Bug 64761 – Let's kill window.find()

• Status: NEW
• Component: New Bugs

[Ian 'Hixie' Hickson]

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?

[Ian 'Hixie' Hickson]

https://bugzilla.mozilla.org/show_bug.cgi?id=672395

[Darin Fisher (:fishd, Google)]

I have no love for this feature, but how do we know that it is unused?

[Darin Adler]

(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.

[Ian 'Hixie' Hickson]

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.

[Daniel Bergey]

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.

[Oleg Mazko]

Hope window.find should survive. Also any window.highlight(str1, str2, ..., strX) impementation wanted for examle for such a projects http://autotagcloud.com/

[David Kilzer (:ddkilzer)]

This layout test, which tests window.find(), actually fails because it uses setTimeout() without waitUntilDone()/notifyDone():

LayoutTests/editing/execCommand/12244.html

I filed:

Bug 132230: LayoutTests/editing/execCommand/12244.html passes, but is actually failing
<https://bugs.webkit.org/show_bug.cgi?id=132230>

[David Vest]

As philipj writes in the corresponding Mozilla bug

https://bugzilla.mozilla.org/show_bug.cgi?id=672395

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

[Bora Ertung]

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.