When something calls document.open(), the document's Selection should have all its ranges removed and its direction reset to forwards. Currently, what seems to happen in Firefox 12.0a1 (2012-01-10) is that the Selection is left alone, so any range in it just gets reset to (document, 0). I think this is unexpected: when the document is unloaded, all state from the previous document should be cleared. Or is the behavior desirable? I updated the editing spec for now to require that the selection's ranges be removed: """ As one of the unloading document cleanup steps, the user agent must remove any range from the selection associated with the Document's browsing context (so the selection's range is null) and set its direction to forwards. """ http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections I also wrote a test: <http://dvcs.w3.org/hg/editing/raw-file/6aaa4b8455c9/selecttest/unload.html>. Firefox 12.0a1 and Chrome 17 dev fail. IE9 and Opera Next 12.00 alpha pass. If the specced behavior is undesirable, I can change it to the other way, but this way makes more sense to me. Note that the test only tests document.open(), but this should also apply to history.back()/forward(), among others. I also didn't test the selection's direction, only the rangeCount. I ran into this bug because I was testing something selection-related in Live DOM Viewer <http://software.hixie.ch/utilities/js/live-dom-viewer/>, which keeps a document in an iframe and uses document.open()/write()/close() to reset state. Gecko and WebKit confused me severely, because the state didn't fully reset between runs. (WebKit doesn't even clear setInterval() . . .) IE and Opera worked as expected.
Summary: Selection's Ranges should be removed on document unload (document.open()) → Selection's Ranges should be removed on document.open()
You need to log in before you can comment on or make changes to this bug.