1509488 - Ctrl+Shift+Tab doesn't work when focus is in the content area

Status: VERIFIED FIXED

Description

[Dão Gottwald [::dao]]

Looks like we need to handle this in the keydown handler as well (like tabbox does), instead of relying on <key>.

Comment 1

[Dão Gottwald [::dao]]

Attachment: Bug 1509488 - Use keydown handler instead of <key> for Shift+Ctrl+Tab. r=jaws

Comment 2

[Dão Gottwald [::dao]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=90b0b4699b489f9b765f0932604c46fb28d26929

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/40310bdbb670
Use keydown handler instead of <key> for Shift+Ctrl+Tab. r=jaws

Comment 4

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/40310bdbb670

Comment 5

[Dão Gottwald [::dao]]

Comment on attachment 9027169 [details]
Bug 1509488 - Use keydown handler instead of <key> for Shift+Ctrl+Tab. r=jaws

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: unclear. This is relevant now because of bug 1473595, but I think the regression is older

User impact if declined: Shift+Ctrl+Tab doesn't work consistently

Is this code covered by automated tests?: Unknown

Has the fix been verified in Nightly?: No

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): We're now handling Shift+Ctrl+Tab in the same event handler as Ctrl+Tab. Not really breaking new ground here.

String changes made/needed:

Comment 6

[fwollsen]

This (or a new unrelated bug with similar symptoms) still reproduces in latest Nightly 65.0a1 (2018-11-28) on OSX.

**[Prerequisites]:**
- Create a new Firefox profile, or reset the pref `browser.ctrlTab.recentlyUsedOrder` to it's default value (true)

**[Steps to reproduce]:**
1. Open the browser (tab 1)
2. Open a new tab (tab 2)
3. Open a new tab (tab 3)
4. Press Ctrl+Shift+Tab

**[Expected result]:**
- The browser should switch to the least recently used tab (being tab 2) - analogous to how Ctrl+Shift makes the browser switch to the most recently used tab (being tab 1 in this case)

**[Actual result]:**
- Nothing happens

**[Notes]:**
- This is regardless of whether or not the focus is in the content area, so it may be a new, unrelated bug to this one.

> Is this code covered by automated tests?: Unknown
> Needs manual test from QE?: No

Since this is a regression, would it be wise to add some automated tests or at least some steps to reproduce for manual tests? It concerns the new default behavior for new profiles after all.

Thanks again for your patience and pardon me if this is comment is out of context. Still trying to wrap my head around the intended behavior here, but having Ctrl+Shift+Tab not to anything at all is hopefully not it :)

Comment 7

[fwollsen]

> **[Expected result]:**
> - The browser should switch to the least recently used tab (being tab 2) - analogous to how Ctrl+Shift makes the browser switch to the most recently used tab (being tab 1 in this case)

Fudged the tab numbers. It should of course be:

**[Expected result]:**
- The browser should switch to the least recently used tab (being tab 1) - analogous to how Ctrl+Shift makes the browser switch to the most recently used tab (being tab 2 in this case)

Comment 8

[Dão Gottwald [::dao]]

(In reply to fwollsen from comment #6)
> **[Steps to reproduce]:**
> 1. Open the browser (tab 1)
> 2. Open a new tab (tab 2)
> 3. Open a new tab (tab 3)
> 4. Press Ctrl+Shift+Tab

As mentioned in bug 1501699 many times, you need to open enough tabs for the tab bar to overflow.

Comment 9

[Julien Cristau [:jcristau] (back on August 5)]

Comment on attachment 9027169 [details]
Bug 1509488 - Use keydown handler instead of <key> for Shift+Ctrl+Tab. r=jaws

make shift-ctrl-tab work reliably; approved for 64.0b14

Comment 10

[fwollsen]

> As mentioned in bug 1501699 many times, you need to open enough tabs for the tab bar to overflow.

Thanks, I did not know that this particular bug is still about the All tabs panel, which I agree could reasonably only be in play when the tab bar overflows. (Not when pressing Ctrl+Shift+Tab though, but that that is another store better discussed in the original bug on the topic: https://bugzilla.mozilla.org/show_bug.cgi?id=1384251#c4)

Happy to see swift action in squashing this particular bug and uplifting it to 64, nice work!

Comment 11

[Sebastian Hengst [:aryx] (needinfo on intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/307b6790d410

Comment 12

[Rares Doghi]

Hi, I managed to reproduce this issue on Windows 10 Firefox Beta 64.0b13 but I can no longer reproduce it in Firefox 64.0b14 or the latest Nightly 65.0a1 (2018-11-28). I will mark it accordingly.