1600548 - If the all tab overflow popup / panel / menu scrolls, pressing the "home" key no longer scrolls the list (though the "end" key does)

Status: NEW

(Firefox :: Menus, defect, P3)

Description

[jochen_vortkamp]

Attachment: Screenshot_2019-12-02 08_58_47.png

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

Steps to reproduce:

Have many opened Tabs.
Click the Arrow down on top right of the Firefox window.
Try to go up to top open tabs by pressing "Pos 1".

My Version is: 68.2.0esr (64-Bit)

Actual results:

Nothing.
The selection windows stays where it it.

Expected results:

Selection windows should go up to the first opend Tab.
Insted I have to move to top by clicking with the mous on the slidebar very often.

This was working in the previous esr version.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
20191030021342

Works for me.

1. Can you reproduce this if you set Windows to one of the Aero themes instead of Classic (and restart Firefox if it's already running)?
2. Can you reproduce this in the latest Nightly, with the Windows Classic theme applied?

• https://www.mozilla.org/firefox/nightly/all/

(In reply to jochen_vortkamp from comment #0)

"Pos 1".

Note: that's the Home key on a German keyboard.

Comment 2

[:Gijs (he/him)]

Marco, this is ultimately going to be about keyboard nav in the toolbar and panels, but also seems to involve a German keyboard - it's possible we're checking the wrong keycode / key value or something. Can you check if you can reproduce, if you've got a German keyboard?

Comment 3

[Marco Zehe (:MarcoZ)]

Yes, I do have a German keyboard, but AFAIK, it doesn't generate a different key code than an English one. I've never seen a case where Home didn't work in the German layout where it did in the English.

Having said that, I also am not quite sure what overflow menu the user is referring to. Or in other words: How many tabs do I need to have open to actually get that? I have ten open now, but the 11th item is just one that opens a new tab. I want to make sure I actually see this particular overflow menu button, don't think I've ever encountered it before...

Comment 4

[Marco Zehe (:MarcoZ)]

^

Comment 5

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #3)

Having said that, I also am not quite sure what overflow menu the user is referring to. Or in other words: How many tabs do I need to have open to actually get that? I have ten open now, but the 11th item is just one that opens a new tab. I want to make sure I actually see this particular overflow menu button, don't think I've ever encountered it before...

If you resize your window to be narrower (ie less horizontal space), or open more tabs, it'll show up automatically. The quantity of tabs you need for it to show will depend on the window size and whether the tabs can fit visually without squashing them too much (at which point the tabs area becomes scrollable and this button shows up). On a 15" mbp at default screen resolution, for instance, I can open 19 tabs without scrolling / "list all tabs" button, but tab number 20 triggers "overflow" of the tab area and shows the button. The contents of the tabs don't matter, you can just hit ctrl/cmd-t repeatedly. Does that help?

Comment 6

[Marco Zehe (:MarcoZ)]

Yes, thanks, that helped. Can't reproduce. When initially clicking that Show All Tabs button, keyboard focus is not set on anything specific. But pressing Home takes me to that first button, End to the last tab I opened. The first actual tab is the fourth item from the top, below the Open Tab in Container button. But Home always goes to the first of the three buttons above the actual first tab. And End goes to the last tab. As expected. No problem in Nightly here.

Comment 7

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #6)

Yes, thanks, that helped. Can't reproduce. When initially clicking that Show All Tabs button, keyboard focus is not set on anything specific. But pressing Home takes me to that first button, End to the last tab I opened. The first actual tab is the fourth item from the top, below the Open Tab in Container button. But Home always goes to the first of the three buttons above the actual first tab. And End goes to the last tab. As expected. No problem in Nightly here.

Ah, hm, re-reading comment #0, I think I misread this bug report. This seems to be specifically about what the scrollable portion of the popup scrolls, if/when it's scrollable. I can repoduce that part, irrespective of keyboard layout. This is going to be a regression from bug 1446101 combined with our keyboard access work in those panels. The previous re-summarizing didn't really capture this. :-(

This happens because the first selectable item in the popup is either "undo close tab" or "search tabs", and pressing the home key then focuses that item, but because it is outside of the scrollbox and because the panel key navigation code stops propagation / prevents default handling of the key, the scrolling area of the box does not scroll. Note that if you then use arrow or tab keys to navigate down to the first item in the list, the box scrolls appropriately (ie home + arrow down + arrow down works in a window with no closed tabs to restore; you need an extra arrow down otherwise).

Page up/page down also still scroll the list (without affecting the keyboard-focused item).

We could:

1. do nothing. The behaviour as-is is arguably correct if using only the keyboard for selection etc.
2. make the home/end keys also scroll any scrollable area inside the same panel view. This may lead to issues with e.g. iframes from webextensions, if the extensions don't prevent the key from bubbling etc.
3. add a workaround specific to this panel.

Note that it seems, based on the steps in comment #0, that the user is specifically interested in combining keyboard and mouse navigation, so I'm not really convinced option (1) makes sense, but options (2) and (3) are ugly. :-(

Jamie, thoughts?

Comment 8

[jochen_vortkamp]

I activated Aero-Designs in my OS.
Now when i press "Pos 1" (Home), the field "Tab suchen" (search Tab?) is selected.
When i'm at top of the Tabs and press "End", it goes to the last tab as MarcoZ mentioned.

I i knew how, i would have attached a screenshot to this post.

Thanks,
Jochen

Comment 9

[jochen_vortkamp]

(In reply to :Gijs (he/him) from comment #7)

This happens because the first selectable item in the popup is either "undo close tab" or "search tabs", and pressing the home key then focuses that item, but because it is outside of the scrollbox and because the panel key navigation code stops propagation / prevents default handling of the key, the scrolling area of the box does not scroll. Note that if you then use arrow or tab keys to navigate down to the first item in the list, the box scrolls appropriately (ie home + arrow down + arrow down works in a window with no closed tabs to restore; you need an extra arrow down otherwise).

Page up/page down also still scroll the list (without affecting the keyboard-focused item).

Thanks you very much.
Exactly this.
I I am the only one who uses the browser linke this, option (1) "do nothing." is OK.
I'm fine with additional pressing the arrow down button.

Comment 10

[Gingerbread Man]

Restoring fields botched in comment 8…

(In reply to :Gijs (he/him) from comment #7)

This happens because the first selectable item in the popup is either "undo close tab" or "search tabs", and pressing the home key then focuses
that item, but because it is outside of the scrollbox and because the panel key navigation code stops propagation / prevents default handling of
the key, the scrolling area of the box does not scroll.

I didn't even see that as a bug. I had no expectation that the box would scroll since the item being selected is already in view.

Note that it seems, based on the steps in comment #0, that the user is specifically interested in combining keyboard and mouse navigation

Perhaps because the Ctrl+Shift+Tab keyboard shortcut that brings up the List All Tabs menu is not only obscure, but it also fails to work when browser.ctrlTab.recentlyUsedOrder is false. There's also an attempt to remove it in bug 505751.

Comment 11

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #7)

1. do nothing. The behaviour as-is is arguably correct if using only the keyboard for selection etc.

Maybe. While it's true that the top item is already in view, I think it's still pretty obscure that pressing home in a situation which uses only linear keyboard navigation (home, end, up, down, etc.) doesn't make the top items visible. Normally, separate scrollable thingies have separate tab stops and separate keyboard navigation.

Another approach here is to split the tab list into a separate single tab stop which has its own keyboard navigation. So if you're focused in the tab list, pressing home would take you to the top of the list and you'd have to shift+tab to get to the additional buttons like New Tab, etc. That would solve the problem, but it's non-trivial to implement and it has its own problems concerning intuitive UX.

2. make the home/end keys also scroll any scrollable area inside the same panel view. This may lead to issues with e.g. iframes from webextensions, if the extensions don't prevent the key from bubbling etc.

Do you mean if a user presses home/end while an iframe is focused, you're worried this will bubble up and get handled by the PMV key nav code? The PMV key nav code should only handle home/end for elements which aren't considered tab only (i.e. buttons, not iframes), so that should be okay. My bigger question here is how we detect eligible scrollable areas.

Comment 12

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #11)

Another approach here is to split the tab list into a separate single tab stop which has its own keyboard navigation. So if you're focused in the tab list, pressing home would take you to the top of the list and you'd have to shift+tab to get to the additional buttons like New Tab, etc.

To be clear, I'm not really suggesting this as a "practical" option. I noted it more to outline how this would normally be handled; e.g. normally, the scrollable area would be a "list box" and the buttons would be distinct from that. Changing the entire UX to fix this one use case probably isn't worthwhile.

Comment 13

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #11)

(In reply to :Gijs (he/him) from comment #7)

2. make the home/end keys also scroll any scrollable area inside the same panel view. This may lead to issues with e.g. iframes from webextensions, if the extensions don't prevent the key from bubbling etc.

Do you mean if a user presses home/end while an iframe is focused, you're worried this will bubble up and get handled by the PMV key nav code? The PMV key nav code should only handle home/end for elements which aren't considered tab only (i.e. buttons, not iframes), so that should be okay.

Ah, hm, so they shouldn't be affected then, which is good.

My bigger question here is how we detect eligible scrollable areas.

I think we can detect if the current focused node is inside such an area. At a minimum there's comparing scrollHeight with clientHeight through the ancestor chain, though ideally there'd be a way to do that without flushing layout...

Comment 14

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #13)

I think we can detect if the current focused node is inside such [a scrollable] area. At a minimum there's comparing scrollHeight with clientHeight through the ancestor chain, though ideally there'd be a way to do that without flushing layout...

Or we could just add a custom attribute to scrollable regions that need this behaviour...?

Comment 15

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #14)

(In reply to :Gijs (he/him) from comment #13)

I think we can detect if the current focused node is inside such [a scrollable] area. At a minimum there's comparing scrollHeight with clientHeight through the ancestor chain, though ideally there'd be a way to do that without flushing layout...

Or we could just add a custom attribute to scrollable regions that need this behaviour...?

Yep, that'd work too. Off-hand, I think that might just be this menu? I don't see a scrollable region inside anything else (as opposed to the entire view being scrollable), but I may well be missing something...