window.find() has a number of bugs:
- first argument being blank unexpectedly shows a dialog, unlike WebKit.
- once find() has selected text in a text field, the next search restarts at the top of the page
- aWholeWord has no effect
- aWrapAround has no effect (unlike WebKit)
- window.find() on a display:none iframe raises an exception (unlike WebKit)
- the window.find() dialog UI is inconsistent with the Ctrl+F inline find feature.
That's just the bugs I found in the first few minutes of testing.
This legacy feature seems to have no real use case, is very poorly implemented, and is badly designed in the first place (six boolean arguments?). It's only implemented in Gecko and WebKit.
Can we drop it?
I think we should try to drop it.
Removing obsolete bits of the web platform? Sounds like something Ms2ger would like to do!
In this context does "drop" mean "make it throw an exception due to lack of such a method", or does it mean "make it a no-op"?
I'm totally on board with the latter. The former might in fact hurt in some situations.
Apparently Opera only has one bug reported about not supporting it at all ("Breaks the "find" button in TinyMCE (possibly also the search/replace feature)"), so we might very well be able to make it throw. Either is fine with me, though.
Er.... I don't think we really want to break the find button and search/replace features in TinyMCE.....
We can't keep a feature just because one site uses it. Especially one with this large and buggy implementation.
I say let's make the function put a warning in the error console but otherwise be a no-op. At some later point we can remove the function from idl and our code completely.
We'll have 3 months to evang the site after we branch for aurora.
AIUI TinyMCE is pretty widespread on the web ...
Jonas, TinyMCE is not a site. It's an editor widget that's widely used on lots of sites.
Sigh, so any suggestions? Seems very crappy to keep this API around just for what is essentially a single consumer.
One solution would be to contact the TinyMCE guys while also adding a deprecation warning any time the function is called. We can leave things in this state for X months to let TinyMCE come out with a new version and give people time to upgrade.
We should certainly start by contacting them... do these features using window.find() not work in IE with TinyMCE or is something else going on?
One option is to shrink the API to just what TinyMCE needs, and then spec that.
Yeah, I have no problem with removing the interactive stuff and whatnot....
j.j., IE doesn't seem to support this.
Did anyone talk with Moxiecode (TinyMCE creators)?
> j.j., IE doesn't seem to support this
If you refer to my platform changes, it indicates Mozilla's affected platforms.
Comment 15 apparently talks about IE's findText() method in it's TextRange object
I wouldn't expect it's just the TinyMCE, we have a closed source web-based IDE being developed for more than 3 years and our code editor uses window.find for some operations. If you want to drop it there should be an alternative which performs at least as well as the window.find() and moves the selection to the string if found.
We'd need to inform users to not upgrade to latest versions of FF if this happens if they can't update our software for any reasons. I'm a fan of the rapid release life cycle but to be honest it's been more pain than gain for us this year with Chrome and FF.
FYI, there are cut and paste scripts flowing on the Internet that uses this feature. I just removed one such script from a page of a customer. (And yes, it used browser sniffing too.) Here is another one, just as bad:
Dynamic Drive is probably the worst web site in existence when it comes to encouraging **** code. And it often shows up near the top on Google search results.
See also bug 250409.
you say it's obsolete, but what is it obsoleted by?
As I commented on the WHATWG mailing list thread about this, window.find() is the only simple way to do text searches for text that crosses node boundaries (e.g. matching the word "cheese" in HTML like <b>che</b><i>ese</i>). I think this is a valid use case and would only be obsolete if another API existed (similar, say, to the findText() method of IE's TextRange).
*** Bug 734463 has been marked as a duplicate of this bug. ***
Doesn't standard search/find (ctrl-f) also use window.find()?
It uses the same backend, but it doesn't actually call the find() method on windows. And even if it did, we could expose an internal API.
Hope window.find should survive. Any window.highlight(str1, str2, ..., strX) impementation wanted (for example http://autotagcloud.com/)
Oleg Mazko: You can build your own reliable method with Google Closure Library. Check goog.dom.getRawTextContent, goog.dom.getNodeAtOffset, goog.dom.Range.createFromNodes etc.
It's been a while since this was touched. What is the current thinking on this?
FWIW, the Blink use counter for this just reached the stable channel and should stabilize within a few weeks: https://www.chromestatus.com/metrics/feature/timeline/popularity/696
Hopefully usage is low :)
Looking good, usage is ~0.0015%
Instead of killing it, simplifying its implementation would make more sense. Interactive bits aren't really needed for example. We exhaustively use find and select functionality it offers.
Completely removing a part of API which has been used for years just because its popularity would not be a good thing.