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

[Maciej Stachowiak]

On Mar 30, 2010, at 7:38 AM, 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():
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/430
>
> 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 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/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.

...

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

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.

Regards,
Maciej