[whatwg] location.reload() on document.open()ed documents
bzbarsky at MIT.EDU
Tue Jul 27 13:10:41 PDT 2010
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():
> 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
>> 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.
More information about the whatwg