This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Make it explicit that once the user changes the selection a Range object is created and associated with the selection.
Browsers seem to differ here. Tested: IE9, Firefox 12.0a1, Chrome 17 dev, Opera Next 12.00 alpha. Initial range: In IE, Chrome, and Opera, getSelection().rangeCount is initially 0. In Firefox, it's initially 1, with the range collapsed at (document, 0) like with all new ranges. When the user changes the selection: All browsers replace the existing range with a new one (they don't mutate the old one). When the user clicks somewhere without dragging, so the selection/cursor disappear: Opera sets rangeCount to 0. Firefox and Chrome make the selection's range collapse at the indicated place. IE make the range collapse to the indicated place if you actually click on some text, but sets rangeCount back to 0 if you click on empty space. Conclusion: Firefox's behavior is simplest, because it means that if no one calls removeRange/removeAllRanges, rangeCount is always 1, and getRangeAt(0) never throws. I wonder if we could get away with making removeRange/removeAllRanges actually reset the range to (document, 0)? Or maybe even (document.documentElement, 0)? That would be a significant additional simplification for authors -- then rangeCount is *always* 1. remove(All)Range(s) followed by addRange would still work as expected. Hmm . . . More complicated than I expected! (Which just shows that I'm unreasonably optimistic, I guess.) I'll send out a mail and update the spec tomorrow.
I clarified behavior requirements for how to associate ranges with selections, matching Firefox as noted in comment 1: http://dvcs.w3.org/hg/editing/rev/c989dd9e441d Started a discussion for possible further change: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0107.html
(In reply to comment #1) > Initial range: In IE, Chrome, and Opera, getSelection().rangeCount is initially > 0. In Firefox, it's initially 1, with the range collapsed at (document, 0) > like with all new ranges. This turned out to be wrong. Actually, all browsers start rangeCount as 0. However, I was testing in Live DOM Viewer, and the range wasn't removed when the iframe got unloaded. IE9 and Opera Next 12.00 alpha do appear to remove the range on unload, which is what I'd expect; Firefox 12.0a1 and Chrome 17 dev do not. I fixed the spec so the range is initially null (matching all browsers), and specified the IE/Opera behavior for unload (with a test): http://dvcs.w3.org/hg/editing/rev/6aaa4b8455c9
Moving to Selection API component.
Reopening the bug per https://bugzilla.mozilla.org/show_bug.cgi?id=671152