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

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Nischal]

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.

Comment 1

[Nischal]

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

Comment 2

[Nischal]

thunderbird also has the same problem.

Comment 3

[alexander :surkov (:asurkov)]

(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?

Comment 4

[Nischal]

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.

Comment 5

[Nischal]

Attachment: shows expected behaviour

This shows the actual behaviour.

Comment 6

[Nischal]

Attachment: Firefox's behaviour

Comment 7

[Nischal]

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

Comment 8

[alexander :surkov (:asurkov)]

(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.

Comment 9

[alexander :surkov (:asurkov)]

confirm

Comment 10

[alexander :surkov (:asurkov)]

Attachment: 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.

Comment 11

[alexander :surkov (:asurkov)]

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

Comment 12

[alexander :surkov (:asurkov)]

(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 ;)

Comment 13

[Nischal]

does this fix the bug for thunderbird as well?

Comment 14

[Nischal]

(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.

Comment 15

[alexander :surkov (:asurkov)]

(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 16

[Marco Zehe (:MarcoZ)]

Comment on attachment 445993 [details] [diff] [review]
patch

r=me, thanks!

Comment 17

[Marco Zehe (:MarcoZ)]

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.

Comment 18

[alexander :surkov (:asurkov)]

(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

Comment 19

[alexander :surkov (:asurkov)]

Comment on attachment 445993 [details] [diff] [review]
patch

regression from Firefox 3.6, plain fix, has mochitests

Comment 20

[Marco Zehe (:MarcoZ)]

Regression from bug 178324. Without this fix, Firefox no longer behaves ATK-compliant on Linux.

Comment 21

[LegNeato]

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.

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 445993 [details] [diff] [review]
patch

Approved for 1.9.2.9, a=dveditz for release-drivers

Comment 23

[Marco Zehe (:MarcoZ)]

Pushed with slight merges to 1.9.2 on Alexander's behalf: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/323adb1ff10a

Comment 24

[Nischal]

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

Comment 25

[alexander :surkov (:asurkov)]

(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