317475 - Top level window with focus should have "ACTIVE" state set

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Willie Walker]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

The top level windows never have their Accessible ACTIVE state set when they have focus, and they only sometimes have their FOCUSED state set.

Reproducible: Always

Steps to Reproduce:
1. Run Firefox and a gnome-terminal
2. Run the attached standalone python application in an xterm
3. Press Alt+Tab to give the gnome-terminal window focus.  Press F11
4. Press Alt+Tab to give the Firefox window focus.  Press F11
5. Click in the location text area at the top of the Firefox window.  Press F11.
Actual Results:  
Step 3: shows proper behavior: the gnome-terminal window has the ACTIVE state set
Step 4: shows improper behavior: one cannot tell if the Firefox window has focus
Step 5: Finally seems to give Firefox focus, but does not set the ACTIVE state


Expected Results:  
I'm guessing by emperical evidence that the window with focus should have its "ACTIVE" state set.

Comment 1

[Willie Walker]

Attachment: Run this standalone Python module to reproduce the bug.

This is a standalone python module that speaks pure AT-SPI IDL.

Comment 2

[Ginn Chen]

Hi Will,

I've a problem to let python aware KeyStroke in xterm. (in gnome-terminal is OK)
Do you know how to solve it?

Thanks.

Comment 3

[Willie Walker]

Hi Ginn:

Xterm is currently not an AT-SPI friendly application, and thus does not
emit AT-SPI events and device events.  

The ultimate solution to this is to use the XEvIE extension, which allows the
AT-SPI to grab keyboard events at a very low level.  Currently, however, 
XEvIE is not in wide use, and the AT-SPI implementation depends upon
higher level interception of keyboard events.

I'm curious, however, how xterm affects your ability to address this bug?

Will

Comment 4

[Ginn Chen]

(In reply to comment #3)
> I'm curious, however, how xterm affects your ability to address this bug?

Not a problem now.
I thought I had to type F11 in the window in which the script was running.
Silly me.

Anyway, I found the root cause in firefox's source.

Comment 5

[Ginn Chen]

Attachment: patch

Implementation of EXT_STATE_ACTIVE

Comment 6

[Aaron Leventhal]

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

Looks great.
Nit: just use 2 spaces for each indent level in the accessibility module (and most other modules).

Comment 7

[Ginn Chen]

Checking in nsRootAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/atk/nsRootAccessibleWrap.cpp,v  <--  nsRootAccessibleWrap.cpp
new revision: 1.6; previous revision: 1.5
done
Checking in nsRootAccessibleWrap.h;
/cvsroot/mozilla/accessible/src/atk/nsRootAccessibleWrap.h,v  <--  nsRootAccessibleWrap.h
new revision: 1.6; previous revision: 1.5
done

Comment 8

[Ginn Chen]

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

It's very hard to know if Firefox is the active app with this bug.
Risk is low.

Comment 9

[Ginn Chen]

Checking in src/atk/nsRootAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/atk/nsRootAccessibleWrap.cpp,v  <--  nsRootAccessibleWrap.cpp
new revision: 1.5.44.1; previous revision: 1.5
done
Checking in src/atk/nsRootAccessibleWrap.h;
/cvsroot/mozilla/accessible/src/atk/nsRootAccessibleWrap.h,v  <--  nsRootAccessibleWrap.h
new revision: 1.5.44.1; previous revision: 1.5
done