Closed
Bug 343903
Opened 18 years ago
Closed 18 years ago
Tools:Web Search (command-K) does not focus search box if no window is open
Categories
(Firefox :: Keyboard Navigation, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mark, Assigned: jminta)
References
Details
(Keywords: fixed1.8.1, regression, Whiteboard: [has patch])
Attachments
(1 file)
1.36 KB,
patch
|
Gavin
:
review+
asaf
:
superreview+
mconnor
:
approval1.8.1+
|
Details | Diff | Splinter Review |
When no window is open, pressing command-K or selecting Tools:Web Search should open a new window and focus the search box. This works properly on the 1.8.0 branch. On 1.8[.1], it does not work properly. The search box appears to be focused very briefly, but focus goes to the URL bar. Steps to reproduce: 1. Close all windows 2. Press command-K Expect: search box focus Observe: URL bar focus This bug is only manifested on the Mac, where the app may be running without any open windows.
Comment 1•18 years ago
|
||
The mac code attaches a load listener to the window and focuses the search box when it fires. (see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&rev=1.657#3055 ) I don't recall which code focuses the URL bar on a new load, but if it runs on a timeout which causes it to run after the load event, then this bug would occur. Is this consistently reproducible on the 1.8 branch, and consistently not on the 1.8.0 branch?
Comment 2•18 years ago
|
||
Gavin: In 1.5.0.x the focus call on the search bar is setTimeout'ed.
Updated•18 years ago
|
Flags: blocking-firefox2?
Comment 3•18 years ago
|
||
(In reply to comment #2) > Gavin: In 1.5.0.x the focus call on the search bar is setTimeout'ed. Yes, I know. That's why I asked whether it was consistently reproducible on both branches - if it's a timeout issue, then it could happen intermittently on both branches.
Updated•18 years ago
|
Flags: blocking-firefox2? → blocking-firefox2+
Assignee | ||
Comment 4•18 years ago
|
||
Moving things back into a timeout makes them work fine for me again.
Assignee: nobody → jminta
Status: NEW → ASSIGNED
Attachment #229848 -
Flags: superreview?(mconnor)
Attachment #229848 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•18 years ago
|
Whiteboard: [has patch]
Comment 5•18 years ago
|
||
Comment on attachment 229848 [details] [diff] [review] restore the timeout Oh, duh. I completely misunderstood Mano's comment, I was under the impression that it was still using a timeout.
Attachment #229848 -
Flags: review?(gavin.sharp) → review+
Comment 6•18 years ago
|
||
Comment on attachment 229848 [details] [diff] [review] restore the timeout r=mano
Attachment #229848 -
Flags: superreview?(mconnor) → superreview+
Assignee | ||
Comment 7•18 years ago
|
||
Landed on trunk Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.662; previous revision: 1.661 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•18 years ago
|
||
Comment on attachment 229848 [details] [diff] [review] restore the timeout For drivers: This patch fixes a regression in the searchbar. It has been on the trunk since Wednesday morning and carries very little chance of regression. The change here is essentially returning us to code that was used in 1.5
Attachment #229848 -
Flags: approval1.8.1?
Comment 9•18 years ago
|
||
Comment on attachment 229848 [details] [diff] [review] restore the timeout a=mconnor on behalf of drivers for checkin to the 1.8 branch
Attachment #229848 -
Flags: approval1.8.1? → approval1.8.1+
Assignee | ||
Comment 10•18 years ago
|
||
Landed on branch Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.479.2.167; previous revision: 1.479.2.166 done
Keywords: fixed1.8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•