Clicking the selected tab should not focus the tab bar

VERIFIED FIXED in Firefox 3.6a1

Status

()

defect
VERIFIED FIXED
11 years ago
2 years ago

People

(Reporter: jruderman, Assigned: enndeakin)

Tracking

(Depends on 1 bug, {verified1.9.1})

Trunk
Firefox 3.6a1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 5 obsolete attachments)

Clicking the selected tab should not focus the tab bar.  It's way too easy to do accidentally and gets in the way of basic keyboard commands like scrolling.  Meanwhile, it doesn't help keyboard-bound users at all.  I run into this at least once a week.

See also:

* Bug 333513, "tab bar shouldn't take focus (whether by clicking or tabbing) if Mac FKA is off".  Mark Pilgrim, Håkan Waara, and I started discussing this issue there, but then we realized the two bugs are separate.

* Bug 418521, "focus ring appears on mouse interactions".  If that bug is fixed before this one, this bug will become even more confusing than it currently is, because there will be no indication that you've entered an undesired mode.

* Bug 321023, which can be seen as a symptom of this bug.
The big problem is bug 418521: clicking a button should never give keyboard focus to it on mac! 

So at least we're consistent: we're doing it wrong for all widgets, including the tab bar...
>So at least we're consistent: we're doing it wrong for all widgets, including
>the tab bar...

Kind of, one issue is that we are drawing the focus ring incorrectly across the board (bug 418521).  My impression is that this bug, which isn't exactly the same, is that the tab bar shouldn't be able to take focus to begin with (regardless of if we are drawing the ring or not).
For 3.1 we can just use a simple fix for tabs. The full focus rings issue (bug 418521) which I attempted to fix is a bit flaky due to general focus code issues, so it seems better to leave that for now. I'll keep investigating though.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #364149 - Flags: review?(gavin.sharp)
I'm going to revert the order of the pseudoclasses in the selectors so that :focus which is quicker to check comes first, but I'll make that change locally before checkin.
Posted patch actually, do this now (obsolete) — Splinter Review
Attachment #364149 - Attachment is obsolete: true
Attachment #364154 - Flags: review?(mconnor)
Attachment #364149 - Flags: review?(gavin.sharp)
That way, the focus ring will still be drawn for right clicks, right?
If so: ew. No clicks, imo!
Comment on attachment 364154 [details] [diff] [review]
actually, do this now

looking good, r=me
Attachment #364154 - Flags: review?(mconnor) → review+
Comment on attachment 364177 [details] [diff] [review]
same as above but with a similar check for the contextmenu event

>+      <handler event="contextmenu">
>+        this.setAttribute("focusbymouse", "true");
>+      </handler>

Umm, but you can open the context menu with the keyboard.
Hmmm, true, maybe I'll just check in the first patch then and think about it some more.
Why not use the mousedown event regardless of the button?
AFAICT, this patch does not fix this bug.  Instead, it makes this bug much worse for keyboard-heavy users (by taking away the visual indication that focus is in the wrong place) and slightly less bad for mouse-only users (by taking away what to them is visual noise).  See my paragraph in comment 0 about bug 418521.
Posted patch add a test (obsolete) — Splinter Review
Attachment #364223 - Attachment is obsolete: true
Attachment #364415 - Flags: review?(mconnor)
Attachment #364154 - Attachment is obsolete: true
Attachment #364177 - Attachment is obsolete: true
Attachment #364415 - Attachment is obsolete: true
Attachment #365173 - Flags: review?(mconnor)
Attachment #364415 - Flags: review?(mconnor)
Comment on attachment 365173 [details] [diff] [review]
gavin pointed out that the state should be reset on dragstart as well

bouncing to gavin, won't have time in the next couple days, but this should be mostly ready to go
Attachment #365173 - Flags: review?(mconnor) → review?(gavin.sharp)
Comment on attachment 365173 [details] [diff] [review]
gavin pointed out that the state should be reset on dragstart as well

>diff --git a/browser/base/content/test/browser_bug462289.js b/browser/base/content

>+function step4()
>+{
>+  is(document.activeElement, tab1, "mouse on tab while focused still activeElement");
>+
>+  EventUtils.synthesizeMouse(tab2, 2, 2, {});
>+  setTimeout(step5, 0);
>+}
>+
>+function step5()
>+{
>+  is(document.activeElement, tab2, "mouse on another tab while focused still activeElement");
>+
>+  gBrowser.removeTab(tab1);
>+  gBrowser.removeTab(tab2);
>+
>+  finish();
>+}

Can you add a comment here that explains why this test passes? Something like:

// tabbox.xml's _selectNewTab is called from a setTimeout in a bubbling
// mousedown event listener, and focuses the current tab if another tab
// previously had focus
Attachment #365173 - Flags: review?(gavin.sharp) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #365173 - Flags: approval1.9.1?
No longer blocks: 418521
Depends on: 418521
Comment on attachment 365173 [details] [diff] [review]
gavin pointed out that the state should be reset on dragstart as well

a191=beltzner
Attachment #365173 - Flags: approval1.9.1? → approval1.9.1+
Three of the tests in browser_bug462289.js are failing on the Mac OS X unit test box on mozilla-central.  (There's only been one unit test cycle so far since this landed... i.e., since the second changeset that actually contained the unit test file landed.)
This bug appears to have broken at least one way that I use the tab bar: Before you could click on the currently focused tab to have it focused with the keyboard as well and then simply use the left and right arrows on the keyboard to switch between tabs. This was very useful in switching quickly between two different versions of a site looking at differences.

This may be "broken" behavior... but it is how it has been for quite a while and has a use to it.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090310 Minefield/3.2a1pre
(In reply to comment #21)
> This bug appears to have broken at least one way that I use the tab bar: Before
> you could click on the currently focused tab to have it focused with the
> keyboard as well and then simply use the left and right arrows on the keyboard
> to switch between tabs.

You can still get this behavior, you just need to focus it using the keyboard (e.g. using Cmd/Ctrl+K then Tab).
Blocks: 482801
No longer blocks: 482801
Depends on: 482801
(In reply to comment #7)
> If so: ew. No clicks, imo!

It's still possible to focus the tab bar by middle-clicking, see bug 482801 comment 1.
Keywords: fixed1.9.1
This Bugfix, breaks my workflow also.
There is utility in navigating along your tabs with arrows/scroll (plus many more when you modify with Cmnd & Fn keys).
I really hope that with this bugfix you don't break this "hidden" workings at all.

Yes I understand that (prior behavior) might be confusing, and needs to stop reacting on a mouse interactions. But we still need a way to focus on a tab for a laptop users (MacBook anyone?)

So I suggest use a modifier key to allow mouse(touchpad rather) click to focus on a tab.

Being I keyboard person, I'd even prefer a shortcut to focus on a tab.

I'm rather new to DOM, so can you please help me: give me a code for a keyconfig extension, so that it might focus a tab with keyboard shortcut only.

P.S. Yes I'll be using "Cmnd+K, then Tab" routine, though it's really awkward.
Depends on: 491178
verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 ID:20081201061100

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090517 Shiretoko/3.5b5pre ID:20090517031745
Status: RESOLVED → VERIFIED
Depends on: 501981
Given the wontfix bug 501981 that was changed on all platforms.
Flags: in-testsuite?
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Firefox 3.6a1
Depends on: 502049
Is it possible to undo this change?  I've been able to enable left and right arrow key tab scrolling with userchrome.css code.  However, the ability to scroll the actual page up and down has been lost.  

I enjoyed being able to focus on tabs with a mouse click, scrolling left and right through tabs, and moving a page up and down with the up/down arrow keys.

It is very frustrating a useful feature was disabled like this without a choice.
It is probably irritating to UI designers that I have to agree with paulreed this is one of the most useful "bugs" I have ever come across. Now you have "fixed" it. There is no longer a way to navigate between tabs with one key, which was a very VERY good feature. CTRL-SHIFT-TAB is not good. For those who "run into this once a week", I make use of it daily. Many people have complained about its removal for example http://support.mozilla.com/tiki-view_forum_thread.php?locale=de&comments_parentId=379294&forumId=1.

Can you please change this to an option in about:config? Hacking workarounds into every installation of Firefox use is not an option, I'm sure you will agree, even worse having to re-do the hack after every new version comes out.

I shall not update in a hurry to 3.5 on my laptop and shall just have to miss out on the pornsurfing mode.
... Having posted the comment I then finally found the click in search box-tab method, which is OK. A fairly good alternative although not obvious to most users. Apologies for the unnecessary post, I thought I had looked hard enough first.
(In reply to comment #29)
> ... Having posted the comment I then finally found the click in search box-tab
> method, which is OK. A fairly good alternative although not obvious to most
> users. Apologies for the unnecessary post, I thought I had looked hard enough
> first.

What you've found (Ctrl+K, then Tab) is only a workaround.
Yet code cleanup could take away this hole too, then we out of luck completely
Developers don't listen to user's voices ...
Download swifttabs add-on...Now if the crashing/not responding errors were fixed....
I used this bug *all* the time. Opening some forum categories, then going through them real fast with the cursor keys. Moving to the first/last tab with home/end real fast.

I do see the idea behind changing it, but please take my suggestion into consideration: doubleclick to select the tab. The first click does the same it does now, the second click gives the focus ring on the tab. I would be very very very happy if it could be made like that.
Depends on: 630140
Depends on: 1359991
You need to log in before you can comment on or make changes to this bug.