Closed Bug 10470 Opened 25 years ago Closed 5 years ago

find searches into list form controls

Categories

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

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: buster, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [p:2])

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.
Assignee: sfraser → kin
Kin, I guess the Text Services document needs to have some smarts to deal with this case.
Status: NEW → ASSIGNED
Accepting bug. Setting Milestone to M11 with the rest of the TextServices/SpellChecker bugs.
Target Milestone: M12
sounds like this should get done in M12 as part of pre-beta cleanup work.
Blocks: 17753
Summary: find searches into list form controls → [BETA]find searches into list form controls
Whiteboard: [BETA code cleanup]
not dogfood, but is beta necessary -- setting to M13
Target Milestone: M12 → M13
Whiteboard: [BETA code cleanup] → [BETA-BLOCKER]
Whiteboard: [BETA-BLOCKER] → [BETA-BLOCKER] (py8ieh:potential candidate for css3 functionality)
Target Milestone: M13 → M14
Moving to M14 with the rest of the TextServices/SpellChecker/Find bugs.
Whiteboard: [BETA-BLOCKER] (py8ieh:potential candidate for css3 functionality) → [BETA-BLOCKER]
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.
setting keyword
Keywords: beta1
Summary: [BETA]find searches into list form controls → find searches into list form controls
Whiteboard: [BETA-BLOCKER]
Putting on PDT- radar for beta1. Need for RTM, but not critical to beta.
Whiteboard: [PDT-]
Target Milestone: M14 → M15
Moving all non-beta1 bugs to M16 since I am going on sabbatical.
Target Milestone: M15 → M16
moving to M18
Keywords: beta1
Target Milestone: M16 → M18
find should not bleed into option elements and possibly other form controls
Keywords: correctness, nsbeta3
Whiteboard: [PDT-]
setting to nsbeta3+
Whiteboard: nsbeta3+
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Whiteboard: [nsbeta3+] → [nsbeta3+][p:2]
setting to future and adding helpwanted Need to triage bugs to meet the glidepath for pr3
Keywords: helpwanted
Whiteboard: [nsbeta3+][p:2] → [nsbeta3-][p:2]
Target Milestone: M18 → Future
Keywords: nsbeta3 → nsbeta1
Whiteboard: [nsbeta3-][p:2] → [p:2]
Blocks: 104166
Blocks: 106961
*** Bug 111601 has been marked as a duplicate of this bug. ***
This also appears on Linux ---> OS=All
OS: Windows NT → All
I still stand by my earlier question: why is this beg valid?
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?
removing myself from the cc list
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".
This sounds like the opposite of bug 63928, "Allow Find to work in listboxes/option lists (SELECT form controls)". Is this bug editor-specific?
QA Contact: sujay → editor
Assignee: kinmoz → nobody
Status: ASSIGNED → NEW

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?

Flags: needinfo?(annevk)

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.

This is the relevant check, fwiw.

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?

Flags: needinfo?(emilio)

I mean for comboboxes:

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

Doesn't return a match for A or B.

Flags: needinfo?(emilio)

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

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

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

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.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Flags: needinfo?(annevk)
You need to log in before you can comment on or make changes to this bug.