W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2010

[Bug 9984] [parser] Insertion point for script@onload doesn't match Firefox

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 Jul 2010 12:16:01 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OZNM9-0007f8-4A@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984





--- Comment #4 from Henri Sivonen <hsivonen@iki.fi>  2010-07-15 12:16:00 ---
(In reply to comment #0)
> > I'd rather not punch a special hole for that event handler without a compelling use case or site compat requirement. (Also, it seems inconsistent to make load on <script> fire synchronously when load events in general are async.)
> 
> I guess I don't fully understand the implementation constraints you're
> operating under.  There are two issues:
> 
> 1) Should the script load even fire synchronously.
> 2) Should synchronous events that call document.write use the current
> insertion point.
> 
> There are a number of benefits to firing the script load event synchronously:
> 
> A) The behavior matches all the shipping browsers I've tested.
> B) Firing the script load event synchronously is more predictable for
> developers and less likely to lead to race conditions.
> C) There are unknown compatibility implications for changing when the
> event is fired.
> 
> There are a number of benefits for having synchronous events use the
> current insertion point.
> 
> a) The behavior matches all the shipping browsers I've tested.
> b) Reusing the current insertion point is more predictable for
> developers and less likely to lead to race conditions.
> c) Reusing the current insertion point better matches the mental model
> for how HTML documents are processed (basically, it abstracts away how
> much of the document input stream is buffered in the network layer and
> how much is buffered inside the tokenizer).
> d) There are unknown compatibility implications for changing how
> document.write in synchronous events behaves.
> 
> The only "con" I see to (1) and (2) is a new implementation constraint
> in Gecko that I don't quite understand given that we're not creating
> any new insertion points (these events are just using insertion points
> that already exist for the <script> elements themselves).

I had a look at the code. It's certainly doable to reorder the script load
event firing and the insertion point getting undefined.

What I'm not quite sure about is how this will interact with the relative
ordering of multiple document.write()s when the script load handler initiates
nested document.write()s. It's easier to see in a debugger what happens than to
try to read the code... I'll report back. Let's keep this spec bug open for a
moment longer. (Sorry about the slow response.)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 15 July 2010 12:16:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:52 UTC