[Webkit-unassigned] [Bug 50115] Please implement async=false for dynamic script loading (REGRESSION: LABjs is broken)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50115





--- Comment #46 from Kyle Simpson <getify at gmail.com>  2010-12-30 10:04:22 PST ---
I have a new detour problem I need help understanding. This entire process of me requesting the "async=false" of Webkit was because of this changeset (and anticipated LABjs breakage):

http://trac.webkit.org/changeset/67245

...which auspiciously is supposed to prevent Webkit from fetching a script resource if the script `type` attribute/property is unrecognized. Indeed, if you try something like:

<script type="foo/bar" src="foo.js"></script>

...in markup, that script will in fact NOT be fetched.

However, if you do:

var script = document.createElement("script");
script.type = "foo/bar";
script.src="foo.js";
document.getElementsByTagName("head")[0].appendChild(script);

...*THAT* script will still be fetched (but not executed, obviously).

So, at the moment, we have that changeset only applying to parser-inserted script elements, and not script-inserted script elements.

Here's what the spec says, which prompted changeset 67245:

http://www.w3.org/TR/html5/scripting-1.html#running-a-script

> 5. If either:
>
> * the script element has a type attribute and its value is the empty string, 
> or 
> * the script element has no type attribute but it has a language attribute 
> and that attribute's value is the empty string, or 
> * the script element has neither a type attribute nor a language attribute, 
> then 
> 
> ...let the script block's type for this script element be "text/javascript".
>
> Otherwise, if the script element has a type attribute, let the script 
> block's type for this script element be the value of that attribute with any 
> leading or trailing sequences of space characters removed.
>
> Otherwise, the element has a non-empty language attribute; let the script 
> block's type for this script element be the concatenation of the 
> string "text/" followed by the value of the language attribute.
>
> The language attribute is never conforming, and is always ignored if there 
> is a type attribute present.
>
> 6. If the user agent does not support the scripting language given by the 
> script block's type for this script element, then the user agent must abort 
> these steps at this point. The script is not executed.

------

In other words, the above language in the spec is a little ambiguous as to whether or not the instruction to ignore fetching the script if the type is invalid ONLY applies to parser-inserted scripts, or if it applies ALSO to script-inserted scripts.

Many other parts of the algorithm at this point in the spec DO apply to both, and indeed I can't imagine that the spec is completely silent on how a script inserted script element's type is determined, so I believe that above language should apply to both.

But it appears that the Webkit changeset was only interpreted to apply to the parser-inserted scripts.

Is this intentional, and if so, what's the reasoning? If not, should a new bug be filed against that changeset to get it applied to dynamic script elements as well?

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

In any case, this is PART of why you're not yet seeing breakage in Webkit nightlies, because pretty much all script loaders use dynamic script elements and not script tags in markup.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.