Closed Bug 1490974 Opened Last year Closed 9 months ago

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

Categories

(Core :: Find Backend, defect, P1)

62 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: szostak, Assigned: bradwerth)

Details

Attachments

(5 files)

Attached image 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.
Component: General → Find Toolbar
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.
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Resolution: --- → INVALID
(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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Flags: needinfo?(mdeboer)
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.
Component: Find Toolbar → Find Backend
Flags: needinfo?(mdeboer) → needinfo?(bwerth)
Product: Toolkit → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'll sort it out.
Assignee: nobody → bwerth
Flags: needinfo?(bwerth)
Status: NEW → ASSIGNED
Priority: -- → P1

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.

Attachment #9045058 - Attachment mime type: text/plain → text/html

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.

Flags: needinfo?(bwerth)
Attachment #9021967 - Attachment description: Bug 1490974 Part 2: Add a test that invisible text and text in option tags doesn't generate a find result. r?mikedeboer! → Bug 1490974 Part 3: Add a test that invisible text and text in option tags doesn't generate a find result. r?mikedeboer!

I think the updated patches get this working properly.

Flags: needinfo?(bwerth)
Pushed by bwerth@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: Last year9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.