Last Comment Bug 717339 - Selection's Ranges should be removed on document.open()
: Selection's Ranges should be removed on document.open()
Status: NEW
:
Product: Core
Classification: Components
Component: Selection (show other bugs)
: Trunk
: x86 Linux
: -- minor (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-11 11:52 PST by Aryeh Gregor (:ayg) (next working March 28-April 26)
Modified: 2012-01-13 02:45 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Aryeh Gregor (:ayg) (next working March 28-April 26) 2012-01-11 11:52:13 PST
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) (next working March 28-April 26) 2012-01-12 08:25:20 PST
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.

Note You need to log in before you can comment on or make changes to this bug.