Open Bug 10470 Opened 20 years ago Updated 10 years ago

find searches into list form controls

Categories

(Core :: Editor, defect, P3)

x86
All
defect

Tracking

()

Future

People

(Reporter: buster, Unassigned)

References

()

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: nsbeta3nsbeta1
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
You need to log in before you can comment on or make changes to this bug.