[whatwg] location.reload() on document.open()ed documents
ian at hixie.ch
Tue Jul 27 12:00:01 PDT 2010
On Tue, 30 Mar 2010, Henri Sivonen wrote:
> The spec says about location.reload():
> "Navigate the browsing context to the document's current address with
> replacement enabled. The source browsing context must be the browsing
> context being navigated."
> It appears that this is what WebKit and Presto do.
> However, for document.open()ed documents, it's not what Gecko and
> Trident do.
> 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?
What if the cache entry has been expired? Does document.open() clear the
cache entry? What if there are multiple windows all with the same original
page, and they each document.write() something different? It's not clear
to me how exactly what you describe would work.
> Trident does something more complicated, because demo 430 doesn't show
> the same results as in Gecko. However,
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/429 shows
> that reload() exists in Trident and is not a no-op. Trident's behavior
> could be explained by Trident making document.write() a no-op when
> reloading a document.open()ed document. See
I don't have IE to test with at the moment; what does IE do in 431?
> 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.
> What about the reload UI?
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/428 creates
> a document.open()ed top-level browsing context making it possible to try
> out the reload button in the UI.
> Gecko and Trident appear to do what they do with reload(). WebKit makes
> reloading from the UI a no-op, but neither Safari nor Chrome bothers to
> put the reload UI in the disabled state. Presto loads the document at
> the document's address (i.e. the opener's address).
> This makes me wonder: If the two engines with the largest market share
> both take steps to enable document.open()ed docs to be reloaded, is the
> behavior needed for optimal Web compatibility? How well are WebKit and
> Presto getting away with their failure to do what Gecko and Trident do
> here? It seems that Gecko is getting away with its failure to do exactly
> what Trident does in the complex cases.
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 haven't changed the spec, mostly because trying to define mutating cache
entries is frightening, so I'd rather not do it without being very
confident that it is the necessary.
On Tue, 30 Mar 2010, Boris Zbarsky wrote:
> 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).
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg