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)

x86
Linux
defect
Not set
normal

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.
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?
Why have focus on a frame ever? It is never able to have user input, thus should not be focusable.
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?
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.
Changing bug summary to reflect the real problem (after discussion on IRC).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Extra focus events on accessibles that never receive user focus → Extra focus events on nsDocAccessible when some internal control really has focus
Fixed via checkin to bug 375747.
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.