Closed
Bug 431474
Opened 16 years ago
Closed 16 years ago
Document Accessibles not getting state_focused when they have focus.
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: mick, Assigned: aaronlev)
Details
(Keywords: access)
Attachments
(1 file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre Accessible objects representing documents, in both Thunderbird3 and Firefox3 do not get state_focused (at least according to MSAA) when they are actually focused. Reproducible: Always Steps to Reproduce: 1. Open a new tab in ff3 (something with no focusable items, such as about:blank). 2. Open Accessibility probe and find ff3 in the explorer pane. 3. In acc probe's event pane, select to watch for event_object_focus, and make sure that the states column is showing. 4. Start watching events. 5. Move back to ff3 and move focus to the document, 6. In accessibility probe note that the focus event for the document has no focused state. Actual Results: The document object has no state_focused. Expected Results: The document object, as it has the focus, should have state_focused. This bug is important to NVDA as it most of the time will only react to focus events on objects that have state_focused. This is to try and wead out a lot of redundant focus events in applications that may happen very quickly in succession, the only important one is where the focus actually is. NVDA does have exceptions to this rule, but it should be made a lot tighter. One major place this will help is in the Thunderbird3 message list when deleting a message. There are a few focus events fired on the deleted message, and then a focus event fired on the new message with focus. We would like to know that where ever we are in a Gecko app, we can rely on the fact that a focus event for the true object with focus, that true object with focus *will* have state_focused.
Comment 1•16 years ago
|
||
Currently, nsDocAccessible::GetState indeed does not check whether the document itself is the focused node. It only checks whether it is focusable. Can any of you look into this please? Thanks!
Comment 3•16 years ago
|
||
Ginn, what do you mean? Should the document not get focused state when running on Unix systems?
I mean this bug does not exist with ATK. On my box, I got focus, state-changed:focused events, and the document frame has focusable and focused stat.
Comment 5•16 years ago
|
||
Ginn, thanks for the clarification!
Assignee | ||
Comment 6•16 years ago
|
||
Assignee: nobody → aaronleventhal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #319069 -
Flags: review?(surkov.alexander)
Comment 7•16 years ago
|
||
Comment on attachment 319069 [details] [diff] [review] Safest fix. Copy unreached condition from nsAccessible::GetState(). Unreached because no nsIContent for document. This is safer and simpler than changing nsAccessible::GetState() r=me
Attachment #319069 -
Flags: review?(surkov.alexander) → review+
Comment 8•16 years ago
|
||
Comment on attachment 319069 [details] [diff] [review] Safest fix. Copy unreached condition from nsAccessible::GetState(). Unreached because no nsIContent for document. This is safer and simpler than changing nsAccessible::GetState() no risk
Attachment #319069 -
Flags: approval1.9?
Assignee | ||
Comment 9•16 years ago
|
||
Comment on attachment 319069 [details] [diff] [review] Safest fix. Copy unreached condition from nsAccessible::GetState(). Unreached because no nsIContent for document. This is safer and simpler than changing nsAccessible::GetState() Let's have Marco test before requesting review. Since this isn't a regression from Firefox 2 I want to make sure it doesn't break JAWS or Window-Eyes. It shouldn't, of course, but it's better to be 100% certain. Maybe they expect documents to never have focus, who knows.
Attachment #319069 -
Flags: approval1.9? → review?(marco.zehe)
Comment 10•16 years ago
|
||
Comment on attachment 319069 [details] [diff] [review] Safest fix. Copy unreached condition from nsAccessible::GetState(). Unreached because no nsIContent for document. This is safer and simpler than changing nsAccessible::GetState() I already did tests on both JAWS and Window-Eyes, and both are unaffected by this change in both Firefox and Thunderbird. I think we're good to go!
Attachment #319069 -
Flags: review?(marco.zehe)
Attachment #319069 -
Flags: review+
Attachment #319069 -
Flags: approval1.9?
Comment 11•16 years ago
|
||
Comment on attachment 319069 [details] [diff] [review] Safest fix. Copy unreached condition from nsAccessible::GetState(). Unreached because no nsIContent for document. This is safer and simpler than changing nsAccessible::GetState() a1.9=beltzner
Attachment #319069 -
Flags: approval1.9? → approval1.9+
Comment 12•16 years ago
|
||
Checking in accessible/src/base/nsDocAccessible.cpp; /cvsroot/mozilla/accessible/src/base/nsDocAccessible.cpp,v <-- nsDocAccessible.cpp new revision: 1.243; previous revision: 1.242 done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 13•16 years ago
|
||
Verified fixed in: *Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050506 Minefield/3.0pre *Thunderbird: version 3.0a1pre (2008050503)
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•