10470 - find searches into list form controls

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[buster]

find should not search into list form controls.  for example, on this bugzilla
sumbission page, a search for DOM should result in a "nothing found" kind of
dialog, rather than matching DOM in Components.  This can be disconcerting since
the text matched often isn't visible.

Comment 1

[Simon Fraser [no longer active]]

Kin, I guess the Text Services document needs to have some smarts to deal with

this case.

Comment 2

[kinmoz]

Accepting bug. Setting Milestone to M11 with the rest of the
TextServices/SpellChecker bugs.

Comment 3

[buster]

sounds like this should get done in M12 as part of pre-beta cleanup work.

Comment 4

[rubydoo123]

not dogfood, but is beta necessary -- setting to M13

Comment 5

[kinmoz]

Moving to M14 with the rest of the TextServices/SpellChecker/Find bugs.

Comment 6

[Hixie (not reading bugmail)]

Actually, I disagree. It would be very useful, IMHO, to be able to search into
list form controls. The real problem is that we do not scroll the result into
view if it is not available, not that we find something at all.

Comment 7

[rubydoo123]

setting keyword

Comment 8

[leger]

Putting on PDT- radar for beta1.  Need for RTM, but not critical to beta.

Comment 9

[kinmoz]

Moving all non-beta1 bugs to M16 since I am going on sabbatical.

Comment 10

[rubydoo123]

moving to M18

Comment 11

[rubydoo123]

find should not bleed into option elements and possibly other form controls

Comment 12

[rubydoo123]

setting to nsbeta3+

Comment 13

[rubydoo123]

setting priority in status whiteboard

Comment 14

[rubydoo123]

setting to future and adding helpwanted

Need to triage bugs to meet the glidepath for pr3

Comment 15

[R.K.Aa.]

*** Bug 111601 has been marked as a duplicate of this bug. ***

Comment 16

[Diego Biurrun]

This also appears on Linux ---> OS=All

Comment 17

[Hixie (not reading bugmail)]

I still stand by my earlier question: why is this beg valid?

Comment 18

[Diego Biurrun]

I agree with you:

> The real problem is that we do not scroll the result into view if it is not  
> available, not that we find something at all.

We should either scroll this into view or not search into form controls.

Should we morph this bug or file a new one?

Comment 19

[rubydoo123]

removing myself from the cc list

Comment 20

[Jesse Ruderman]

Scrolling to and focusing the item makes sense for a normal listbox, but what do
you do if you find an <option> in a drop-down listbox?

See also bug 58305, "Find in page ignores text fields".

Comment 21

[Jesse Ruderman]

This sounds like the opposite of bug 63928, "Allow Find to work in
listboxes/option lists (SELECT form controls)".  Is this bug editor-specific?

Comment 22

[Kagami Rosylight [:saschanaz] (they/them)]

This does work but only on <select> with size attribute with its value > 1, on both Firefox and Chrome. Quite surprising to me, does the spec require this?

Comment 23

[Emilio Cobos Álvarez [:emilio]]

Find in page is not spec'd AFAICT.

But the main issue is how to highlight the user than the search hit is in the <option> element, as it's not visible by default.

Comment 24

[Emilio Cobos Álvarez [:emilio]]

This is the relevant check, fwiw.

Comment 25

[Kagami Rosylight [:saschanaz] (they/them)]

I can see highlight and Firefox even scroll down the <select> to show it, at least on Windows. Do you mean it doesn't on your machine or am I misunderstanding?

Comment 26

[Emilio Cobos Álvarez [:emilio]]

I mean for comboboxes:

<select>
 <option>A</option>
 <option>B</option>
</select>

Doesn't return a match for A or B.

Comment 27

[Kagami Rosylight [:saschanaz] (they/them)]

Oops, then I mean size=2 suddenly enables searching + highlighting.

<select size=2>
 <option>A</option>
 <option>B</option>
</select>

Comment 28

[Emilio Cobos Álvarez [:emilio]]

Yeah, that's expected, because now the <option>s are visible.

Comment 29

[Kagami Rosylight [:saschanaz] (they/them)]

I confused this bug with Bug 63928. The problem here was <select size=2> does not scroll, but now it does. I guess this can be closed then.

Mozregression says search had been disabled and then enabled again with proper scrolling on 2018-05-31 build.

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e60600aa79f
[components] For https://github.com/mozilla-mobile/android-components/issues/10470 - Add a new lastMediaAccess property for TabSessionState
https://hg.mozilla.org/integration/autoland/rev/3d0fb08d0aeb
[components] For https://github.com/mozilla-mobile/android-components/issues/10470 - Persist and restore lastMediaAccess of TabSessionState