Status

()

Core
DOM: Core & HTML
6 years ago
2 months ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

(Blocks: 4 bugs, {dev-doc-needed, site-compat})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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?
(Reporter)

Comment 1

6 years ago
https://bugs.webkit.org/show_bug.cgi?id=64761

Comment 2

6 years ago
I think we should try to drop it.
Agreed

Updated

6 years ago
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?
(Reporter)

Comment 13

6 years ago
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....

Comment 15

6 years ago
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.

Updated

6 years ago
Keywords: dev-doc-needed
OS: Mac OS X → All
Hardware: x86 → All

Comment 16

6 years ago
j.j., IE doesn't seem to support this.
Did anyone talk with Moxiecode (TinyMCE creators)?

Comment 17

6 years ago
> 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

Updated

6 years ago
Blocks: 718911

Comment 18

6 years ago
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

6 years ago
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.

Comment 21

5 years ago
you say it's obsolete, but what is it obsoleted by?

Comment 22

5 years ago
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).
Duplicate of this bug: 734463

Updated

5 years ago
Blocks: 437721
Blocks: 750051

Comment 24

5 years ago
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.

Comment 26

4 years ago
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

4 years ago
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

4 years ago
Hope window.find should survive. Any window.highlight(str1, str2, ..., strX) impementation wanted (for example http://autotagcloud.com/)

Comment 29

4 years ago
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

4 years ago
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.

Updated

4 years ago
Blocks: 252855

Comment 31

3 years ago
It's been a while since this was touched. What is the current thinking on this?

Comment 32

2 years ago
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

2 years ago
Looking good, usage is ~0.0015%

Comment 34

2 years ago
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

2 years ago
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

Comment 36

a year ago
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

a year ago
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.

Comment 38

4 months ago
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?

Updated

2 months ago
Depends on: 1348409
You need to log in before you can comment on or make changes to this bug.