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

[Bug 10625] Spec should cover stopping parsing on location.href = "foo"

From: <bugzilla@jessica.w3.org>
Date: Wed, 29 Sep 2010 04:22:52 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P0oBw-000331-68@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10625

--- Comment #6 from Boris Zbarsky <bzbarsky@mit.edu> 2010-09-29 04:22:51 UTC ---
The Gecko behavior is that starting a load in a docshell (which is basically a
navigation context; maps 1-1 to a window proxy) will issue a Stop() call if the
URI is not a javascript: URI.  This check happens after checks for scrolling to
anchor, etc.

Now a complication is that there are two kinds of Stop() calls.  Usually
navigation starts issue a STOP_NETWORK, which just stops all the network
activity associated with the current page in the navigation context.  But for
location.href sets, and for any navigation that happens before the new page is
actually showing (e.g. during the paint suppression timeout), we issue a
STOP_ALL call, which stops network activity, stops image animations, and stops
the parser.

I believe both versions of Stop() can synchronously trigger onload on the page
being navigated away from in some cases (e.g. a parent document that has
everything loaded except for one subframe is navigated from an onload handler
on the subframe's window; that will synchronously trigger onload on the parent
before the location set returns, because otherwise the parent would never get
an onload at all in Gecko due to the new load that just got kicked off being
associated with it for the moment).

Now what parts of all this are needed for web compat... I don't know.  This
code mostly predates my involvement in the project, and I've modified it as
little as I can while fixing obvious issues over the years; the regression risk
has always scared the crap out of me.

As for the questions in comment 5.... at least in Gecko a location.href set is
equivalent to the user hitting the stop button in terms of its "stop" effects. 
What's the stop button specified to do, if anything?  If it's not specified,
then (still in Gecko) the situation is basically treated as if all outstanding
network requests in the window subtree rooted at the relevant window had
network errors.  That should cover document readiness, DOMContentLoaded, load,
pageshow, popstate behavior.  No idea about appcache.  As for scripts executing
and parsing ending, I believe anything that's not in the DOM already needs to
not end up in there, if you're trying to duplicate Gecko behavior.

Again, no idea how much of this is _needed_ for compat.

-- 
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 Wednesday, 29 September 2010 04:22:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:25 UTC