1689354 - display inline-block makes element focusable

Status: VERIFIED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Momen]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36

Steps to reproduce:

When the user wants to use the keyboard with the Firefox browser unexpected behavior occurs around . menu-button button.

If you press tab after the . menu-button button you don't come out on the next ‘test 2’ button as expected, but the focus seems to disappear. If you then press TAB two more times you do end up on ‘test 2’ button.

Our research showed that the span with the attribute data-email="long" has the css property display: inline-block and that makes this span focusable. The display inline-block on [data-email="long"] span is needed so that the long email hooks off behind the white gradient.

You can find a demo of the issue here:

https://jsfiddle.net/momenelkamri/6e9vh0nx/

Actual results:

display inline-block element is focusable

Expected results:

element with display inline-block are not focusable

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Our research showed that the span with the attribute data-email="long" has the css property display: inline-block and that makes this span focusable.

I don't think so. The cause must be the overflow-x: hidden.

Only when a (potentially) scrollable element is there, its overflow values are checked.
https://searchfox.org/mozilla-central/rev/f9ad45c76ba50bdee54bebd14e6625ae14d4d085/layout/generic/nsIFrame.cpp#10097,10104

But currently, we check both overflow-x and overflow-y.
https://searchfox.org/mozilla-central/rev/f9ad45c76ba50bdee54bebd14e6625ae14d4d085/layout/base/ScrollStyles.cpp#44-45

So, if I change the overflow-x: hidden to overflow: hidden, it works as (probably) as you expected.

enn: Is this an expected behavior? Or, it's caused by overflow became a shorthand of overflow-x and overflow-y?

Comment 2

[Momen]

Thanks, using overflow: hidden instead of overflow-x: hidden works for us in this use case

Comment 3

[Neil Deakin (away until Sept 6)]

Yes, any element that the user can scroll in either direction is focusable. This is also the case if only one direction has been specified as scrollable.

The example given here would be scrollable vertically if there was enough text placed inside it and its height was limited, so using overflow hidden (or clip) in both directions should be ok for this testcase.

I'm going to mark as invalid for now.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

(In reply to Neil Deakin from comment #3)

Yes, any element that the user can scroll in either direction is focusable. This is also the case if only one direction has been specified as scrollable.

The example given here would be scrollable vertically if there was enough text placed inside it and its height was limited, so using overflow hidden (or clip) in both directions should be ok for this testcase.

I'm going to mark as invalid for now.

Shouldn't it check the scrollable frame is actually scrollable or not?

Comment 5

[Neil Deakin (away until Sept 6)]

We always allow scrollable frames to be focused. That way, resizing them so the scrollbar appears and disappears doesn't change whether they can be focused or not.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Thank you for the explanation.