Element still remains focused after it goes to visibility: hidden
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
People
(Reporter: ailea, Unassigned)
References
()
Details
Attachments
(3 files)
Affected versions:
ALL
Affected platforms:
ALL
Steps:
- Launch Firefox with a new profile access: http://theswishlife.com/
- Scroll down and then click on the "Go to the top" red button (Bottom right).
- Scroll down again.
Actual result:
The "Go to the top" button remains black (focused) after step 3, like the button is still pressed.
Expected result:
The "Go to the top" button should become red again.
The issue is not reproducible on Chrome.
Please see the video attachment for a better understanding.
Regression range:
This is not a recent regression. The issue is also reproducible on Fx 65.
Reporter | ||
Comment 1•5 years ago
|
||
Comment 2•5 years ago
|
||
Focus traversal behavior suggests that the button remains focused in Chrome, too. I don't see a reason why focus wouldn't remain there. Since the styling differs, sending over to style system.
Comment 3•5 years ago
|
||
Pretty sure this is a focus handling issue. Here's a reduced test-case.
The element goes to visibility: hidden (which makes it unfocusable), and back again. We keep the focus but Chrome removes it. Not 100% clear what's the right thing to do here.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Hi,
I was able to reproduce this issue on Ubuntu 18 with Firefox version Nightly 76.0a1 (2020-03-17) (64-bit). Marking that flag as affected.
Comment 5•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Updated•5 years ago
|
Comment 6•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Created attachment 9130406 [details]
TestcasePretty sure this is a focus handling issue. Here's a reduced test-case.
The element goes to visibility: hidden (which makes it unfocusable), and back again. We keep the focus but Chrome removes it. Not 100% clear what's the right thing to do here.
Edgar, do you have thoughts about the right behavior here?
Comment 7•5 years ago
|
||
Per https://html.spec.whatwg.org/#focus-fixup-rule, this is a Gecko bug.
In a Document whose focused area is a button element, removing, disabling, or hiding that button would cause the page's new focused area to be the viewport of the Document. This would, in turn, be reflected through the activeElement API as the body element.
Comment 8•5 years ago
|
||
Hi,
I've tested this using Firefox Nightly version 77.0a1 (2020-04-13) (64-bit) for windows 7 x64 and I’m also able to reproduce the issue. Based on this I will mark each respective flag as affected.
Best,
Raluca
Comment 9•5 years ago
|
||
Latest Nightly 78 is also affected, updating flags.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•