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.

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.

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.

(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.

Neil, do you think you can review this? Gavin seems swamped, and you have the best understanding of how panels work anyway.

Pushed as 17130:2b38ad6798cf.

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

https://litmus.mozilla.org/show_test.cgi?id=7029 added to the Litmus FFT.