312092 - Accessible hierarchy incomplete/incorrect

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Willie Walker]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5
Build Identifier: Firefox 1.5 Beta 2

When examining the Firefox hierarchy when using AT-POKE, I can only see
the following components (parent first, children next):

Gecko (role=application)
   Mozilla Firefox Start Page - Mozilla Firefox Beta2 (role=frame)
     <no name> (role=panel)

I should be able to go much deeper than this.

Furthermore, when I get an AT-SPI event from Firefox and examine the 
hierarchy upwards from the event source, I cannot get to the top level
application object.  Instead, the top level object is one who's role is
"invalid."  Here's an example when looking at slashdot (children first,
parents next).  In this output, the string in parentheses is the name of
the object and the trailing string is the accessible role as reported by
the AT-SPI:

--> parent=(Slashdot: News for nerds, stuff that matters) html container
--> parent=() panel
--> parent=() scroll pane
--> parent=() panel
--> parent=(Slashdot: News for nerds, stuff that matters - Mozilla Firefox Beta 2) frame
--> parent=(Mozilla) invalid
--> obj=(Mozilla) parent=(None)

I should be able to get to the Application object and should also not encounter any
objects with invalid role names.


Reproducible: Always

Steps to Reproduce:
1. Run Firefox
2. Run AT-POKE
3. Examine Firefox hierarchy using AT-SPI


Actual Results:  
Shown above

Expected Results:  
I should be able to get a much more detailed hierarchy when moving down the parent/child relationship 
in Firefox using AT-POKE.

When I get an event from Firefox, I should be able to go up the hierarchy and reach the application 
object.

Comment 1

[Ginn Chen]

Willie, which Linux distribution are you using?

I think it may be related to some other Gecko programs installed.
I can't reproduce this issue on debian/ppc, at-poke is fine with firefox trunk.
But I can reproduce this issue on JDS 3.
I found a workaround, 
1)turn off "Enable assistive technologies", and re-login
2)export GNOME_ACCESSIBLITY=1, run firefox

You can try it and check out whether it works for you too.

Comment 2

[Willie Walker]

Thanks for the response!  It does seem to be some odd interaction with
GTK_MODULES.  After you pointed me in this direction, I did some experimenting
and came up with this:

0) Set GTK_MODULES=:gail:atk-bridge:
1) Run firefox.  You will get these warnings:

   [wwalker@fedora firefox]$ export GTK_MODULES=:gail:atk-bridge:
   [wwalker@fedora firefox]$ ./firefox
   GTK Accessibility Module initialized

   (Gecko:11340): GLib-GObject-WARNING **: gsignal.c:1072: unable to lookup
signal "activate" of unloaded type `MaiAtkObject'

   (Gecko:11340): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion
`signal_id > 0' failed

2) Run at-poke.  Firefox shows up as "Gecko."
3) Double click on Gecko and expand its
   hierarchy in the resulting window

When you do #3, you will see only three objects.  When you unset
GTK_MODULES, Firefox shows up as "Mozilla" and the hierarchy seems
to look fine.

I'm not quite sure what to do here.  Is the bad interaction with GTK_MODULES a
bug or an end user error?

Comment 3

[Ginn Chen]

Thanks for pointing this out!

set "GTK_MODULES=:gail:atk-bridge:" causes this issue, and unset can avoid it.
I reproduced on debian/ppc.

I also noticed when AT is enabled, debian and FC4 don't set "GTK_MODULES=:gail:atk-bridge:".

I need some investigation to know whether it is a bug of JDS3 or Firefox.

Comment 4

[Ginn Chen]

FYI:
This is the fix we did with JDS Mozilla 1.7.
in mozilla.sh.in add following lines.

##
## Reset GTK_MODULES, strip gail, atk-bridge if exists
##
GTK_MODULES=`echo $GTK_MODULES | sed -e 's/\<gail\>//g' -e 's/\<atk\-bridge\>//g'`
export GTK_MODULES

Comment 5

[Ginn Chen]

Snip from http://www.baum.ro/gnopernicus_files/go_gnome

#if you want to use gnopernicus with GTK toolkit applications 
#uncomment the next line and comment the "export GTK_MODULES=" line, and vice-versa

#export GTK_MODULES="gail:atk-bridge:gail-gnome"

#if you want to use gnopernicus with nautius, mozilla, StarOffice, gnome-cd, gnome-calculator
export GTK_MODULES=

Comment 6

[Ginn Chen]

When set GTK_MODULES=:gail:atk-bridge: before run firefox/mozilla,
I got
(Gecko:29510): GLib-GObject-WARNING **: gsignal.c:1069: unable to lookup signal "activate" of unloaded type `MaiAtkObject'

(Gecko:29510): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `signal_id > 0' failed

I think the problem is libatk-bridge.so loaded too early.

I didn't find a way to fix it inside mozilla/accessible/src/atk, a simple fix it remove atk-bridge from GTK_MODULES in run-mozilla.sh
Is it acceptable?

Comment 7

[Ginn Chen]

Attachment: strip atk-bridge in run-mozilla.sh

Comment 8

[Willie Walker]

Thanks!  This seems to solve the problem.  But...is this interaction something that can be avoided, or will one always need to make sure GTK_MODULES is not set (either by doing it on purpose or by using run-mozilla.sh)?

Comment 9

[Wan-Teh Chang]

Comment on attachment 203901 [details] [diff] [review]
strip atk-bridge in run-mozilla.sh

I am not familiar with accessibility or GTK, so I
should not review this patch.  I suggest that you
ask the "accessibility" or "GTK" module owners or
peers to review the patch.  You can find their names
in http://www.mozilla.org/owners.html.

> 	##
>+	## Reset GTK_MODULES, strip atk-bridge if exists
>+	## Mozilla will load libatk-bridge.so later if necessary
>+	##
>+	GTK_MODULES=`echo $GTK_MODULES | sed -e 's/atk-bridge//g'`
>+	export GTK_MODULES
>+	##
> 	## Run the program
> 	##

The comment should explain why you need to strip
atk-bridge.

After you strip atk-bridge, GTK_MODULES may contain
an extra colon (:).  Is that okay?

Comment 10

[Ginn Chen]

Checking in run-mozilla.sh;
/cvsroot/mozilla/build/unix/run-mozilla.sh,v  <--  run-mozilla.sh
new revision: 1.53; previous revision: 1.52
done

Comment 11

[Ginn Chen]

Comment on attachment 203901 [details] [diff] [review]
strip atk-bridge in run-mozilla.sh

Almost all the atk tools can't work correctly without this patch.
Risk is low.
We're used this patch for Sun Mozilla 1.7 for a long time.

Comment 12

[Benjamin Smedberg]

I'm trying to get rid of as many hacks from the shell scripts as possible and move them into the apprunner to make XULRunner launching saner: could we please do this environment-munging in nsAppRunner.cpp at the top of XRE_main instead of in the shell scripts?

Comment 13

[Ginn Chen]

I tried to setenv GTK_MODULES at the top of XRE_main(), it works fine.
Do we need to move the hacking now?

Comment 14

[Benjamin Smedberg]

I would prefer it, yes.

Comment 15

[Ginn Chen]

Attachment: patch (move to nsAppRunner.cpp)

Comment 16

[Benjamin Smedberg]

Comment on attachment 210840 [details] [diff] [review]
patch (move to nsAppRunner.cpp)

String passed to setenv() must be static, because on some OSes they are used directly in the environment table and not copied. I think leaking this string is fine, so just strdup(gtkModules) and manipulate that string directly.

(and gtkModules should be const char*)

Comment 17

[Ginn Chen]

Attachment: patch revised (move to nsAppRunner.cpp)

Comment 18

[Ginn Chen]

Checking in build/unix/run-mozilla.sh;
/cvsroot/mozilla/build/unix/run-mozilla.sh,v  <--  run-mozilla.sh
new revision: 1.55; previous revision: 1.54
done
Checking in xpfe/bootstrap/nsAppRunner.cpp;
/cvsroot/mozilla/xpfe/bootstrap/nsAppRunner.cpp,v  <--  nsAppRunner.cpp
new revision: 1.449; previous revision: 1.448
done
Checking in toolkit/xre/nsAppRunner.cpp;
/cvsroot/mozilla/toolkit/xre/nsAppRunner.cpp,v  <--  nsAppRunner.cpp
new revision: 1.130; previous revision: 1.129
done

Comment 19

[Ginn Chen]

Checking in xpfe/bootstrap/nsAppRunner.cpp;
/cvsroot/mozilla/xpfe/bootstrap/nsAppRunner.cpp,v  <--  nsAppRunner.cpp
new revision: 1.442.2.2; previous revision: 1.442.2.1
done
Checking in toolkit/xre/nsAppRunner.cpp;
/cvsroot/mozilla/toolkit/xre/nsAppRunner.cpp,v  <--  nsAppRunner.cpp
new revision: 1.113.2.5; previous revision: 1.113.2.4
done

Comment 20

[Shane Caraveo]

this broke solaris builds, see bug 327502