Open Bug 672395 Opened 12 years ago Updated 10 days ago

Let's kill window.find()

Categories

(Core :: DOM: Core & HTML, task, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
task

Tracking

()

People

(Reporter: ian, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: dev-doc-needed, site-compat) 

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.
Blocks: 481513
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....
It's bad idea to completely remove window.find. It's the only easy way to do complex search on web page by javascript. Every major browser except Opera has such kind of feature.
Keywords: dev-doc-needed
OS: Mac OS X → All
Hardware: x86 → All
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
http://msdn.microsoft.com/en-us/library/ms536422.aspx
Blocks: 718911
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:

http://www.dynamicdrive.com/dynamicindex11/findpage.htm

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).
Blocks: 437721
Blocks: 750051
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.
Please DON'T kill it! I VERY much need a find-in-page facility that can be actuated by using JavaScript to supply a value to a function! I write papers--essays--that I put on line and use find in page to substitute for an index. Since the 1990s I was using one that worked fine with NS and IE, but it used a Confirm box to step through selections on a page. The new Confirm dims the background and can't be moved, so it breaks my find-in-page facility that otherwise works fine. The new find() also works fine--EXCEPT
Please DON'T kill it! I VERY much need a find-in-page facility that can be actuated by using JavaScript to supply a value to a function! I write papers--essays--that I put on line and use find in page to substitute for an index. Since the 1990s I was using one that worked fine with NS and IE, but it used a Confirm box to step through selections on a page. The new Confirm dims the background and can't be moved, so it breaks my find-in-page facility that otherwise works fine. The new find() also works fine--EXCEPT that the Find dialog box cannot be closed automatically. If the user doesn't close it with Cancel, it remains open UNTIL EXITING FIREFOX, and a new search does not update it. It's name appears to be "find" but window.find.close() doesn't affect it. Try it at: http://www.biblekjv.com/cmt/tng/starttng.htm  Leaving the Find dialog box open makes subsequent searches impossible.  Please fix it! Thanks! Or show me how to make a window.find.close() work for it.
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.
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.
Blocks: 252855
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.
Keywords: site-compat
We use window.find() in our application in order to easily look for text that crosses node boundaries, for us it is specially useful for looking and highlighting text inside some intricate HTML documents that some conversion tools we use generate. It is a very useful feature for us, it will be bad if this just stop existing because the amount of people that uses it is not enough. We tried to built our own custom method to emulate the functionality of window.find(), but within these special HTML documents I'm mentioning, nothing we made worked as good as window.find().
I'm agree with Bora Ertung that the best solution is simplifying its implementation instead of killing it, maintaining of course its find and select functionality.
Chromium issue is https://bugs.chromium.org/p/chromium/issues/detail?id=695564

If this is spec'd, which stanard makes the most sense? Does the API depend on layout?
Depends on: 1348409
window.find() is a great feature and should definitely stay. But Firefox has a terrible bug (it could be related to cache too :( - https://bugzilla.mozilla.org/show_bug.cgi?id=1442466
FWIW, I filed https://github.com/whatwg/html/issues/3539 to track this standards-wise.
Priority: -- → P3
Depends on: 1358633
Type: defect → task

Since it hasn't been mentioned previously, apart from the websites and widgets mentioned above, popular addons like Vimium use window.find() to implement their 'find in page' feature (and hence also suffer from the bugs mentioned in the original post). AIUI, such usage would not be visible to the Blink use counter linked above.

For additional context, here are a few issues in Vimium and the source of them on window.find()'s side:

The full list of related issues is here, which may be useful when fixing/replacing window.find().

Please don't kill this unless replaced by something better. We use it in our XML editor.

Also Window.find() should allow searching while normalizing spaces (to search in a pretty printed documents), if this is not currently the case.

Not clear what the behaviour should be today when searching a string with spaces in the middle (such as "increase for 2010"). Should it match the same text found in the DOM but with many whites spaces (including newlines, tabulations, etc. thus) between the words?

Severity: normal → S3

I just found myself in a situation where I need the features window.find provides but it not being standard make a pain to test it against the 3 browsers to check it correctly works.

I do not know if this is the correct channel, but I would really appreciate a standardized way of search across nodes, that works equal or almost equal in all browsers.

You need to log in before you can comment on or make changes to this bug.