Open Bug 10470 Opened 20 years ago Updated 10 years ago
find searches into list form controls
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.
Kin, I guess the Text Services document needs to have some smarts to deal with this case.
Accepting bug. Setting Milestone to M11 with the rest of the TextServices/SpellChecker bugs.
sounds like this should get done in M12 as part of pre-beta cleanup work.
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
Whiteboard: [BETA-BLOCKER] → [BETA-BLOCKER] (py8ieh:potential candidate for css3 functionality)
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.
Summary: [BETA]find searches into list form controls → find searches into list form controls
Putting on PDT- radar for beta1. Need for RTM, but not critical to beta.
Moving all non-beta1 bugs to M16 since I am going on sabbatical.
Target Milestone: M15 → M16
moving to M18
Target Milestone: M16 → M18
find should not bleed into option elements and possibly other form controls
setting to 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
Whiteboard: [nsbeta3+][p:2] → [nsbeta3-][p:2]
Target Milestone: M18 → Future
*** 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?
Assignee: kinmoz → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.