694940 - script.async=false does not mantain order execution

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[filippo]

Attachment: Screenshot of the firebug console

Loading script with script.async=false does not preserve order execution.

The bug seems platform specific. I'm getting it only on a 32 bit Linux machine with Firefox 7.0.1 and Ubuntu 10.04.
I couldn't reproduce the bug on Linux 64 bit, Windows and Mac

Here is a minimal test case I'm running. You can find it online at this url:
http://rewind.sgconsulting.it/test-lab/index2.html

The javascript code is this:
<script type="text/javascript">
var script1 = document.createElement("script"),
    script2 = document.createElement("script")
;

script1.async = false;
script1.src = "http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js";

script2.async = false;
script2.src = "../js/jquery.lightbox-0.5.min.js";

document.head.appendChild(script1);
document.head.appendChild(script2);
</script>

Sometimes the jQuery is executed after jquery.lightbox and so I get an error.
See the attached file with a screenshot of the firebug console.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Non-parser-inserted scripts do not have any execution order imposed on them per spec, last I checked.  They're executed in the order they load in.

Comment 2

[filippo]

I'm not an expert in the field, but googling around I found this proposal as accepted and part of HTML5 spec:
"Make script-inserted external scripts that have .async=false execute in the insertion order, default to true"
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295

See also here:
http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order
for a discussion on the matter.

Comment 3

[filippo]

Ok I think I found out what's happening:

when I request the script from:
http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js

google answers with a redirect to the same url but using the https protocol.

This causes sometimes the script to be inserted in the html after the second one and so it's executed later.

I don't know if this behavior is a bug according to html specs or not, but preserving execution order is important e.g. for script loaders which are becoming popular especially in big sites.

Comment 4

[Kyle Simpson]

(In reply to Boris Zbarsky (:bz) from comment #1)
> Non-parser-inserted scripts do not have any execution order imposed on them
> per spec, last I checked.  They're executed in the order they load in.

Boris, you may recall that in FF4b8, FF implemented what I call "ordered async", which was later spec'd by Ian. "Ordered Async" means that dynamically inserted scripts which have their `async` property set to false will all load in parallel, but will execute in order (that is, the order they are requested, not the order they finish loading).

For reference:

https://bugzilla.mozilla.org/show_bug.cgi?id=602838

http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295

http://ln.hixie.ch/?start=1296711456&count=1

-------------

I helped filipo develop this simple test for this bug report, using no other lib and just creating dynamically inserted script elements with `async=false`. I couldn't reproduce on my machine the out-of-order behavior that he was seeing, but I confirmed that it did in fact exhibit that unexpected (buggy) behavior on his machine (linux, with FF7).

Filipo: if you change the test to request jquery from the https:// address, does the bug go away? If so, that might in fact point in the general direction of the source of this bug.

Comment 5

[filippo]

Yes using https the bug goes way.

I've also tried creating a simple test loading 2 scripts with the first script sleeping for some seconds and then redirecting to a different url but I can't reproduce the bug. Neither to http nor to https

Might it be something related to how google does the redirect? 
Here is a screenshot of my Net Panel in firebug when the error occur:
http://rewind.sgconsulting.it/test-lab/when_error_occurs.png

The google request has no response code while in my tests with a status code 302 everything works fine.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Boris, you may recall that in FF4b8, FF implemented what I call "ordered async"

Ah, I had forgotten that in fact.  OK.

The redirect thing should not affect script ordering behavior.

Like Kyle, I cannot reproduce this problem...

filippo, can you reproduce the problem in safe mode?

Comment 7

[filippo]

Yes I could reproduce the problem in safe mode. See
http://rewind.sgconsulting.it/test-lab/safe_mode.png

I was also able to reproduce the problem on another machine. 
So I'm sure it's not a problem of my pc :-)

Both machines are Ubuntu Linux 32bit. One is 10.04 the other is 10.10.
Firefox is 7.0.1 installed using ppa:mozillateam/firefox-stable

Comment 8

[Henri Sivonen (:hsivonen)]

I installed 32-bit Ubuntu 10.04 and Firefox 7.0.1 from the PPA on VirtualBox OSE on 64-bit Ubuntu 11.10 host. I was unable to reproduce the problem.

The network view from comment 5 looks really strange. What causes the second jquery request if the first one is still stalled?

Comment 9

[filippo]

The first one is the request to http://ajax.googleapis.com
This one should redirect to the some url but with https protocol.
The second one is the request to the https url.

I'm not sure however of the first one because in firebug I was not able to see the response (it remains as you see in the screenshot forever). I also tried with httpfox and with wireshark, but couldn't see the response.

Moreover the behavior on other platforms (MAC and Windows) is different: I have a single request to the http url and the response is either a 200 or 304 status code.

Comment 10

[filippo]

I've done some other tests trying to understand what's happening in the first request.
Doing only a request to:
http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js

Here is another screenshot made with httpfox:
http://rewind.sgconsulting.it/test-lab/jquery_req.png

In the first request there's no bytes received and the response type is "Redirect (cached)" 
In the sencond row there's the request to the https url with result (Cache)

I've also tried replicating the exact same request using netcat, but what I get back from googleapis is a 200 OK response (directly from the http url) with the gzipped jquery library.
This is the same behavior as I see on other platforms or with other browsers.

Hope it helps.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The HTTP behavior should really be irrelevant.  When a script is added to the DOM, we append it to a queue of scripts to run.  Only the first script from the queue is executed (when it's ready), then it's removed, and the process is repeated.

So if the scripts are really running out of order (as opposed to, say, the jquery script just ending up with bogus data), something is very very wrong somewhere.

If you run the same build against a clean profile, can you reproduce the problem?

Comment 12

[filippo]

Ok I created an empty profile with only firebug installed. It's installed by default if you want I can try to install it and repeat the tests.

I ran the tests doing lots and lots of reloads and I got the error only twice. 

I also found out what causes the strange redirect from http to https.
It's a plugin called HTTPS Everywhere:
https://www.eff.org/https-everywhere

My bad I had completely forgotten it.

Comment 13

[Henri Sivonen (:hsivonen)]

(In reply to filippo from comment #12)
> Ok I created an empty profile with only firebug installed. It's installed by
> default if you want I can try to install it and repeat the tests.

Firebug installed by default? Can you reproduce the problem without Firebug?

I installed Firebug into PPA Firefox 7.0.1 on Ubuntu 10.04 on a VM, but I was unable to reproduce the problem (tried HTTP caches enabled and disabled).

Comment 14

[Boris Zbarsky [:bzbarsky]]

filippo, I thought you said you reproduced the problem in safe mode (i.e. without Firebug and without HTTPS Everywhere)...  Is that the case?

Comment 15

[filippo]

(In reply to Henri Sivonen (:hsivonen) from comment #13)
> (In reply to filippo from comment #12)
> > Ok I created an empty profile with only firebug installed. It's installed by
> > default if you want I can try to install it and repeat the tests.
> 
> Firebug installed by default? Can you reproduce the problem without Firebug?
> 

I had Firebug installed through apt-get and when I created the new profile it was there and got automatically updated to the latest version.
Now I've removed the firebug package and uninstalled it. I still see the bug though rarely.

I'll try to simplify the tests even more, removing jquery and using something simpler. 
I'll also try to reproduce it on other machines.

(In reply to Boris Zbarsky (:bz) from comment #14)
> filippo, I thought you said you reproduced the problem in safe mode (i.e.
> without Firebug and without HTTPS Everywhere)...  Is that the case?

Yes I could see the error also in safe mode. In fact HTTPS Everywhere was disabled and there was not the double request from http to https.

Comment 16

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.