Closed
Bug 364274
Opened 18 years ago
Closed 18 years ago
Incorrect state for static text in wizard dialogs
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: monsanto, Assigned: evan.yan)
Details
(Keywords: access)
Attachments
(1 file)
(deleted),
patch
|
ginnchen+exoracle
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
Build Identifier: version 3 alpha 1 (20061218)
The Account Wizard dialog has an accessible child for each block of static text. Each page (Identity, Server Information, etc.) has its own static text to be displayed when the user hits the next or back button to go to the next or previous page. Assistive technologies, like Orca, need to speak the static text that's appropriate for the page the user is own. The problem is that the accessible state for all the static text includes SHOWING and VISIBLE, even though the text may not be either showing or visible. Orca should only read the text that is showing and visible, so it needs get the correct state for the text.
Reproducible: Always
Steps to Reproduce:
1. Start the Thunderbird Account Wizard
2. Launch at-poke and open the subtree under the Account Wizard.
3. Click on any of the static text nodes. You will see that they are all SHOWING and VISIBLE.
Actual Results:
See above.
Expected Results:
See above
Reporter | ||
Updated•18 years ago
|
Version: unspecified → Trunk
confirmed.
it's a common problem of all wizard dialogs.
changing component to core::disability access API
Status: UNCONFIRMED → NEW
Component: Account Manager → Disability Access APIs
Ever confirmed: true
Product: Thunderbird → Core
Summary: Incorrect state for Account Wizard static text → Incorrect state for widgets in wizard dialogs
Comment 2•18 years ago
|
||
2 issues here
1)element in a page under a deck should be grouped with each page.
2)element in non-current page under a deck should not be showing and visible
the cause of this bug:
nsXULTextAccessible::GetState() returns STATE_READONLY directly, and we treat widgets as VISIBLE once INVISIBLE state is not set.
for issue 1) mentioned in comment #2, I think bug 357969 talks about that, right?
Assignee: mscott → Evan.Yan
Summary: Incorrect state for widgets in wizard dialogs → Incorrect state for static text in wizard dialogs
Comment 4•18 years ago
|
||
(In reply to comment #3)
> the cause of this bug:
> nsXULTextAccessible::GetState() returns STATE_READONLY directly, and we treat
> widgets as VISIBLE once INVISIBLE state is not set.
it's nothing wrong^_^ not invisible means visible
(In reply to comment #4)
> it's nothing wrong^_^ not invisible means visible
>
yes, I just meant that nsXULTextAccessible::GetState() should return INVISIBLE state explicitly when the widget is invisible.
Comment 6•18 years ago
|
||
> yes, I just meant that nsXULTextAccessible::GetState() should return INVISIBLE
> state explicitly when the widget is invisible.
>
it's not related to nsXULTextAccessible::GetState(). xul element itself is visible, not invisible
Comment 7•18 years ago
|
||
(In reply to comment #6)
> > yes, I just meant that nsXULTextAccessible::GetState() should return INVISIBLE
> > state explicitly when the widget is invisible.
> >
> it's not related to nsXULTextAccessible::GetState(). xul element itself is
> visible, not invisible
>
my fault. i'd thought all accessible node is visible. in fact it's only for static text. sorry again.
Attachment #249907 -
Flags: review?(ginn.chen)
Comment on attachment 249907 [details] [diff] [review]
call parent's GetState()
since we touch here, we can change _retval to aState.
Attachment #249907 -
Flags: review?(ginn.chen) → review+
You need to log in
before you can comment on or make changes to this bug.
Description
•