15470 2012-01-09 14:59:07 +0000 Changing the selection creates a Range object 2014-09-16 01:20:54 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Selection API unspecified PC All REOPENED P2 normal --- 1 annevk rniwa benjamp mike public-webapps public-webapps-bugzilla oldest_to_newest 62412 0 annevk 2012-01-09 14:59:07 +0000 Make it explicit that once the user changes the selection a Range object is created and associated with the selection. 62518 1 ayg 2012-01-10 21:15:47 +0000 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. 62552 2 ayg 2012-01-11 17:12:49 +0000 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 62570 3 ayg 2012-01-11 19:35:25 +0000 (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 104121 4 benjamp 2014-04-21 21:07:29 +0000 Moving to Selection API component. 111570 5 rniwa 2014-09-16 01:20:54 +0000 Reopening the bug per https://bugzilla.mozilla.org/show_bug.cgi?id=671152