Closed Bug 717339 Opened 10 years ago Closed 3 years ago

Selection's Ranges should be removed on


(Core :: DOM: Selection, defect)

Not set





(Reporter: ayg, Unassigned)



When something calls, 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.

I also wrote a test: <>.  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, 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 <>, which keeps a document in an iframe and uses 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.
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 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.)

New test:

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.
Summary: Selection's Ranges should be removed on document unload ( → Selection's Ranges should be removed on

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?

Depends on: 1489308
Flags: needinfo?(timothygu99)

Some digging-around yields as what Aryeh was referring to, which was then added to WPT as However, the test was recently changed to the actual spec behavior in, which is the same as Firefox's current behavior. The behavior of Chrome is tracked in

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.

Flags: needinfo?(timothygu99)

Great, thank you!

Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.