[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


Adam Barth <abarth at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2




--- Comment #49 from Adam Barth <abarth at webkit.org>  2010-12-30 10:30:38 PST ---
> I've listed several major sites which are using LABjs that *will* break in Webkit nightlies.

So, currently, there isn't a compatibility problem to solve.  There's only a performance problem to solve, correct?

> I am personally in communication with the development teams for many of these major sites using LABjs, and keep them up to speed on the progress of this issue.

Great.  Thanks for doing that.  That's very valuable.

> There's quite a bit of performance optimization that will be lost on these sites if they are forced to go back to using script tags and abandon using script loader techniques.

Is this statement backed up with experiments or just intuition?  Antti's point, which I'm not sure you understood, is that "parallel load, sequential execute" is WebKit's default behavior if you have a bunch of script tags:

<script src="aa.js"></script>
<script src="bb.js"></script>

The preload scanner will kick off both loads in parallel and then execute them sequentially.

> This would be a huge loss for the web community to have Webkit not be forward-thinking (ahead of the spec) and address this obviously needed use case. 

This statement doesn't really make sense.  We should be agreeing on behavior in the HTML working group and then implementing those agreements.  Trying to end-run the process by sneaking a patch into WebKit isn't really productive.  

> Mozilla realized this same thing and that's why they acted with a stop-gap measure to address the need before the spec catches up. I'm asking Webkit to do the same.

You seem to view the spec as "slow" and in need of "catching up."  That's not true at all.  The spec can often be changed faster than implementations because it ships instantly whereas browsers have shipping cycles that last varying amounts of time, but as long as a year.

(In reply to comment #45)
> > So why is async needed at all?
> 
> I assume you mean the markup `async` attribute, not the (currently being discussed) `async` property on a dynamic script element in JavaScript?

Today these two things are the same.  The JavaScript property reflects the DOM attribute, like a ton of other JavaScript properties.

> But in JavaScript, I have *no way* to choose the ordering behavior.

Right.  That's the real problem.  Why don't we create an API that solves this particular problem instead of goofing up the connection between the async property and the async attribute?

> 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

I'm not sure I understand the connection with this change.

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

Would it help to apply it to script-inserted scripts as well?

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

The TR version of the spec is usually wildly out of date.  I recommend always using the whatwg version.

[[
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.
]]

> 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.

It seems clear that we shouldn't fetch the src in either case.

> 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.

Indeed.

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

That sounds like a bug we should fix.

> 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?

It's not intentional.  Please file a new bug (and ideally attach a patch).

Bottom line: Let's work this issue out in the HTML WG.  That's the proper forum for this discussion.  Once we decided what to do in that venue, we can implement that decision here.

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