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.
Indeed. > 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 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 > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/431 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. `._.-(,_..'--(,_..'`-.;.'