Some DOM Event tests fail with this polyfill about ie8

[WebReflection]

Hello there!
Looks like our libraries do something different where mine extends document and window and is focused not only in synthetic or well known events but both.

I am curios to know which test failed exactly but what I can already tell you it won't be fixed is:

• there won't be any try/catch around methods. try/catch is slow in IE8 and in any case uncaught exceptions put any web app in a weird state nobody wants/needs to deal with. The fact native keeps firing is in my opinion a bad decision. Events should not fail and they don't in 12+ years of personal experience so YAGNI and slower
• there won't be any capture phase in my shim since it complicates much more than what you've written there. As example, capturing usually starts from the document so you have completely unpredictable behavior in there.
• there won't be a CustomEvent polyfill in here. I might think about it later on but IIRC such constructor needs to be polyfilled in many other environments so your version might not be enough.

That said, it's good you have so many tests for your scenarios and I wonder if your polyfill works with my tests instead where both synth and real world use cases with real user actions over both custom and real events are performed.

Maybe putting these libraries together we can end up with something really reliable, fast enough, and usable for complex scenarios too?

Also I could not see any DOMContentLoaded polyfill in your repo, the method used the most and missed the most in my DOM w/out libraries experience :-)

Best Regards

[ondras]

Hi there,

thanks a lot for your reply!

I am not sure what do you mean by "synthetic" events. My goal is to create an implementation as compatible with the spec as possible - and this includes both the (polyfilled) MouseEvent and CustomEvent.

It would be best if you could get my tests up & running (really just a matter of checking out the repo and opening the test runner); you can then switch my polyfill to yours to see failing tests.

I fully understand your reasoning about non-implemented features (try/catch; capture). My aim here is different: to stick to the spec as much as possible. Also, I recently came across a situation where a poorly implemented event handler threw an exception; fortunately, this was a native implementation and other handlers were executed okay. This would have cost us quite some money, should the other handlers not fire (customer tracking code). I also recall seeing some cool trick where you can execute handlers withing a single try-catch block, not needing to wrap every iteration again and again (=> slow).

My CustomEvent and MouseEvent polyfills are ready even for non-IE8 browsers that use the document.createEvent() interface (those are actually double polyfills). Again, try to run those tests in all contemporary browsers: they all pass, even with CustomEvent and MouseEvent.

I would be interested in running your tests against my polyfill; I will try that tomorrow and let you know about the results.

Finally, DOMContentLoaded is indeed missing. I am planning to implement it as well soon, but there are two things that slightly complicate the situation:

1. I am not aware of any feature detection code which allows me to sniff for DOMContentLoaded support/absence;

2. this event is basically untestable using traditional testing tools (such as the Jasmine BDD I used).

[WebReflection]

you cannot use a single try catch 'cause the moment it fails you are kinda screwed regardless? Or you mean something like the following?

function moreTryLessCatch(handlers, index) {
  if (index == null) index = 0;
  try {
    while (index < handlers.length)
      handlers[index++]()
    ;
  } catch(e) {
    moreTryLessCatch(handlers, index);
  }
}

This might be a desirable fix indeed ... thinking about it right now.

About DOMContentLoaded you know that if your code is loaded in IE8, which is the case for mine, it's missing. As easy as that ;-)

Otherwise you can assume that if addEventListener is not a method, you are in IE 8 and need to fix that.

[ondras]

Yeah, the trick was similar. Something like this:

var i=0, len=listeners.length;
while (i<len) {
  try {
    while (i<len) {
      listeners[i++]();
    }
  } catch (e) {}
}

As for the DOMContentLoaded detection -- well, I agree that the absence of addEventListener somewhat implies IE8, but this is just a trick; I would be happier to do a precise feature detection, polyfilling this event in EVERY BROWSER that does not fire it itself (the same I do with addEventListener and other polyfilled functions).

[WebReflection]

there's no other browser except IE < 9 that does not fire DOMContentLoaded and has no addEventListener event since ever.
Be pragmatic for this specific case otherwise you'll never be able to polyfill that.

[WebReflection]

ping :)

[ondras]

Ah, sorry for forgetting about this. I tried to run your tests, but they use the (now deprecated) document.createEvent interface, which is not supported by my polyfill. I also found out that a standards compliant browser (FF 23 in my case) fails two of your unit tests. Is that expected?

I did not have enough time to further enhance my polyfill so far; instead, I create two issues for the two improvements suggested in this thread: https://github.com/ondras/ie8eventtarget/issues

[WebReflection]

what do you mean by deprecated createEvent ? DOM4 uses customs but that does not mean createEvent is going anywhere, isn't it? Or you are saying your FF does not allow that anymore already?

[ondras]

As far as the deprecation goes, I was just citing the red box at the top of this page: https://developer.mozilla.org/en-US/docs/Web/API/document.createEvent

The failing tests can be seen by opening your test runner http://webreflection.github.io/ie8/test/ in a recent Firefox.

[WebReflection]

so let me explain something here ... nothing that is not IE should fail in those tests since those tests are based on current standards plus the library you see here is never loaded in anything but IE8.

The fact Firefox Nightly is failing with one test and Chrome is not, for example, does not mean this library breaks anything and does not mean Firefox is right neither since every other test using synthetic events pass indeed.

In the worst case scenario, it's the test with some issue, not this polyfill or library since again, it never runs in other browsers different from IE8 ... it's using the conditional, IE8 specific, comments indeed ;-)

[WebReflection]

<!--[if IE 8]><script src="build/ie8.max.js"></script><![endif]-->

this is all you have for non IE8 browsers: a comment

[WebReflection]

You know what? I've filed a Firefox Bug ;-)

[ondras]

Well I am not questioning your polyfill, I just pointed out that the test runner fails in Firefox. Also, the behavior seems to be per spec, as there is no exception for nodes not appended to the document tree.

Finally, the test runner also fails in Opera, IE9 and IE10 :-)

[WebReflection]

Looks like Chrome, Safari, and Blink (Chrome again) are failing same way so this is a WebKit gotcha I guess and that has been filed all over.

I'll fix the test and IE8 library accordingly so thanks!

[WebReflection]

I'll double check with IE8 later but I should have fixed the library and I've changed tests too. Now green in Firefox