14591 2011-10-28 19:35:39 +0000 Get rid of Range.detach() 2012-12-04 11:45:06 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED FIXED P2 enhancement --- 14842 1 ayg annevk bugs bzbarsky mats mike Ms2ger rniwa timdown www-dom public-webapps-bugzilla oldest_to_newest 59141 0 ayg 2011-10-28 19:35:39 +0000 It's absolutely useless, and it adds a line to every single Range attribute and method definition. Skimming Code Search turns up no usage of Range.detach() in the first few pages (jquery/mootools omitted because they define methods by that name that occur a lot): http://www.google.com/codesearch#search/&q=lang:%5Ejavascript$%20function:%5Edetach$%20-file:(%5E%7C/)jquery.*%5C.js$%20-file:mootools%5C.js$&type=cs Are implementers willing to drop support here? Are there sites that actually use it? I find four crash bugs in Gecko when searching for "range detach", so clearly enough people must be using it for those to get reported. If that's too big a compat risk, can we make it a no-op? 59682 1 bugs 2011-11-07 16:20:44 +0000 It might be worth trying this, but perhaps implementations should first warn about deprecated method for few releases, then make detach no-op, and the after few releases remove the method. 59683 2 bugs 2011-11-07 16:22:47 +0000 Or, could we make detach more useful, like detaching range automatically from selection. 60062 3 mats 2011-11-16 04:01:33 +0000 (In reply to comment #0) > I find four crash bugs in Gecko when searching for "range detach", so > clearly enough people must be using it for those to get reported. I found 5 Gecko crash bugs involving Range.detach(), all of which were found by fuzz testing tools, so you shouldn't take those as an indication that detach() is used much on the web. (In reply to comment #1) > warn about deprecated method for few releases, then > make detach no-op, and the after few releases remove the method. This sounds like a good plan to me. (In reply to comment #2) > Or, could we make detach more useful, like detaching range automatically > from selection. I would like to remove detach(). 60070 4 ayg 2011-11-16 14:09:50 +0000 Could Mozilla or Google try just removing the method in nightlies/canaries and see if there are any complaints? It seems very unlikely based on available evidence that any sites are actually relying on it, so making it warn/no-op/etc. seems overly complicated. The point of nightlies is you can make changes that have a little compat risk, right? 60071 5 ayg 2011-11-16 14:22:02 +0000 Anne suggested I file a Gecko bug, so I did: https://bugzilla.mozilla.org/show_bug.cgi?id=702948 60072 6 bugs 2011-11-16 15:07:52 +0000 Nightly/Canary builds don't get enough testing, especially for intranet web apps. 67283 7 ayg 2012-05-03 11:31:24 +0000 Gecko is experimenting with making Range.detach() a no-op for Firefox 15. Currently it's in nightlies, and I don't think we've received any complaints of broken pages yet, but it's only been a few days. If it gets to stable and we still have no or almost no problem reports, I think it's definitely worth speccing it as a no-op. Removing it entirely is probably a bad idea. I've seen code (including in Gecko's own non-detach()-related test support code) that pointlessly calls detach() after it's done with the range and doesn't intend to use it again. Probably this is based on the theory that any associated storage can be freed at that point or something -- although Gecko never actually did that AFAICT. Ms2ger, Anne, are you okay with us updating the spec now to have an XXX about this? I'd wait a little longer before changing the spec to match Gecko, in case problems arise. 67287 8 annevk 2012-05-03 13:18:41 +0000 Just make it a no-op once we know enough. Intermediate update is not necessary. 79005 9 annevk 2012-11-28 16:28:20 +0000 Given that it's been many Firefox releases without complaints, I removed it since Aryeh is short on time: https://github.com/whatwg/dom/commit/5fc29db3e55d3b9b5b5ba62b12741636fd05d8ee Review appreciated: http://dom.spec.whatwg.org/#ranges 79006 10 bugs 2012-11-28 16:32:47 +0000 Gecko does have .detach(). It is just no-op. 79007 11 bugs 2012-11-28 16:33:49 +0000 ...which is what the spec says it should be doing :) 79008 12 annevk 2012-11-28 16:34:35 +0000 As does the spec. I meant I removed the detached flag. 79017 13 timdown 2012-11-28 17:11:11 +0000 I'm in favour of getting rid of detach() because its existence is confusing, but I still have some residual confusion. I had assumed that the reason for detach()'s existence was because a range needs to observe the DOM in order to update itself when the DOM changes, which must have some performance implication. Was I mistaken? If not, is the process of detaching a range now handled when the range is garbage collected? 79397 14 ayg 2012-12-04 11:45:06 +0000 Yes, in theory detaching a range avoids the need for it to be informed of DOM changes, but in practice JS relies on garbage collection for this. The whole point of a garbage-collected language is that authors shouldn't have to manually release resources.