Closed Bug 53882 Opened 25 years ago Closed 24 years ago

[access]focus should not go to hidden elements in a deck

Categories

(Core :: XUL, defect, P3)

x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla0.9

People

(Reporter: hewitt, Assigned: bryner)

Details

When tabbing around a form that uses a deck, the focus will disappear when it comes to the deck because the hidden elements in the deck still receive the focus. To reproduce, open the search tab on the sidebar in advanced mode. Set focus to the textfield and then tab until you get past the menulist. You will notice the focus suddenly disappear because it is going to the hidden tree in the deck that is used for the simple search mode. (Note that as of this post, there are many other focus problems that may obscure this one, but it is more obvious to me since I've fixed most of these issues in my build, but not checked them in yet.)
Just to clarify, what I'd like to see here to fix this is for the deck to set an attribute on it's children (such as hidden="true") to indicate whether they are currently visible or not. Then I could use this attribute to indicate that focus should be ignored.
Nevermind my previous suggestion, that won't solve anything. This is a deeper problem. The focus traversal algorithm currently used seems to just walk the tree in pre-order as you hit the Tab key and give focus to any element that doesn't explicitly deny it using CSS. I think to do this right we need more criteria than that. We need to also evaluate if the element in question is currently visible.
->saari, cc evaughan
Assignee: trudelle → saari
Yeah, this bug poped up before in a different context but got futured I think. I can certainly add a checks for visibility to the focus code. Just + it...
Status: NEW → ASSIGNED
future
Target Milestone: --- → Future
Affects accessiblity, target mozilla 0.9
Target Milestone: Future → mozilla0.9
Summary: focus should not go to hidden elements in a deck → [access]focus should not go to hidden elements in a deck
I was helping bryner look at this yesterday, and he seems to have it under control so I'm giving it him
Assignee: saari → bryner
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This is fixed now.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.