- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 24 Jun 2012 01:26:22 -0400
- To: Jatinder Mann <jmann@microsoft.com>
- CC: "Karen Anderson (IE)" <Karen.Anderson@microsoft.com>, Carl-Anton Ingmarsson <carlantoni@opera.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On 6/22/12 5:53 PM, Boris Zbarsky wrote: > That said, I think this spec could really benefit from an actual > definition of "navigation". The definition could explicitly exclude > document.open, which would have the same effect in terms of normative > requirements. I feel like I need to state this more clearly (and perhaps more forcefully), actually. In browsers, the behavior of document.open/write/close involves the following: * Firing beforeunload and unload on the Window. * Creation of a new Window. * Parsing of some data and creation of a new DOM tree, loading of subresources. * Firing load on the new Window. In most browsers it also involves addition of entries to the session history, with the ability to navigate forward and back between the various document.write-created pages. The only differences between this and your typical http:// load are: 1) No network access. This is also the case for file:// or data: or javascript:, etc loads. 2) The document object is preserved during the process (though at least in Gecko it is NOT preserved when navigating back/forward between document.open-created documents). In Gecko, at least, what makes something a "navigation" is whether certain events fire and whether the Window object changes. Document object identity never even enters the picture. Since this specification does not define what a "navigation" is, Gecko is simply using its internal definition, and as far as I can tell that's perfectly conformant with the spec as it is written now. If the intent of the spec is to exclude document.open from changing the state, then the specification needs to define "navigation" accordingly. Probably by either calling out document.open specifically somehow or by trying to define it in terms of not having behavior #2 above (i.e. defining it as a change of current document for a browsing context... though note that then going back from a document.open-generated page _would_ be a navigation in Gecko). And of course as Carl-Anton pointed out the "loading of subresources" bit means it might in fact make sense to measure navigation timing even on document.open-created documents. That's a separate issue from how to not measure it if it's _not_ desired. -Boris
Received on Sunday, 24 June 2012 05:26:53 UTC