javascriptgoogle-chromelabjs

LABjs bug : scripts always excuted the sequence they are loaded using .script()

When I did some test cases with LABjs,I encountered some problems,here comes the code:

$LAB.script('http://code.jquery.com/jquery-1.8.0.min.js')
    .script('http://id.qq.com/js/10001/simple.js');

according to the API description, there is no guaranteed for the excution order of jquery-1.8.0.min.js and simple.js. I blocked jquery-1.8.0.min.js with fiddler,what i boserverd was:

  1. It works just all right in IE8, when simple.js finished downloading,it excuted right at once.
  2. In chrome 20, simple.js never excuted until jquery-1.8.0.min.js finished downloading and excuted.

Is it a bug ?

Then I did another test in chrome 20,here comes the code:

var script = document.createElement('script');
script.type = 'text/cache';
script.src = 'http://code.jquery.com/jquery-1.8.0.min.js';
document.head.appendChild(script);

jquery-1.8.0.min.js didn't start downloading when I ran this code , is it the problem?

here is the api description:http://labjs.com/documentation.php#script

Solution

  • You have two questions, so let me take them separately:

    1. Why isn't "simple.js" running if "jquery.js" is blocked, in Chrome 20, but works as expected in IE8?

      Ummmm, I don't fully know why that would be. It's probably not a bug in LABjs, but it might be a quirk of Chrome. It should, according to the spec, run in ASAP order, meaning "simple.js" should not be waiting on "jquery.js". The only other explanation besides the browser having a quirk/bug would be if somewhere in your code you have set $LAB.setGlobalDefaults({AlwaysPreserveOrder:true}), as that will cause the blocking behavior just like if there was a wait() in between the two.

      Just for the sake of ruling that out, can you change the snippet to be $LAB.setOptions({AlwaysPreserveOrder:false}).script(...)... to explicitly disable that automatic wait() behavior, just in case?

    2. Webkit (roughly Chrome 11'ish) stopped fetching script elements if their type attribute wasn't a recognized valid type. So "text/cache" should be ignored and fail to start downloading in Chrome 20 (and all other browsers, for that matter, except IE <= 9), because that's what the spec says to do. Where you see that technique in LABjs' source code, it's actually used as a last-case fallback, where it applies ONLY to those really old/legacy webkit browsers, because it DID work way back then.