using the new panel (Bug 395980) the location bar focus is lost whilst cycling the tabs. STRs: - start Fx and create at least three tabs and focus within each the location bar - use ctrl+tab to cycle through the tabs exp.: focus is kept to location bar in each tab actual: focus is lost help on finding a regression range is highly appreciated. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080813032636 (tested with new profile, safemode)
setting browser.ctrlTab.mostRecentlyUsed to false fixes this issue -> blocking Bug 395980 and CCing Dao for investigation.
There is no difference with the old way of tab switching. The focus doesn't remain within the location bar.
Ok, it depends on if the cursor was set into the location bar before and which is saved for each tab separately. I can also confirm this on OS X.
OS: Windows XP → All
Hardware: PC → All
yeah, sorry for the low precision. STR should be: - start Fx and create at least three tabs and focus *the cursor* within the location bar in every tab - use ctrl+tab to cycle through the tabs
There was bug 445768 fixed yesterday (August 12) that would focus the location bar if only 1 tab was open and one pressed Ctrl+Tab. Did this problem you're seeing happen with the August 11 or August 12 builds as well? Maybe it's a regression from that bugfix?
nope, it's broken in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080811053724 Minefield/3.1a2pre too, so this is before checkin of bug 445768.
If you focus the location bar, click on another tab, and Ctrl+Tab back to the previous tab, focus does go back to the location bar. The problem is that opening the Ctrl+Tab panel removes focus from the location bar for the /current/ tab.
Created attachment 333749 [details] [diff] [review] patch This would fix it depending on bug 450554. I'm not sure why the code checks why focus was set on an element inside the panel, but this doesn't work for the Ctrl+Tab panel, as there's no element that can obtain focus.
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #333749 - Flags: review?(enndeakin)
(In reply to comment #8) > Created an attachment (id=333749) [details] > I'm not sure why the code checks why > focus was set on an element inside the panel, s/why focus was set/if focus was set/
(In reply to comment #8) > Created an attachment (id=333749) [details] > patch > > This would fix it depending on bug 450554. I'm not sure why the code checks why > focus was set on an element inside the panel Panels with noautofocus="true" don't clear the focus when the panel is opened. Those panels, or other panels may modify the focus while panel is open or during a popuphiding/popuphidden events. Which do you want? - focus to be lost when the panel opens and then restored when it is closed? - or focus to remain where it was while the panel is opened?
(In reply to comment #10) > Which do you want? > - focus to be lost when the panel opens and then restored when it is closed? > - or focus to remain where it was while the panel is opened? Since there's no reason why focus should be lost in the first place, I guess I really want the latter.
No longer depends on: 450554
Created attachment 333801 [details] [diff] [review] patch v2 -- don't clear the focus Neil, do you think you can review this? Gavin seems swamped, and you have the best understanding of how panels work anyway.
Attachment #333801 - Flags: review?(enndeakin)
Attachment #333801 - Flags: review?(enndeakin) → review+
Pushed as 17130:2b38ad6798cf.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1a2
Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080820020636 Minefield/3.1a2pre ID:20080820020636 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080820035100 Minefield/3.1a2pre ID:20080820035100
Status: RESOLVED → VERIFIED
Flags: blocking-firefox3.1? → in-litmus?
https://litmus.mozilla.org/show_test.cgi?id=7029 added to the Litmus FFT.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.