Frame for firefox does not implement the state "active" when firefox is the active frame

RESOLVED FIXED

Status

()

Core
Disability Access APIs
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Nischal, Assigned: surkov)

Tracking

({regression})

unspecified
x86
Linux
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 .9-fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

In gnome desktop environment, we have AT-SPI which is used by assistive technologies. Currently firefox does support accessibility in linux. 

Whenever a frame is the currently activated frame, it takes the state "active" However, when firefox is the currently opened frame it does not assume the state of "active".

Reproducible: Always

Actual Results:  
Firefox frame does not take the state "active" when it is the activated frame.

Expected Results:  
Firefox frame should take the state "active" when it is the activated frame.
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
(Reporter)

Comment 1

8 years ago
Here is the link to ATK api for linux that gives details of the states: http://library.gnome.org/devel/atk/1.30/atk-AtkState.html
(Reporter)

Comment 2

8 years ago
thunderbird also has the same problem.
(Assignee)

Comment 3

8 years ago
(In reply to comment #0)

> Actual Results:  
> Firefox frame does not take the state "active" when it is the activated frame.

What does "when" mean actually? Do you listen accessibility events like active state change?
(Reporter)

Comment 4

8 years ago
The normal behaviour for a frame, in linux accessibility, is that if it is currently activated it should take the state "active" and when some other frame gets activated, that frame gets the state "active". So at any given point of time only one frame(among frames belonging to different applications) has the state "active".

I am a developer for an assistive software. At any given point of time, i search for a frame which is currently "activated". But since firefox(and thunderbird) never take the "active" state, these applications are never accessed by the software.
(Reporter)

Comment 5

8 years ago
Created attachment 445954 [details]
shows expected behaviour

This shows the actual behaviour.
(Reporter)

Comment 6

8 years ago
Created attachment 445955 [details]
Firefox's behaviour
(Reporter)

Comment 7

8 years ago
The above 2 attachments were created using an application called "accerciser" which can be used to see the accessibility states taken by different applications.
(Assignee)

Comment 8

8 years ago
(In reply to comment #4)
> The normal behaviour for a frame, in linux accessibility, is that if it is
> currently activated it should take the state "active" and when some other frame
> gets activated, that frame gets the state "active". So at any given point of
> time only one frame(among frames belonging to different applications) has the
> state "active".

Sure, I know. We expose active state on focused firefox window (or exposed). I need to figure out why it's not working.

(In reply to comment #7)
> The above 2 attachments were created using an application called "accerciser"
> which can be used to see the accessibility states taken by different
> applications.

Thanks. That what I've needed to know.
(Assignee)

Comment 9

8 years ago
confirm
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 10

8 years ago
Created attachment 445993 [details] [diff] [review]
patch

nsGlobalWindow::GetInterfacee() doens't allow to get docshell's doctreeitem interface, we should get webnagivation interface and then query to doctreeitem. But since nsRootAccessible is created for top window then we don't need to this. All we need is to get a window and compare it with active window.
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #445993 - Flags: review?(marco.zehe)
Attachment #445993 - Flags: review?(bolterbugz)
(Assignee)

Comment 11

8 years ago
must be regression from bug 178324 (http://hg.mozilla.org/mozilla-central/diff/cabb8925dcd3/accessible/src/base/nsRootAccessible.cpp).
(Assignee)

Comment 12

8 years ago
(In reply to comment #11)
> must be regression from bug 178324
> (http://hg.mozilla.org/mozilla-central/diff/cabb8925dcd3/accessible/src/base/nsRootAccessible.cpp).

Marco, you were reviewer ;)
(Reporter)

Comment 13

8 years ago
does this fix the bug for thunderbird as well?
(Reporter)

Comment 14

8 years ago
(In reply to comment #11)
> must be regression from bug 178324
> (http://hg.mozilla.org/mozilla-central/diff/cabb8925dcd3/accessible/src/base/nsRootAccessible.cpp).

I think it was working properly in the previous version of firefox. 
It must be a regression from bug 178324.
(Assignee)

Comment 15

8 years ago
(In reply to comment #13)
> does this fix the bug for thunderbird as well?

I didn't tested but I believe so. Accessibility support is a part of Gecko engine, in that way any Gecko-based application should be working.
Comment on attachment 445993 [details] [diff] [review]
patch

r=me, thanks!
Attachment #445993 - Flags: review?(marco.zehe) → review+
Comment on attachment 445993 [details] [diff] [review]
patch

Expanding my r+ to the code part and cancelling request for David to review. I also tested this patch locally on a build, although neither NVDA nor Orca seem to actively use this state currently.
Attachment #445993 - Flags: review?(bolterbugz)
(Assignee)

Comment 18

8 years ago
(In reply to comment #17)
> (From update of attachment 445993 [details] [diff] [review])
> Expanding my r+ to the code part and cancelling request for David to review. I
> also tested this patch locally on a build, although neither NVDA nor Orca seem
> to actively use this state currently.

thanks!

landed on 1.9.3 - http://hg.mozilla.org/mozilla-central/rev/abfa416fd41a
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
(Assignee)

Comment 19

8 years ago
Comment on attachment 445993 [details] [diff] [review]
patch

regression from Firefox 3.6, plain fix, has mochitests
Attachment #445993 - Flags: approval1.9.2.5?
Regression from bug 178324. Without this fix, Firefox no longer behaves ATK-compliant on Linux.
Keywords: regression

Comment 21

8 years ago
Comment on attachment 445993 [details] [diff] [review]
patch

We will not be taking this for 3.6.6. Moving approval request forward.

If you disagree, send me an email.
Attachment #445993 - Flags: approval1.9.2.7?
Attachment #445993 - Flags: approval1.9.2.6-
Attachment #445993 - Flags: approval1.9.2.5?
Blocks: 178324
Comment on attachment 445993 [details] [diff] [review]
patch

Approved for 1.9.2.9, a=dveditz for release-drivers
Attachment #445993 - Flags: approval1.9.2.9? → approval1.9.2.9+
Pushed with slight merges to 1.9.2 on Alexander's behalf: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/323adb1ff10a
status1.9.2: --- → .9-fixed
(Reporter)

Comment 24

6 years ago
This issue is reproducible in version 11.0 of firefox. Can you please re-open this issue and fix it as soon as possible?
(Assignee)

Comment 25

6 years ago
(In reply to Nischal from comment #24)
> This issue is reproducible in version 11.0 of firefox. Can you please
> re-open this issue and fix it as soon as possible?

please file new bug for this and refer to this one
You need to log in before you can comment on or make changes to this bug.