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

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.

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

> On Tue, 30 Mar 2010, Maciej Stachowiak wrote:
>>
>> I could not find any bugs in http://bugs.webkit.org/ that were
>> identifiably about this issue. Nor in Radar (Apple's internal bug
>> tracker). Though I have not done thorough testing, I do not believe it
>> is a compatibility issue.

I should note that in the past we _have_ had reports of compatibility 
issues around this behavior, iirc.  I'm not sure we could reasonably 
change it without breaking pages.

 > I haven't changed the spec, mostly because trying to define mutating
 > cache entries is frightening

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.

>> I do feel pretty strongly that reload() doing something different from
>> the browser's reload UI is ... very odd.
>
> Agreed. Opera seems to get away with having them be consistent. WebKit
> browsers should probably change to match (or disable the 'reload' button,
> but that doesn't seem necessary here).

Well, we have no data that Opera hasn't received any complaints and 
hasn't had any compatibility issues... we only know that webkit, with 
behavior differing between the reload button and location.reload, 
hasn't.  And that Gecko, which doesn't have such a difference, has in 
the past when the reload behavior deviated from what it is now.

-Boris

Received on Tuesday, 27 July 2010 13:10:41 UTC