YuzuJS/setImmediate

Fatal "Operation aborted" errors when used during page load in IE6/IE7

Closed this issue · 3 comments

sth commented

In Internet Explorer 6 and 7, modifying the DOM from Javascript during page load is problematic and can lead to an "Operation aborted" error.

The readystatechange implementation of setImmediate, which is used in IE6 and 7,
does modify the DOM and causes this error if setImmediate is called before
the page is completely loaded.

For example the following HTML causes such a "Operation aborted" popup, followed
by an error page:

<html>
   <head>
      <script src="setImmediate.js" type="text/javascript"> </script>
      <script type="text/javascript">
         setImmediate(function(){});
      </script>
   </head>
</html>
domenic commented

You should load the setImmediate script at the bottom of the page, not in the <head>. You should generally do this for all <script> tags, in all browsers.

sth commented

You probably should put a note in the readme that it is supposed to be unusable before the page is completely loaded. Otherwise I don't think this it the usually expected behavior.

Deleted user commented

If you see possible fix, I would like if you reopened this. This is in fact serious issue - if this project is to be a shim for setImmediate, it must work in all conditions, even during page load; not just after DOM is ready or any other condition.

To include a real-life story, I wanted to include this project as a dependency of amber-smalltalk/amber, to implement #fork by way of setImmediate, but @NicolasPetton vetoed it at that time, not wanting to have external dependencies in core. Now I am paradoxically thankful for it, because Amber won't fail during page load if code with #fork is used.

What I wanted to say by this story is, to be usable, you should not presribe your users a way to use you. setImmediate must work (or, at least, queue for later) even during page load.

P.S.: Amber does not support IE6 nor IE7, so in practice, this would not be issue at the moment. But the mindset of 'you should load me after DOM is ready, or I don't care' is, IMO, not right - it can bring in similar error later.