domReady plugin fires much later than it should (in FF/Chrome/Safari) about curl HOT 12 CLOSED

So, in order to set up this test case, we will need to delay the response of one or more modules (or js files) from the server?

FWIW, unlike RequireJS, there's no code that explicitly waits for inflight modules/files in the domReady! plugin or the curl/domReady module (which it calls).

It might be useful to see your setup. There are a few variables that come to mind. Specifically, are you using the js! plugin in conjunction with the domReady! plugin? Are you using curl's promise-like chaining? Are your scripts in the head or near the end of the body?

A code snippet would be very helpful. :)

from curl.

It requires a custom handler to easily repro, something similar to:

<script src="curl.js"></script>
<script>
   curl(['http://crossdomain/sleep/5000']).then(function() {
     console.log('my file loaded');
   });


   curl('domReady!').then(function() {
     console.log('domReady!');
   });
</script>

It wont necessarily fire AFTER "my file loaded", but it'll be right before.. So domReady will take roughly 5 seconds to fire in this case, with nothing else on the page other than your basic tags (html/head/body etc).

from curl.

Another important note, it does not matter the ordering that I put my curl calls in. You can subscribe for "domReady!" first, it'll still fire late.

from curl.

Part of my previous post got stripped by github so here it is again: Are your scripts in the head or near the end of the body?

from curl.

In the example above, the first script (to include curl) is in the head, but all functionality is in the body. This example requires nothing else in the body.

from curl.

I found and fixed two issues with the domReady algorithm in FF/webkit that could delay the callback. I am not sure if they resolve the issue entirely. Still investigating.

from curl.

Great. On vacation, but I can verify Tuesday if you haven't closed the issue by then.

from curl.

Hey @asilvas,

I didn't actually test the slow script loading scenario that you mentioned, but I did find what appears to be a smoking gun*. :) I made the fix in the dev branch last night. If you've got some time to verify, that would be great! If not, I'll likely get to it tonight or tomorrow.

Much appreciated!

-- J

• Some earlier code that tried to consolidate IE and W3C load detection was causing IE to signal dom-ready too early. We removed the "interactive" readyState altogether to fix the problem. I've got a fix in there that restores the "interactive" readyState, but doesn't hose-up IE. Ultimately, we may move over to Diego Perini's ultra-fast IEContentLoaded method if we can keep the code size down.

from curl.

My tests against FF5 & Chrome were fantastic, virtually identical to jQuery.ready callback! This is a dramatic change for domReady logic, especially on slower loading pages.

After testing IE9 I thought it had broken, what I found was that the updated logic just allowed domReady to fire IE9 even earlier than it already was. So after moving my dom element above the script block (duh), my test cases resumed working.

My concern however is the inconsistency between browers. jQuery.ready for instance does not fire until all dom elements are available, including those that follow the executing script block. But with "domReady!", while it seems to work this way in FF/Chrome, it is firing dangerously (?) early in IE9. Thoughts?

from curl.

By the way, my last statement is not to say it should or should not work differently, only stating a difference I noticed. I'm of the mindset of, I want to know when the dom is available at the earliest time possible (which differs between browsers).

from curl.

I played -- er, I mean tested :) -- with IE9 a lot while trying the new domReady. I was worried that it was firing too early. Clearly, from your tests, it's firing before all of the dom is ready. That's too early for a general-purpose solution, imho. I am going to try a variation (i.e. improvement) on Diego Perini's IEContentLoaded method. It should be an easy addition.

from curl.

The latest dev branch holds a fix for IE9 executing too early. Closing for now. Please reopen if you find any more issues. Thx!

from curl.