W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] location.reload() on document.open()ed documents

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 24 Aug 2010 22:13:44 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1008242107090.1138@ps20323.dreamhostps.com>
On Tue, 27 Jul 2010, Boris Zbarsky wrote:
> On 7/27/10 3:00 PM, Ian Hickson wrote:
> > > On each document.write() on a document.open()ed document, Gecko 
> > > appends the written string to a cache entry (at the method call 
> > > time--not at the tokenization time--which makes a difference of the 
> > > document loads external scripts that also call document.write()!). 
> > > Upon reload, Gecko parses the contents of the cache entry. This 
> > > produces interesting results if the document.open()ed document 
> > > itself calls document.write(): 
> > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/430
> > 
> > Does that mean that location.reload() will never reload from the 
> > network?
> 
> For a document that was created via document.open(), this is correct. 
> Note that "from the network" makes no sense in this context.
> 
> > What if the cache entry has been expired?
> 
> It doesn't get expired; it's pinned in the cache while the document is live.
> 
> > Does document.open() clear the cache entry?
> 
> It creates a new one and unpins the old one.
> 
> > What if there are multiple windows all with the same original
> > page, and they each document.write() something different?
> 
> They get different cache entries.  In particular, the cache entries are
> addressed by the URI of the page originating the write and a unique (well,
> until you make 2^32 open() calls) sequence number.
> 
> Note that this is just the description of the Gecko implementation; all 
> the cache stuff is implementation details that are irrelevant to the 
> resulting behavior, which is that if you have a subframe and your page 
> opens it and writes to it and you hit reload the subframe is reloaded 
> with whatever was written to it.

So basically, translating this to specese:

   Document objects on which you call open() have an "override reload" 
   flag set and an initially empty source cache added.

   When you call document.write() on a document with the "override reload" 
   flag set, also append the text to the document source cache.

   When you reload a document that has the "override reload" flag set, 
   instead of reloading from the network, just stream the data in from the 
   document source cache.

Is that right?

If so, how do other browser vendors feel about doing this?


> > > Loading demo 429 in WebKit or Presto reloads the top-level document 
> > > in the iframe causing the alert to run again and again and again.
> > 
> > Because it ends up with an infinite regression of iframes; the reload 
> > is just making the page load the page instead of about:blank, since 
> > calling document.open() changes the document's address to the caller's 
> > address.
> 
> Right.  This infinite regression is not a desirable consequence; the 
> spec requiring this behavior seems like a bad idea.

I don't know, it seems pretty desireable to me -- it's far simpler than 
caching the results of document.write()!


> Again, those are an implementation detail.  The upshot is that each 
> document created via document.open() has a nonce identifier that points 
> to the data that was written; this data is used when the document needs 
> to be reloaded for whatever reason (history navigation, reload button, 
> location.reload(), etc). The data goes away once it can no longer be 
> reached/used.

Also doing this for history navigation is rather scary too, but I guess 
could be done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 24 August 2010 15:13:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC