Last Comment Bug 672395 - Let's kill window.find()
: Let's kill window.find()
Status: NEW
: dev-doc-needed, site-compat
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: unspecified
: All All
: -- normal with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 734463 (view as bug list)
Depends on:
Blocks: 252855 437721 481513 718911 750051
  Show dependency treegraph
 
Reported: 2011-07-18 16:01 PDT by Hixie (not reading bugmail)
Modified: 2016-06-24 06:45 PDT (History)
36 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Hixie (not reading bugmail) 2011-07-18 16:01:45 PDT
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?
Comment 1 Hixie (not reading bugmail) 2011-07-18 16:02:21 PDT
https://bugs.webkit.org/show_bug.cgi?id=64761
Comment 2 Olli Pettay [:smaug] 2011-07-18 16:04:55 PDT
I think we should try to drop it.
Comment 3 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-07-18 16:15:32 PDT
Agreed
Comment 4 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-07-18 17:46:04 PDT
Removing obsolete bits of the web platform?  Sounds like something Ms2ger would like to do!
Comment 5 Boris Zbarsky [:bz] 2011-07-18 20:43:25 PDT
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.
Comment 6 :Ms2ger (⌚ UTC+1/+2) 2011-07-19 03:50:46 PDT
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.
Comment 7 Boris Zbarsky [:bz] 2011-07-19 06:49:31 PDT
Er.... I don't think we really want to break the find button and search/replace features in TinyMCE.....
Comment 8 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-07-19 09:25:16 PDT
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.
Comment 9 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-07-19 09:27:33 PDT
AIUI TinyMCE is pretty widespread on the web ...
Comment 10 Boris Zbarsky [:bz] 2011-07-19 09:33:08 PDT
Jonas, TinyMCE is not a site.  It's an editor widget that's widely used on lots of sites.
Comment 11 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-07-19 10:13:45 PDT
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.
Comment 12 Boris Zbarsky [:bz] 2011-07-19 10:34:12 PDT
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?
Comment 13 Hixie (not reading bugmail) 2011-07-19 12:24:25 PDT
One option is to shrink the API to just what TinyMCE needs, and then spec that.
Comment 14 Boris Zbarsky [:bz] 2011-07-19 12:39:12 PDT
Yeah, I have no problem with removing the interactive stuff and whatnot....
Comment 15 scathlock 2011-08-13 16:43:19 PDT
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.
Comment 16 Ronny Orbach 2011-12-27 01:20:22 PST
j.j., IE doesn't seem to support this.
Did anyone talk with Moxiecode (TinyMCE creators)?
Comment 17 j.j. 2011-12-27 05:22:39 PST
> 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
Comment 18 Jaroslav Benc 2012-01-17 23:06:01 PST
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.
Comment 19 Lars Gunther 2012-01-17 23:15:42 PST
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.
Comment 20 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-02-08 15:11:54 PST
See also bug 250409.
Comment 21 Sean Newman 2012-03-01 10:33:13 PST
you say it's obsolete, but what is it obsoleted by?
Comment 22 Tim Down 2012-03-03 08:54:02 PST
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).
Comment 23 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-03-09 12:07:01 PST
*** Bug 734463 has been marked as a duplicate of this bug. ***
Comment 24 Anton Khodakivskiy 2012-12-09 01:01:32 PST
Doesn't standard search/find (ctrl-f) also use window.find()?
Comment 25 Boris Zbarsky [:bz] 2012-12-09 07:35:57 PST
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.
Comment 26 John Holland 2013-03-07 22:30:04 PST
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
Comment 27 John Holland 2013-03-07 22:55:06 PST
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.
Comment 28 Oleg Mazko 2013-03-20 10:03:41 PDT
Hope window.find should survive. Any window.highlight(str1, str2, ..., strX) impementation wanted (for example http://autotagcloud.com/)
Comment 29 daniel 2013-08-16 17:03:08 PDT
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.
Comment 30 daniel 2013-08-16 17:04:01 PDT
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.
Comment 31 Ben Peters 2014-10-16 12:54:38 PDT
It's been a while since this was touched. What is the current thinking on this?
Comment 32 Philip Jägenstedt 2015-05-22 05:27:22 PDT
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 :)
Comment 33 Philip Jägenstedt 2015-05-28 08:37:48 PDT
Looking good, usage is ~0.0015%
Comment 34 Bora Ertung 2015-12-26 10:45:43 PST
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.
Comment 35 Bora Ertung 2015-12-26 23:54:43 PST
Completely removing a part of API which has been used for years just because its popularity would not be a good thing.
Comment 36 jsanchez1928 2016-06-24 06:38:08 PDT
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().
Comment 37 jsanchez1928 2016-06-24 06:45:25 PDT
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.

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