User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100529 Minefield/3.7a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100529 Minefield/3.7a5pre When "Search for text when I start typing" option is activated and I try to use the addons search, Firefox start searching in the page instead of search plugins. Reproducible: Always Steps to Reproduce: Activate "Search for text when I start typing" and try to search addons on new Firefox 3.7a5pre (Minefield) addons manager. Actual Results: Firefox started "Quick Find". Expected Results: It should start searching my addons. Well, it can be fixed by adding an exception to "about:addons".
Component: Preferences → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: preferences → add-ons.manager
Version: unspecified → Trunk
Reporter, I can't see that behavior. No quick find will be opened. Do you focus the search field in the addons manager or where is the focus when you start typing?
Confirming - found while testing for bug 569342; Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a5pre) Gecko/20100601 Minefield/3.7a5pre 1) Tools / Addons 2) Select search box 3) Type '/' findbar pops up. 0) Tools / Options / Advanced / General / Search for text when I start typing 3) Type anything in search box
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks. That regression started with the landing of the new ui.
(In reply to comment #1) > Reporter, I can't see that behavior. No quick find will be opened. On builds before bug 567309 was fixed it is likely that the findbar needed to have been opened previously in the session.
This will need fixed for all in-content chrome pages, not just the Addons Manager.
It works in about:config, and about:crashes. So I would assume it's related to the Add-ons Manager.
Hmm, wonder if those pages are just blacklisted somewhere.
*snip* We should add the Add-ons Manager too: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/findbar.xml#1374
No we should do something better. I've been speaking to Gavin about this already so I'll just get this finished off at some point.
Assignee: nobody → dtownsend
blocking2.0: --- → final+
Fixed by bug 569342
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
The underlying bug here may be bug 570230
Not fixed by bug 569342. It's still reproducible with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100610 Minefield/3.7a5pre
Status: RESOLVED → REOPENED
No longer depends on: 569342
Resolution: FIXED → ---
Target Milestone: mozilla1.9.3a5 → ---
(In reply to comment #12) > The underlying bug here may be bug 570230 This is now fixed by bug 570230 (bug 568429)
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Look like. Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a6pre) Gecko/20100616 Minefield/3.7a6pre
Status: RESOLVED → VERIFIED
Depends on: 570230
Target Milestone: --- → mozilla1.9.3a6
For testing search we will have a Litmus test. So how does it look like for an automated test?
(In reply to comment #17) > For testing search we will have a Litmus test. So how does it look like for an > automated test? I would think that the test in attachment 449289 [details] [diff] [review] would be sufficient.
(In reply to comment #18) > I would think that the test in attachment 449289 [details] [diff] [review] would be sufficient. Agreed on. No manual test is necessary here.
You need to log in before you can comment on or make changes to this bug.