1579709 - Ctrl+Tab focuses the address bar with only one tab open and browser.ctrlTab.recentlyUsedOrder=false

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[elliottabarnes]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Tested on Windows 7 X64 with Firefox 69.

Before Firefox 69, when only one tab was open within a specific browser window, pressing the Ctrl + Tab keyboard combination did nothing. However, as of version 69, pressing this combo now forces the Address Bar to be displayed; pressing this combo again restores focus back to the tab content.

Actual results:

See above.

Expected results:

Could we consider restoring pre-69 behaviour, so that pressing the mentioned keyboard combo does nothing? I'm a screen reader user, and found it really useful to use this combo as a quick way to determine whether I had any other tabs open; it's not visually possible to see this information. Whilst I can still do this, using the above combo jumps me to the Address Bar if no other tabs are open, meaning that I then need to navigate back to the main page. Whilst this only takes a matter of a second to do, in my opinion it's more productive to keep pre-69 behaviour - unless there's a specific reason that this was changed.

Comment 1

[Daniel Bodea [:danibodea]]

I am attempting to reproduce the "old behavior" in Firefox Release v68.0.2 on Windows 10 and Windows 7. Could not reproduce focusing the address by pushing the "CTRL" + "TAB" keys when a single tab is present. Are you sure this behavior was present by default in builds before firefox69?

In which exact build did you reproduce this? Am I missing anything from the details needed?
Please install an old version and make sure you can still reproduce it in a new profile.

Thank you for your contribution!

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[elliottabarnes]

Apologies. Before version 69, pressing Ctrl + Tab didn't do anything - however, as of 69 pressing this combo now forces the Address Bar to gain focus. It's this change that I was asking about possibly reverting.

Thanks.

Comment 4

[Daniel Bodea [:danibodea]]

I finally understood what the issue is here: the reporter sais that in firefox69, firefox70 and firefox71, when only one tab is opened, if he presses the "CTRL" + "TAB" keys together, then the focus would move from the content section to the address bar and back.
He suggests that this behavior should be removed (as firefox68 works now, no action on pressing that key combo.)
I have confirmed this behavior on Windows 10 and Mac OS 10.13.6.

Comment 5

[Dão Gottwald [:dao]]

Could you help us find out when this regressed?

Comment 6

[Daniel Bodea [:danibodea]]

I have performed a (moz)regression and these are my results:
2019-09-18T12:05:04: INFO : Narrowed inbound regression window from [6c6b0bbf, 8f15ea3b] (3 builds) to [5a18f5c9, 8f15ea3b] (2 builds) (~1 steps left)
2019-09-18T12:05:04: DEBUG : Starting merge handling...
2019-09-18T12:05:04: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=8f15ea3b3223c91e84a671b7ad32916d62e1ca84&full=1
2019-09-18T12:05:05: DEBUG : Found commit message:
Bug 1555060 Convert <tabs> to a custom element

The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.

Differential Revision: https://phabricator.services.mozilla.com/D32855

2019-09-18T12:05:05: DEBUG : Did not find a branch, checking all integration branches
2019-09-18T12:05:05: INFO : The bisection is done.
2019-09-18T12:05:05: INFO : Stopped

Comment 7

[Dão Gottwald [:dao]]

Andrew, could you please take a look?

Comment 8

[Andrew Swan [:aswan]]

Sorry for the long delay, I'm not really sure what's up here. The event handler in question is:
https://searchfox.org/mozilla-central/rev/5cb522c7baba24e55874809e0e206b001494c1e9/toolkit/content/widgets/tabbox.js#124-160

When I set a breakpoint in that code with the Browser Toolbox, and press ctrl-tab, then event.keyCode is 17, but ShortcutUtils.jsm is looking for 9 (which is what I would expect for tab).

I'm having a hard time seeing a connection to bug 1555060 though, the patch mentioned above didn't touch this code. It did convert an old XBL keydown <handler> to a regular DOM event listener, if that somehow had the side effect of changing the behavior of the MozTabbox event listener, it is for reasons way beyond my understanding.

Brian, do you have any idea what's going on here?

Comment 9

[Brian Grinstead [:bgrins]]

Maybe the XBL <handler event="keydown" group="system"> somehow ended up with different keyCode than using addEventListener("keydown"). Mossop, do you know if this is likely/possible? For future reference, here's the old handler: https://hg.mozilla.org/integration/mozilla-inbound/rev/8f15ea3b3223#l4.1621.

I wonder if switching the listener to "keypress" instead of "keydown" would change anything here.

Comment 10

[Andrew Swan [:aswan]]

Er, sorry, I got a bit confused here, the event handler I mentioned above isn't actually invovled.
The actual problem is that newTab here is null:
https://searchfox.org/mozilla-central/rev/5cb522c7baba24e55874809e0e206b001494c1e9/toolkit/content/widgets/tabbox.js#794

Looks like this used to be checked for but it got dropped:
https://hg.mozilla.org/mozilla-central/rev/5f9198b156f7#l21.143

Comment 11

[Andrew Swan [:aswan]]

Attachment: Bug 1579709 Fix ctrl-tab with only one tab r=bgrins

Comment 12

[Brian Grinstead [:bgrins]]

Pushed to autoland

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da50dff5f11f
Fix ctrl-tab with only one tab r=bgrins

Comment 14

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/da50dff5f11f

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Is this something you think is safe to uplift for beta 14 (our last beta build before the release candidate)?

Comment 16

[Andrew Swan [:aswan]]

(In reply to Liz Henry (:lizzard) from comment #15)

Is this something you think is safe to uplift for beta 14 (our last beta build before the release candidate)?

Yes, I think the patch is unlikely to cause other unintended breakage.

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, thanks, if you request uplift today it can still make it into beta 14.

Comment 18

[Andrew Swan [:aswan]]

Comment on attachment 9099413 [details]
Bug 1579709 Fix ctrl-tab with only one tab r=bgrins

Beta/Release Uplift Approval Request

• User impact if declined: As described in the bug, annoying focus behavior when using ctrl-tab in a window that has only one tab
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Described in the bug
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is small and, from inspection, the risk of other unintended side effects is tiny.
• String changes made/needed: none

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9099413 [details]
Bug 1579709 Fix ctrl-tab with only one tab r=bgrins

Low risk, fix for recent regression, let's uplift for beta 14.

Comment 20

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/releases/mozilla-beta/rev/6a1daea605bf

Comment 21

[Rares Doghi, Desktop QA]

Hi, This issue is Verified as Fixed in Firefox Beta 70.0b14 and our Latest Nightly build on Windows 10, Mac OsX 10.14, and Ubuntu 18.04.