cycling tabs using new Ctrl+Tab panel does not keep location bar focus

VERIFIED FIXED in Firefox 3.1a2

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: xtc4uall, Assigned: dao)

Tracking

({access, regression})

Trunk
Firefox 3.1a2
access, regression
Points:
---
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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)
Flags: blocking-firefox3.1?
(Reporter)

Comment 1

10 years ago
setting browser.ctrlTab.mostRecentlyUsed to false fixes this issue -> blocking Bug 395980 and CCing Dao for investigation.
Blocks: 395980
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
(Reporter)

Comment 4

10 years ago
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

Comment 5

10 years ago
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?
(Reporter)

Comment 6

10 years ago
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.
(Assignee)

Comment 7

10 years ago
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.
(Assignee)

Updated

10 years ago
Depends on: 450554
(Assignee)

Comment 8

10 years ago
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)
(Assignee)

Comment 9

10 years ago
(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?

(Assignee)

Comment 11

10 years ago
(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
(Assignee)

Updated

10 years ago
Attachment #333749 - Attachment is obsolete: true
Attachment #333749 - Flags: review?(enndeakin)
(Assignee)

Comment 12

10 years ago
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+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
Pushed as 17130:2b38ad6798cf.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
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?
Keywords: access
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.