Closed
Bug 255317
Opened 20 years ago
Closed 8 years ago
Never lose focus if element/ancestor is hidden, destroyed or disabled
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
DUPLICATE
of bug 570835
mozilla1.9alpha8
People
(Reporter: aaronlev, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
This is spun off from bug 255187
If any element becomes unfocusable for any reason (destroyed, hidden or disabled
are the reasons I can think of right away), then the focus should automatically
advance to the next focusable item.
Reporter | ||
Updated•20 years ago
|
Priority: -- → P2
Updated•19 years ago
|
Target Milestone: --- → mozilla1.9beta
Reporter | ||
Comment 1•19 years ago
|
||
We've taken care of any cases where focus/keynav is totally locked up -> minor
Severity: normal → minor
Updated•15 years ago
|
QA Contact: keyboard.navigation
Comment 3•12 years ago
|
||
When focused element becomes hidden by CSS visibility, this bug can still be reproduced on current Nightly build.
> data:text/html,<input autofocus id="i"><input><script>window.addEventListener("load", function () { var i = document.getElementById("i"); i.style.visibility = "hidden"; setTimeout(function () { i.style.visibility = "visible"; }, 10000); }, false);</script>
This testcase sets focus to the first <input> and hide it at load event. 10 sec later, it's shown again. Even during it's hidden, I can edit the content of <input>.
Comment 4•12 years ago
|
||
This is covered by 570835 pretty much.
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•