462289 - Clicking the selected tab should not focus the tab bar

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Jesse Ruderman]

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.

Comment 1

[Håkan Waara]

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

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 3

[Neil Deakin]

Attachment: use an attribute to flag that a tab was mouse focused

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.

Comment 4

[Neil Deakin]

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.

Comment 5

[Neil Deakin]

Attachment: actually, do this now

Comment 6

[Dão Gottwald [:dao]]

That way, the focus ring will still be drawn for right clicks, right?

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

If so: ew. No clicks, imo!

Comment 8

[Mike Connor [:mconnor]]

Comment on attachment 364154 [details] [diff] [review]
actually, do this now

looking good, r=me

Comment 9

[Neil Deakin]

Attachment: same as above but with a similar check for the contextmenu event

Comment 10

[Dão Gottwald [:dao]]

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.

Comment 11

[Neil Deakin]

Hmmm, true, maybe I'll just check in the first patch then and think about it some more.

Comment 12

[Dão Gottwald [:dao]]

Why not use the mousedown event regardless of the button?

Comment 13

[Jesse Ruderman]

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.

Comment 14

[Neil Deakin]

Attachment: ok, let's try just this other hack which makes tabbrowser tabs nonfocusable on mouse clicks

Comment 15

[Neil Deakin]

Attachment: add a test

Comment 16

[Neil Deakin]

Attachment: gavin pointed out that the state should be reset on dragstart as well

Comment 17

[Mike Connor [: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

Comment 18

[:Gavin Sharp [email: [e-mail]]]

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

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 365173 [details] [diff] [review]
gavin pointed out that the state should be reset on dragstart as well

a191=beltzner

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 21

[Landon Abney]

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

Comment 22

[:Gavin Sharp [email: [e-mail]]]

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

Comment 23

[Joonas]

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

Comment 24

[Sam]

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.

Comment 25

[Aakash Desai [:aakashd]]

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

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Given the wontfix bug 501981 that was changed on all platforms.

Comment 27

[paulrreed]

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.

Comment 28

[Ian Thomson]

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.

Comment 29

[Ian Thomson]

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

Comment 30

[Sam]

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

Comment 31

[paulrreed]

Download swifttabs add-on...Now if the crashing/not responding errors were fixed....

Comment 32

[mailme667]

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.