717339 - Selection's Ranges should be removed on document.open()

Status: RESOLVED INVALID

(Core :: DOM: Selection, defect)

Description

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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.

Comment 1

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

After discussion with Boris Zbarsky and Ian Hickson: actually, the Selection object is supposed to be replaced with a new one.  This is specified in HTML as part of the document.open() algorithm:

"""
Replace the Document's singleton objects with new instances of those objects. (This includes in particular the Window, Location, History, ApplicationCache, and Navigator, objects, the various BarProp objects, the two Storage objects, the various HTMLCollection objects, and objects defined by other specifications, like Selection and the document's UndoManager. It also includes all the Web IDL prototypes in the JavaScript binding, including the Document object's prototype.)
""
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-open

New test: http://dvcs.w3.org/hg/editing/raw-file/56c83bbaa44c/selecttest/Document-open.html

The new test shows that Gecko does replace the selection with a new object, but that object has the same ranges as the old one.  WebKit is the same object as before.  Opera clears the ranges but I can't tell if it's the same object, because getSelection() != getSelection() in Opera.  IE returns a different object and clears the ranges, so it's the only one that passes the new test.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Spec has since changed. As far as I can tell, the new spec doesn't say to do anything magic with selection...

The test link in comment 1 seems to be 404 now. What is the expected behavior here, and what do browsers actually do?

Comment 3

[Timothy Gu [:TimothyGu]]

Some digging-around yields https://github.com/w3c/editing/blob/1b2a1256bc79b470b34dc8846534e870266251e7/selecttest/Document-open.html as what Aryeh was referring to, which was then added to WPT as https://github.com/web-platform-tests/wpt/blob/01a11727cdfb8a3ac30a20c4c7314ae35e5c35da/selection/Document-open.html. However, the test was recently changed to the actual spec behavior in https://github.com/web-platform-tests/wpt/pull/15812, which is the same as Firefox's current behavior. The behavior of Chrome is tracked in https://crbug.com/941913.

tl;dr: This is no longer a bug for Firefox. Chrome still does something different (in order to pass the older test it turns out), but that will be fixed hopefully soon.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Great, thank you!