Bug 64761 - Let's kill window.find()
Summary: Let's kill window.find()
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2011-07-18 16:01 PDT by Ian 'Hixie' Hickson
Modified: 2018-05-10 01:07 PDT (History)
20 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ian 'Hixie' Hickson 2011-07-18 16:01:01 PDT
window.find() has a number of bugs:

 - first argument being blank doesn't show a dialog like Gecko.
 - when aCaseSensitive is false, even "å" matches "a".
 - once find() has selected text in a text field, the next search restarts at the top of the page
 - aWholeWord has no effect
 - aSearchInFrames has no effect (unlike Gecko)
 - aShowDialog doesn't work (unlike Gecko)
 - calling window.find() on a loading doc doesn't work

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 Ian 'Hixie' Hickson 2011-07-18 16:01:43 PDT
Comment 2 Darin Fisher (:fishd, Google) 2011-07-19 11:08:41 PDT
I have no love for this feature, but how do we know that it is unused?
Comment 3 Darin Adler 2011-07-19 12:01:58 PDT
(In reply to comment #0)
>  - when aCaseSensitive is false, even "å" matches "a".

The idea is that the correct text-finding algorithm depends on the person using the computer. For many US users, this behavior is helpful.

I think this bug goes in a different category than the rest.

I don’t know whether websites are using this or not.

A relatively unimportant side note: We have used it for regression testing for the find machinery inside WebCore so if we did remove it we’d have to add some sort of testing hook. Removing this and reimplementing those tests would mean that these tests that currently run in the web browsers would instead work only inside a testing tool like DumpRenderTree.
Comment 4 Ian 'Hixie' Hickson 2011-07-19 12:24:50 PDT
Apparently the only known use of this is the TinyMCE editor, but it is quite widespread. One suggestion I raised on the Mozilla bug cited above is to shrink the API to the minimum required by that usage rather than dropping it altogether.
Comment 5 Daniel Bergey 2012-01-10 12:37:41 PST
This feature is useful for find-as-you-type implementations. As mentioned on the Mozilla bug, It'd be non-trivial to duplicate the functionality of .find() in pure JS.

It is, however, buggy and only partially-implemented. It'd be nice to have a nice native API for finding (and selecting?) text without the need for UI integration.
Comment 6 Oleg Mazko 2013-03-20 10:17:55 PDT
Hope window.find should survive. Also any window.highlight(str1, str2, ..., strX) impementation wanted for examle for such a projects http://autotagcloud.com/
Comment 7 David Kilzer (:ddkilzer) 2014-04-27 08:16:36 PDT
This layout test, which tests window.find(), actually fails because it uses setTimeout() without waitUntilDone()/notifyDone():


I filed:

Bug 132230: LayoutTests/editing/execCommand/12244.html passes, but is actually failing
Comment 8 David Vest 2015-05-22 05:48:41 PDT
As philipj writes in the corresponding Mozilla bug


the Blink use counter for this just reached the stable channel and should stabilize within a few weeks:

Comment 9 Bora Ertung 2015-12-26 23:54:35 PST
Instead of killing it, simplifying its implementation would make more sense. Interactive bits(find dialog etc.) aren't really needed for example. We exhaustively use find and select functionality it offers. The popularity metrics would not mean much because it is used one way or the other. Completely removing a part of API which has been used for years just because its popularity would not be a good thing.