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
