0

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

doydoy44
  • 5,720
  • 4
  • 29
  • 45
casperchen
  • 5
  • 1
  • 1

1 Answers1

0

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.

Kyle Simpson
  • 15,725
  • 2
  • 33
  • 55
  • thanks for your patient reply~ After posting this question , I set some breakpoints and trace the source code of LAB.src.js , still with the same test case: `$LAB.script('http://code.jquery.com/jquery-1.8.0.min.js').script('http://id.qq.com/js/10001/simple.js');` The following variable is set to false in create_sandbox , so :`can_use_preloading = real_preloading || xhr_or_cache_preloading` so in request_script(), param preload_this_script is false too, then it goes into the second branches, where set the script's async property to false `script.async = false;` ,is it the problem? – casperchen Sep 04 '12 at 16:12
  • ahh, so, yes this explains things. it's not a "problem", it's as designed. for browsers that use `async=false` as the technique, their execution order will be enforced by the browser (not LABjs), and that order will be request order. AFAIK, in those browsers, you cannot get around that browser behavior. sorry for not catching that fact in your first question. – Kyle Simpson Sep 10 '12 at 18:15