This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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.
Or, could we make detach more useful, like detaching range automatically from selection.
(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().
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?
Anne suggested I file a Gecko bug, so I did: https://bugzilla.mozilla.org/show_bug.cgi?id=702948
Nightly/Canary builds don't get enough testing, especially for intranet web apps.
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.
Just make it a no-op once we know enough. Intermediate update is not necessary.
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
Gecko does have .detach(). It is just no-op.
...which is what the spec says it should be doing :)
As does the spec. I meant I removed the detached flag.
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?
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.