Cannot use zone.js with SemanticUI Search

[gaiottino]

Hi,

I initially posed this bug in here angular/angular#7750 since I'd only narrowed it down to angular2-polyfills.js before I left for holiday. Now that I'm back I dug deeper and found that zone.js is the culprit and I can see there are others having similar issues with 3rd party libs. More specifically, in my case, it's because zone.js is patching the onkeydown event which is used by SemanticUIs Search https://github.com/Semantic-Org/Semantic-UI/blob/master/dist/components/search.js#L100

Here's an updated plunker with only zone.js included http://plnkr.co/edit/SQBxicLoQ5LiFXJgT4qm?p=preview. Commenting out utils_1.patchOnProperties(HTMLElement.prototype, eventNames); the search tool works as intended again or even just removing onkeydown from the patched events "solves" the issue.

This is causing headaches for many people trying to use 3rd party libs with Angular2. Is there a fix coming or a workaround available? Any insight in why this is happening?

Regards,
Daniel

[gaiottino]

Looking for a response or thoughts to this issue. I'm not the only one having issues with how zone.js patches the events and this preventing 3rd party libs to work properly.

[mattdemps]

I second this. I am using Angular in SharePoint and it is hijacking the onsubmit event for the form. Content editors cannot save edits when zone.js is included.

Is there a way to possibly scope zone.js so, for example, only elements that are wrapped in a parent element that has a specific attribute or class are affected by it?

I noticed in the property-descriptor.ts file (line: 15) it is modifying the HTMLElement interface's prototypes, but it might be possible to do some checking on the getters and setters to conditionally hijack events.

[steffenstolze]

same problem here with the Semantic UI search component..

are there any known side-effects when commenting out utils_1.patchOnProperties(HTMLElement.prototype, eventNames); ?

thanks!

[gaiottino]

Still looking for a response to this.

[steffenstolze]

Yes. Me, too.

[lpotapczuk]

I am also interested in more actions on this.

[jlukic]

I just saw this in one of my own projects using Semantic UI. Probably a bad idea to patch events like this, although im still not really sure what's causing this to break in SUI.

[veered]

I was able to fix the problem by changing this line:

zone.js/lib/common/utils.ts

Line 86 in ed69756

return this[_prop];

to return this[_prop] || null;. I haven't thoroughly vetted the change but it works as far as I can tell.

[jlukic]

I've loosened the typechecks to use == instead of === which should preserve meaning even if props are returning null. This should be a simpler solve then waiting for zones to be patched.
Semantic-Org/Semantic-UI@d028ed1

[gaiottino]

@jlukic, @veered I tried both your methods but can't see that they fix the problem? This http://plnkr.co/edit/OOA6TWvvk58q2TRqSkz8?p=preview should have both of your tweaks but the problem persists. Mind creating a plunkr showing it's working? Thanks for your participation with this issue.

[veered]

If you try it with just my change it works for me http://plnkr.co/edit/O475D4x9SXqDu9naIjpk?p=preview

[gaiottino]

@veered you are correct. It does feel like this is a change that should be made in SemanticUI though if it's indeed an issue with undefined and null. How did you find the issue?

[veered]

I think this is genuinely a bug in zone.js. On a normal webpage document.createElement('input').oninput === null but on a webpage with zone.js document.createElement('input').oninput === undefined.

I found it by noticing that keyups were triggering search and breakpointing in different places until I notice the difference I described above.