-
Notifications
You must be signed in to change notification settings - Fork 26
addEventListener polyfill is firing the actual event on the actual element the first time that event is listened to #18
Comments
Just a bit more information for anyone that's interested. I'm using (having to use) jQuery, and my current workaround is to include the following code block directly after including ie8.js.
|
as you can read here the whole point is indeed to silent the test,
This polyfill is about DOM standards, are you sure you just don't want to use jQuery 1.X instead? If you have to support IE8 and you want to use jQuery it seems like a better answer. [edit] trying to see if I can at least cancelBubble if there is a SECRET |
Can you please try this version and tell me if with that you still need the jQuery hack? Maybe it was simpler than expected, Thanks |
Firstly, thank you for this lib, dom4.js, and document-register-element.js. None of us dev's choose to support IE8 for so long, but such is life, and your libs make it a lot more bareable... I was able to reproduce the issue without using jQuery using the following page
In this test page, the onsubmit method is still being invoked with the updated build. If it is possible to fix this, the use case that it benefits is when someone is working with a legacy codebase but trying to add all new features in a more standards-based way. In that case there might be inline javascript and/or jQuery hanging around until those parts get refactored. If a fix is possible, AWESOME, it means I can drop this lib into a legacy codebase and start using standards. If a fix isn't possible, then it would probably at least be good for people to know what to look out for when adding this lib to a legacy codebase. Maybe it just warrants a mention in the known gotchas section of the readme... Thanks for your time and everything. |
uhm ... Yeah, if you don't use standards to add events, ie8 and dom4 might fail in many ways. These libraries have been created to actually let people write standards, not as migration to standard patterns, specially because ie8 + attachEvent on top of legacy might do more damage than solving. The migration should be a proper refactoring, but I understand this might be not reasonable, as task to waste time, in some bloated, badly architected, legacy code. I'll try to think about some way to avoid the inline / onpage event triggering, but I will need you to test again your legacy. |
the form page has been tested against IE8 ( through Windows XP VM ) and it seems to work as expected: no regressions, and no alert shown. Can you please confirm the latest build works? |
OK, I have done other enhancement. The current version I will close this, but feel free to ask me more, if needed. Cheers |
Thank you very much! Cheers... |
Line 353 is
self.fireEvent(ontype, e);
In my case, this is submitting a form as soon as the listener gets added. I see in the comments that you want to perform the test on the actual element, but maybe there's a way to silence the event so it doesn't propagate or trigger the default behavior?
The text was updated successfully, but these errors were encountered: