1490974 - Toolkit::Find Toolbar CTRL+F finding matches also inside <select>

Status: RESOLVED FIXED

(Core :: Find Backend, defect, P1)

Description

[Grzegorz Szostak]

Attachment: FirefoxWrongMatches.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180830143136

Steps to reproduce:

1. Open page where <select> elements are included ex.: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option
2. Press CTRL+F to open Find toolbar
3. Type anything that is selectable through <select> element ex:. "Dog"
4. Number of matches will not be correct 3 instead of 2 in my example as it is counting also text inside <select> elements.


Actual results:

Typing "Dog" in Find toolbar when on page: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option is giving 3 matches


Expected results:

I expected to see 2 matches as it was in previous versions of Firefox before ver.62. 

Many of my colleagues are using Firefox to browse our company intranet where at some pages we have many <select> elements and that makes impossible to find correct match with CTRL+F toolbar.

Comment 1

[Mike de Boer [:mikedeboer]]

I'm not sure if this is a bug at all, is it? The <option> elements are hidden from sight and require additional interaction to become visible only after specific user interaction. Therefore, find-in-page can not be used as a navigational tool, because it can't show you anything reasonable. I think it's entirely fair to not treat them as a find occurrence.

Comment 2

[Grzegorz Szostak]

(In reply to Mike de Boer [:mikedeboer] from comment #1)
> I'm not sure if this is a bug at all, is it? The <option> elements are
> hidden from sight and require additional interaction to become visible only
> after specific user interaction. Therefore, find-in-page can not be used as
> a navigational tool, because it can't show you anything reasonable. I think
> it's entirely fair to not treat them as a find occurrence.

Hi,
Yes I agree with you, option elements are hidden from sight therefore it should not be treated as a find occurrence but they are now. That is the clue I tried to explain in Bug Report, sorry if something was misleading. There are too many find occurrences happening when many <option> elements are on the site. My example only show one case like that but on some websites it may be impossible to navigate and search for certain words as Find toolbar will show all matches from <option> element.

Please look at other example:
https://www.w3schools.com/code/tryit.asp?filename=FVSQ2XXZVVFQ
Here is the video showing the problem: https://www.youtube.com/watch?v=C-5x7xJuOTI

In my opinion CTRL+F and text "Saab" should give 2 matches instead of 10.

Comment 3

[Mike de Boer [:mikedeboer]]

Aha! Thanks for the explanation, example and video! That's just great to work with :-)

Brad, I'm going to pass this along to you, again, if you don't mind. You've indeed taken on a very complex task, but I'm still super happy that you did.

Comment 4

[Brad Werth [:bradwerth]]

I'll sort it out.

Comment 5

[Brad Werth [:bradwerth]]

Attachment: Bug 1490974 Part 1: For find-in-page, prevent invisible nodes and option nodes from being included in find results. r?mikedeboer!

Comment 6

[Brad Werth [:bradwerth]]

Attachment: Bug 1490974 Part 3: Add a test that invisible text and text in option tags doesn't generate a find result. r?mikedeboer!

Depends on D10631

Comment 7

[Brad Werth [:bradwerth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff6b95e27dfa41fd46623e467ce95f3479fad8bf

Comment 8

[Daniel Holbert [:dholbert]]

Looks like this stalled -- any updates here?

Ritu just ran into a particularly bad case of this -- a page that reported 15 results for a find-in-page term, but they were all buried in <select> elements so none of them were actually visible.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (do find-in-page to search for 'aaa' or 'bbb')

Comment 10

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

If Experimenter tool is going to be widely used internally, a search for "pocket" on the landing page (https://experimenter.services.mozilla.com/?page=1) incorrectly returns 15 results, which are mostly found in email addresses from "all owners" drop down list.

My intent to find in page "pocket" on experimenter was to find any experiments related to pocket and the results returned will always be misleading if we don't fix this bug.

Comment 11

[Brad Werth [:bradwerth]]

Attachment: Bug 1490974 Part 2: Remove an assert that insists only editable elements can use independent selection.

Depends on D10631

Comment 12

[Brad Werth [:bradwerth]]

I think the updated patches get this working properly.

Comment 13

[Brad Werth [:bradwerth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ac07ed0d5ca571298e7932fa81df5a93d723493

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cdafab785845
Part 1: For find-in-page, prevent invisible nodes and option nodes from being included in find results. r=mikedeboer
https://hg.mozilla.org/integration/autoland/rev/330d7fe2bf6b
Part 2: Remove an assert that insists only editable elements can use independent selection. r=mikedeboer
https://hg.mozilla.org/integration/autoland/rev/81d7a246c2b0
Part 3: Add a test that invisible text and text in option tags doesn't generate a find result. r=mikedeboer

Comment 15

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/cdafab785845
https://hg.mozilla.org/mozilla-central/rev/330d7fe2bf6b
https://hg.mozilla.org/mozilla-central/rev/81d7a246c2b0