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)

x86
Windows Vista
defect
Not set
normal

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.
Keywords: access
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!
not on UNIX
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.
Ginn, thanks for the clarification!
Assignee: nobody → aaronleventhal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #319069 - Flags: review?(surkov.alexander)
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 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?
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 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 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+
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
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.

Attachment

General

Created:
Updated:
Size: