Browser-laptop: ctrl-shift-tab does not navigate active tab focus backwards

[petemill]

Description

whilst cmd-shift-[ works to navigate backwards, and ctrl-tab works to navigate forwards, ctrl-shift-tab keeps going back and forth backwards and forwards

Steps to Reproduce

1. Open multiple tabs
2. Use ctrl-tab to move focus to a subsequent tab
3. Use ctrl-shift-tab to move focus backwards to a previous tab
4. Use ctrl-shift-tab again to move focus backwards to another previous tab

Actual result:
Tab focus moves forward

Expected result:
Tab focus moves backwards

Reproduces how often: 100%

Brave Version

Brave 0.20.3
rev 10ec013
Muon 4.5.3
libchromiumcontent 62.0.3202.38
V8 6.2.414.23
Node.js 7.9.0
Update Channel developer
OS Platform macOS
OS Release 17.0.0
OS Architecture x64

Reproducible on current live release:
No

[bbondy]

does this reproduce with 0.19.x beta channel? Mainly I'd like to know because otherwise it should go in 0.19.x release 1.

[petemill]

@bbondy I cannot reproduce in 0.19.33 beta
[edit: must have been an issue, but it's not 100% reproducible, more like 90%]

[bbondy]

Please re-open if it becomes a problem

[petemill]

Still an issue for me in 0.19.61 actually @bbondy, also reported by someone else in https://github.com/brave/browser-laptop/issues/11636 (0.19.62)

[LaurenWags]

+1 from community: https://community.brave.com/t/ctrl-tabbing-cycling-through-tabs-broken-in-macos-brave-v0-19-70/9808

[petemill]

Still an issue in 0.19.70. The menu that the shortcut is attached to is fine (Window -> Select Previous Tab), it's just the keyboard shortcut that's intermittently, often, but unpredictably moving forwards instead of backwards

[eljuno]

+1 from community https://community.brave.com/t/ctrl-shift-tab-is-broken/9912?u=eljuno

[petemill]

Just to be clear this bug was not present in 0.18.x, but introduced with 0.19.x, so should it have a hotfix milestone @bsclifton ?

[bbondy]

Moved this to P3 and also moving to backlog until there's a fix we can uplift into here. We wouldn't block the release on here so no need to put it in this milestone pls.

[petemill]

This seems to have everything to do with the Menu, and having two items with the accelerators: Ctrl+Tab and Ctrl+Shift+Tab.

When they are defined in menu.js, the second one defined will 50% of the time fire the first one's action (I re-ordered the menu items and observed the same). If one of the shortcuts is changed to not involve tab (e.g. Ctrl+Shift+m) then the issue goes away.

This was working fine with Muon 4.4.28, introduced in afe71148f17ba03b4c2018a48ca42cabbc2ffe17, and fine right up to and including 0.19.48 released in a314b4e1c83cfbcc6b958bdc7ce6d00837c7cb4c. The commit after is the next version of Muon, 4.5.4 with Cr 62 (17018e721af2731a73257a01b10913166588c279) and that seems to be the first commit that the issue is present in (tested in 36445285828d143fcdbdc0582d59e2d8c6e98553 which is the next working commit). I'll try to see if anything relevant changed in muon then...

[andrewmusselman]

I'm seeing this too on:

Brave | 0.19.70
rev | d4b94c6
Muon | 4.5.9
libchromiumcontent | 62.0.3202.62
V8 | 6.2.414.32
Node.js | 7.9.0
Update Channel | Release
OS Platform | macOS
OS Release | 16.7.0
OS Architecture | x64

[fizzyfrosty]

Is it possible to move this up in priority? Not being able to navigate tabs via hotkeys is a gamebreaker for me, and I've had to manually downgrade each time after accidentally updating. I wonder if this is affecting other power users. If I didn't have the ability to decline updates, as a user I would be forced to use another browser.

[bbondy]

we'll get it in the next hotfix

[kjozwiak]

@fizzyfrosty, can you try the following alternatives as a workaround until this is fixed?

• Windows, macOS & Linux: ctrl + PgUp or PgDn
• macOS: command + option + left arrow or right arrow
• macOS: command + shift + [ or ]

Those should let you navigate through all your opened tabs.

[mr-z-ro]

I noticed this in the past few weeks as well.

Without having looked at the relevant code, this behavior appears to be consistent with a hypothetical scenario where a Brave developer interpreted "previous tab" as meaning the last tab that was active/displayed, as opposed to the tab to the left of the currently active one.

If that is the case, this is not necessarily a bug. That said, it is still not consistent with what users coming from other browsers would expect in terms of web browsing experience, and causes a slew of usability (or at least onboarding) issues.

Confirming that for now cmd+shift+[ and cmd+option+<- work as expected though.

[petemill]

@msgrasser don't worry, it's not caused by implementing 'last recently used' for tab keyboard shortcuts. It's definitely a bug and it's being looked at with high priority. Thanks!