- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 30 Mar 2010 17:38:04 +0300
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. 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. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 30 March 2010 07:38:04 UTC