Closed
Bug 375746
Opened 18 years ago
Closed 18 years ago
Extra focus events on nsDocAccessible when some internal control really has focus
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: scott, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070327 Minefield/3.0a4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070327 Minefield/3.0a4pre
Firefox is firing extra focus events on accessibles that never receive user focus. For example, visual focus rectangle is never on the doc frame when switching between tabs or visual rectangle is never on frame.
See wiki addressing issue: http://live.gnome.org/LSR/FocusEvents
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Reporter | ||
Updated•18 years ago
|
Blocks: focuseventa11y
Assignee | ||
Comment 1•18 years ago
|
||
Similar to other browsers, we only draw the visual focus on the document frame when the user is tabbing. That's the only time they really need to see it, otherwise it's obvious enough. It's considered less than attractive to always have the visual focus rectangle sitting on the document frame, so it's an exception we make.
However, the focus is really there.
I don't see any other examples of items that are getting focus but shouldn't. Any reason to not mark this bug INVALID?
Reporter | ||
Comment 2•18 years ago
|
||
Why have focus on a frame ever? It is never able to have user input, thus should not be focusable.
Assignee | ||
Comment 3•18 years ago
|
||
It receives arrow keys etc. for scrolling.
Scott is talking about the top level window frame holding the chome and document. I think Aaron is talking about the document frame. Is that correct?
Assignee | ||
Comment 5•18 years ago
|
||
Okay, that might be a legit problem, However Scott said the doc frame in the bug summary.
Concerning the document frame...
Aaron, you seem to be indicating that we should expect there to be two focuses:
1) The document frame, for scrolling
2) The focused link or other form element in the page, for all other interactions
This is true when, for example, a link has focus. Up/down arrow scroll the page. Enter activates the link.
But it is not true for all widgets on a page. For instance, say the focus on a text area form control. Up/down arrow never scroll in this situation. They move the caret in the text box. Therefore, the one control that has the keyboard input focus is the text area. No input goes to the document frame in this case.
The same might be true for an ARIA widget. It might eat up/down arrow.
The real problem we're having, and the purpose of this discuss, is that we're getting far too many focus events that do absolutely nothing to tell us where the user's point of regard truly is and are nearly impossible to filter out because we get a different set of events depending on where the user's POR is now and where it will be after he/she performs an action (e.g. pressing Tab). See Scott's table linked from the original report.
Assignee | ||
Comment 7•18 years ago
|
||
Changing bug summary to reflect the real problem (after discussion on IRC).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•18 years ago
|
Summary: Extra focus events on accessibles that never receive user focus → Extra focus events on nsDocAccessible when some internal control really has focus
Assignee | ||
Comment 8•18 years ago
|
||
Fixed via checkin to bug 375747.
Assignee | ||
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•