Closed Bug 743580 Opened 12 years ago Closed 10 years ago

firefox can't find libatk-bridge.so when its in a multiarch path

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32
Tracking Flags:
Tracking Status
firefox-esr31 --- fixed

People

(Reporter: tbsaunde, Assigned: tbsaunde)

References

Details

Attachments

(2 files, 3 obsolete files)

patch to detect gtk path v1.6 - after Mike's review
1.63 KB, patch
Details | Diff | Splinter Review
don't remove atk-bridge from GTK_MODULES during startup
1.88 KB, patch
ginnchen+exoracle
: review+
karlt
: review+
bkerensa
: approval-mozilla-esr31+
Details | Diff | Splinter Review 
Since I've debugged this once before I figure its high time I file a bug.

in a multiarch world libatk-bridge.so lives in /usr/lib/<tripplet>/gtk-2.0/modules/libatk-bridge.so not /usr/lib/gtk-2.0/libatk-bridge.so

in LoadGnomeModule() (accessible/src/atk/nsApplicationAccessibleWrap.cpp:819) we have the codethat tries to dl_open() usingthe nspr api for that libatk-bridge.so

Glandium you seem like a reasonable person to ask what the right solution is here.
Does setting the GTK_MODULES environment variable to "gail:atk-bridge" load the right modules?
So, you're running 32bit Firefox on 64bit Linux?

Does it work if you manually load the library?
Does any 32bit GNOME program work in this way?
(In reply to Mike Hommey [:glandium] from comment #1)
> Does setting the GTK_MODULES environment variable to "gail:atk-bridge" load
> the right modules?

it was set, when I tested this.

I can however fix the issue with  ln -s /usr/lib/x86_64_linux-gnu/gtk-2.0/modules/libatk-bridge.so /usr/lib/gtk-2.0/modules/libatk-bridge.so

I believe the issue is that PR_GetLibraryPath() returns "/usr/lib:/lib" and then we tac gtk-2.0/modules on the end of each of those, and so don't search in /usr/lib/x86_64_linux-gnu/gtk-2.0/modules/

(In reply to Ginn Chen from comment #2)
> So, you're running 32bit Firefox on 64bit Linux?

no, 64 bit firefox on 64 bit linux
The state of loading gtk modules at runtime is pretty sad.

However, I'm wondering if we really need to actively open these modules, when they probably are in GTK_MODULES already... (enabling gnome a11y does that, right?)

Trevor, would you mind trying again after removing active module loading from nsApplicationAccessibleWrap::Init (but keeping signals and type hooks)?
(In reply to Mike Hommey [:glandium] from comment #4)
> The state of loading gtk modules at runtime is pretty sad.
> 
> However, I'm wondering if we really need to actively open these modules,
> when they probably are in GTK_MODULES already... (enabling gnome a11y does
> that, right?)

yes, enabling a11y in gnome puts them in GTK_MODULES.
As for if we can remove this code I'm not sure we do various magical things that atleast accordingto the comments are to make our a11y be the prefered one instead ofthe gtk one so that our tree of accessible objects is exposed with ones from gtk embeded where needed.  However almost all ofthat code is from before me so, I'm nto really familiar with it.

> Trevor, would you mind trying again after removing active module loading
> from nsApplicationAccessibleWrap::Init (but keeping signals and type hooks)?

yeah, I can look at that.
(In reply to Mike Hommey [:glandium] from comment #4)
> The state of loading gtk modules at runtime is pretty sad.

This is for backwards compatibility, we strip atk-bridge from GTK_MODULES in nsAppRunner.cpp, because atk-bridge can only be init-ed once, we need to init it after we have take control, otherwise gail will be the only a11y toolkit of Firefox.

After GNOME 2.24.2, we have NO_AT_BRIDGE=1, we should no longer need to strip atk-bridge from GTK_MODULES.

(In reply to Trevor Saunders (:tbsaunde) from comment #3)
> I believe the issue is that PR_GetLibraryPath() returns "/usr/lib:/lib" and
> then we tac gtk-2.0/modules on the end of each of those, and so don't search
> in /usr/lib/x86_64_linux-gnu/gtk-2.0/modules/

See LoadGtkModule(GnomeAccessibilityModule& aModule)
We add ":/usr/lib64:/usr/lib" for x64 linux.
So we may want to add /usr/lib/x86_64_linux-gnu, too.
(In reply to Ginn Chen from comment #6)
> (In reply to Mike Hommey [:glandium] from comment #4)
> > The state of loading gtk modules at runtime is pretty sad.
> 
> This is for backwards compatibility, we strip atk-bridge from GTK_MODULES in
> nsAppRunner.cpp, because atk-bridge can only be init-ed once, we need to
> init it after we have take control, otherwise gail will be the only a11y
> toolkit of Firefox.
> 
> After GNOME 2.24.2, we have NO_AT_BRIDGE=1, we should no longer need to
> strip atk-bridge from GTK_MODULES.

Mmmm probably not old enough to rely on that :-/

> (In reply to Trevor Saunders (:tbsaunde) from comment #3)
> > I believe the issue is that PR_GetLibraryPath() returns "/usr/lib:/lib" and
> > then we tac gtk-2.0/modules on the end of each of those, and so don't search
> > in /usr/lib/x86_64_linux-gnu/gtk-2.0/modules/
> 
> See LoadGtkModule(GnomeAccessibilityModule& aModule)
> We add ":/usr/lib64:/usr/lib" for x64 linux.
> So we may want to add /usr/lib/x86_64_linux-gnu, too.

Except that will fix the problem for x86-64 only. Then there's also x86, ia64, mips, arm, etc. , and non-linux architectures too.
What could work, though, is to use the path containing the gtk+ library.
Looks like it would be possible to persuade gtk to load another module by
adding it to the list in the "gtk-modules" property of the default
GtkSettings.
(In reply to Karl Tomlinson (:karlt) from comment #8)
> Looks like it would be possible to persuade gtk to load another module by
> adding it to the list in the "gtk-modules" property of the default
> GtkSettings.

I saw that earlier, but unfortunately, the gtk-modules loading code is only triggered when adding a display.
Hi devs!

On my debian libatk-bridge.so is located under /usr/lib/i386-linux-gnu/gtk-2.0/modules. It's from python-pyatspi package required by orca (gnome screen reader). This excludes at-spi package that would place the file in expected location /usr/lib/gtk-2.0/modules.

So I have accessibility off in firefox. Looking for a portable solution. I'm new to dynamic link libraries under linux, however will try to investigate that. I don't want to fix my machine, but to fix it on all linuxes.
I have a sketch of a solution. Architecture triplet is returned by `dpkg-architecture -qDEB_HOST_MULTIARCH`. dpkg-architecture is a perl script which in a complicated manner extracts it from /usr/share/dpkg/triplettable and I don't see any easier way to get this triplet on Debian. I would like to prepare a patch that runs this command and adds the path /usr/lib/<triplet> to the library paths, what whould solve this bug. But do you find it acceptable to call another process before loading the library?

Adding accessibilty to Mozilla is already a big performance overhead, so adding this call should not bother as much. It would happen only when accessibility is requested. It may also be coded as a fallback, if finding the library without the triplet does not succeed, however it could complicate the code strongly.

The other approaches that I tried were:
A. Try to get the gtk modules path from gtk library. Not possible, it's done by private functions in gtkmodules.c file. And the library path itself is hardcoded at configure time.
B. Try to get library paths from ld.so system. The only solution I found would be to parse /etc/ld.so.conf file together with its includes - quite cumbersome. Seems like no utility exists which does that, although I've seen a patch for linux (can't find it now), so it will probably be possible in the future.

So, can I proceed with 'dpkg-architecture' solution?
More thoughts...

dpkg is probably debian specific. Maybe something else, still debian specific, but with some chance of being cross platform. A bit of a guess. How about parsing the lines beginning with slashes in all files from /etc/ld.so.conf.d? Those entries could be added to our library path list and do the job.

Actuall processing of ld.so.conf is more complicated. It accepts "include" command. That's why I suggest a simplified approach, which would solve the Debian problem too.
In LXDE environment now I manual need creating a simbolic link in /usr/lib/i386-linux-gnu/gtk-2.0 directory to /usr/lib/gtk-2.0.
Only this way accessible the LXDE environment with Firefox and Thunderbird now.

Attila
blocking-b2g: --- → koi?
blocking-b2g: koi? → ---
(In reply to Karl Tomlinson (:karlt) from comment #8)
> Looks like it would be possible to persuade gtk to load another module by
> adding it to the list in the "gtk-modules" property of the default
> GtkSettings.

wouldn't this also break the weird ordering requirements ginn mentioned in comment 6?

(In reply to Jarek Czekalski from comment #12)
> I have a sketch of a solution. Architecture triplet is returned by
> `dpkg-architecture -qDEB_HOST_MULTIARCH`. dpkg-architecture is a perl script
> which in a complicated manner extracts it from /usr/share/dpkg/triplettable
> and I don't see any easier way to get this triplet on Debian. I would like
> to prepare a patch that runs this command and adds the path
> /usr/lib/<triplet> to the library paths, what whould solve this bug. But do
> you find it acceptable to call another process before loading the library?

that's definitely not ok, especially on startup. you can't do something that touches the disk much less runs another process.

> The other approaches that I tried were:
> A. Try to get the gtk modules path from gtk library. Not possible, it's done
> by private functions in gtkmodules.c file. And the library path itself is
> hardcoded at configure time.

Well all you really need to know is the path to the loaded .so for gtk from which you can work out where its modules should be.  Saddly neither gtk or glib seem to provide a function that does that.

I think the least bad thing to do would be parsing /proc/self/maps for where libgtk-x11-2.0.so is loaded and then taking dirname() of that and then appending  gtk-2.0/modules but that's pretty gross and linux only :/
Presumably, akt-bridge is loaded by gtk because we add it to GTK_MODULES in nsAppRunner.cpp. Considering this, dlopen("libatk-bridge.so") should find it without giving a full path. So the question, really, is why PR_LoadLibrary(aModule.libName) doesn't work in LoadGtkModule. The fallback should actually never be used.

That being said, it should be able to find the location of gtk with PR_FindSymbolAndLibrary
(In reply to Mike Hommey [:glandium] from comment #17)
> Presumably, akt-bridge is loaded by gtk because we add it to GTK_MODULES in
> nsAppRunner.cpp. Considering this, dlopen("libatk-bridge.so") should find it

I see us remove it from GTK_MODULES, but I don't see us adding it anywhere in that file.

> That being said, it should be able to find the location of gtk with
> PR_FindSymbolAndLibrary

accept the definition of PRLibrary is hidden within nspr and there is no accessor to get at the path
PR_GetLibraryFilePathname is the one i was actually thinking about.
Another option would be hardcoding the path at build time, and getting the path with pkg-config:

emilio@titan:~$ echo "`pkg-config --variable=libdir gtk+-3.0`/gtk-3.0/modules"
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules
(In reply to Mike Hommey [:glandium] from comment #19)
> PR_GetLibraryFilePathname is the one i was actually thinking about.

yeah, that looks like about what's needed
(In reply to Emilio Pozuelo Monfort from comment #20)
> Another option would be hardcoding the path at build time, and getting the
> path with pkg-config:
> 
> emilio@titan:~$ echo "`pkg-config --variable=libdir
> gtk+-3.0`/gtk-3.0/modules"
> /usr/lib/x86_64-linux-gnu/gtk-3.0/modules

That would only work for distro builds, not mozilla.org builds.
Mike, Trevor - thanks for the hints. Now just all pieces need to be combined. I'll work on it. This night I hope to complete the fresh build of Mozilla, so I'll be ready to start preparing the patch.

By myself I could have problems finding PR_GetLibraryFilePathname, because it is not advertised on MDN api page.
> By myself I could have problems finding PR_GetLibraryFilePathname, because
> it is not advertised on MDN api page.

see nspr/pr/include/prlink.h or look at http://mxr.mozilla.org/mozilla-central/ident?i=PR_GetLibraryFilePathname
Attached patch patch to detect atk path (obsolete) — — Splinter Review 
I'm attaching a patch based on the fact that PR_LoadLibrary(sATKLibName) succeeds at the beginning of PlatformInit. In this library I find the symbol "atk_get_version" and use it to obtain the library location.

This is another workaround for the actual problem, bug #984086, PR_GetLibraryPath being unreliable. If this bug is ever fixed, we can remove these 2 hacks from LoadGtkModule.

        Attachment #8391845 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 8392084 [details] [diff] [review]
path to detect atk path v1.1 - fixed new function lettercase

>+static void
>+AppendAtkPath(nsAutoCString &path)

I don't think there's any point in adding a new function for this, you might as well inline it into LoadGnomeModule()

>+    PRFuncPtr symbol = PR_FindFunctionSymbol(sATKLib, "atk_get_version");

that function is kind of recent, you might as well pick a function that's been in atk longer.

>+    if (!symbol)
>+        return;
>+    char *atkPath = PR_GetLibraryFilePathname(sATKLibName, symbol);

nit, new line pls

>+    if (atkPath && atkPath[0]) {
>+        // we have no cross platform api to get dirname, have we?

dirname(3) looks ok modulo the insanity around its thread safety, and strrchr(3) seems fine if you don't care about people who put '/' in the names of there libraries (which I think won't work anyway because we link libxul against libatk-1.0.so)

otherwise seems fine, please get someone to review a patch with the above addressed I can do it or if glandiums willing another set of eyes is never a bad thing ;)

    
    

    
  
Trevor, thank you for the review and prompt reply.

(In reply to Trevor Saunders (:tbsaunde) from comment #27)
> I don't think there's any point in adding a new function for this, you might
> as well inline it into LoadGnomeModule()

I see a point. Readability, code understanding and maintaining is easier when functions do not exceed a height of a screen. LoadGtkModule is already at its limits. This advice may be found for example here: http://stackoverflow.com/a/550920/772981. But if you don't use this rule at mozilla, I'll put the code inline.

> >+        // we have no cross platform api to get dirname, have we?
> 
> dirname(3) looks ok modulo the insanity around its thread safety, and

So I'll include <libgen.h>, as you wish.

    
    

    
  


  

        Attachment #8392084 -
        Attachment is obsolete: true

    
  

        Attachment #8392422 -
        Flags: review?(mh+mozilla)

    
    

    
  
Comment on attachment 8392422 [details] [diff] [review]
path to detect atk path v1.5 - after Trevor's remarks

Review of attachment 8392422 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/atk/Platform.cpp
@@ +89,5 @@
> +            PR_FindFunctionSymbol(sATKLib, "atk_object_get_name");
> +        if (symbol) {
> +            char *atkPath = PR_GetLibraryFilePathname(sATKLibName, symbol);
> +            if (atkPath && atkPath[0]) {
> +                char *dir = dirname(atkPath);

I'd rather use our string API here.

@@ +96,5 @@
> +                    libPath.Append(dir);
> +                }
> +            }
> +            PR_Free(atkPath);
> +        }

I don't think the path should be derived from the atk lib path, but from the gtk lib path. I don't think the path searching thing is necessary with this: either the module is in $GTK_DIR/gtk-2.0/modules or it's nowhere. It's not worth trying /usr/lib/gtk-2.0/modules after that.

As a side note, I think we shot ourselves in the foot with this hack. If when this hack was written, we'd have bugged gtk upstream to provide public functions to load modules, by now, we'd have such functions available in the smallest gtk version we support and we wouldn't have this problem.

        Attachment #8392422 -
        Flags: review?(mh+mozilla) → review-

    
    

    
  
> @@ +96,5 @@
> > +                    libPath.Append(dir);
> > +                }
> > +            }
> > +            PR_Free(atkPath);
> > +        }
> 
> I don't think the path should be derived from the atk lib path, but from the
> gtk lib path. I don't think the path searching thing is necessary with this:
> either the module is in $GTK_DIR/gtk-2.0/modules or it's nowhere. It's not
> worth trying /usr/lib/gtk-2.0/modules after that.

I think I may at one point have had a machine where I built atk and atk-bridge but not gtk and had atk / atk-bridge in /opt or something.  So this might not be absolutely true, but its probably close enough (and I may well have been using other env variables to make my crazy setup work)

> As a side note, I think we shot ourselves in the foot with this hack. If
> when this hack was written, we'd have bugged gtk upstream to provide public
> functions to load modules, by now, we'd have such functions available in the
> smallest gtk version we support and we wouldn't have this problem.

yeah, wouldn't a time travel machine be great?

    
    

    
  
(In reply to Trevor Saunders (:tbsaunde) from comment #31)
> I think I may at one point have had a machine where I built atk and
> atk-bridge but not gtk and had atk / atk-bridge in /opt or something.  So
> this might not be absolutely true, but its probably close enough (and I may
> well have been using other env variables to make my crazy setup work)

I don't think gtk looks for modules in directories other than under the directory where gtk itself is installed.

    
    

    
  
(In reply to Trevor Saunders (:tbsaunde) from comment #16)
> (In reply to Karl Tomlinson (:karlt) from comment #8)
> > Looks like it would be possible to persuade gtk to load another module by
> > adding it to the list in the "gtk-modules" property of the default
> > GtkSettings.
> 
> wouldn't this also break the weird ordering requirements ginn mentioned in
> comment 6?

I don't know why you suspect that.
The idea would be to set "gtk-modules" when it is appropriate to load atk-bridge.

(In reply to Ginn Chen from comment #6)
> After GNOME 2.24.2, we have NO_AT_BRIDGE=1, we should no longer need to
> strip atk-bridge from GTK_MODULES.

We don't support systems older than CentOS 6.0 and this has Gnome 2.28, so I assume we no longer need to strip atk-bridge.

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #33)
> I'm guessing the search path is determined here:
> https://git.gnome.org/browse/gtk+/tree/gtk/gtkmodules.c?h=gtk-2-
> 24&id=b96f4233434da4ce9be789f7d740cbb410196042#n54

Indeed, and that says gtk looks in:
- $GTK_PATH/GTK_BINARY_VERSION/GTK_HOST/modules
- $GTK_PATH/GTK_BINARY_VERSION/modules
- $GTK_PATH/GTK_HOST/modules
- $GTK_PATH/modules
- $HOME/.gtk-2.0/GTK_BINARY_VERSION/GTK_HOST/modules
- $HOME/.gtk-2.0/GTK_BINARY_VERSION/modules
- $HOME/.gtk-2.0/GTK_HOST/modules
- $HOME/.gtk-2.0/modules
- GTK_LIBDIR/gtk-2.0/GTK_BINARY_VERSION/GTK_HOST/modules
- GTK_LIBDIR/gtk-2.0/GTK_BINARY_VERSION/modules
- GTK_LIBDIR/gtk-2.0/GTK_HOST/modules
- GTK_LIBDIR/gtk-2.0/modules

where $GTK_PATH is an environment variable, $HOST the result of g_get_home_dir(), and GTK_LIBDIR, GTK_BINARY_VERSION and GTK_HOST are variables hardcoded in gtk at build time. GTK_LIBDIR comes from $libdir (so usually /usr/lib or /usr/lib/<multiarch-dir>), GTK_BINARY_VERSION is the gtk version and GTK_HOST is $host, so i guess the output from config.guess.

And that's not counting whether GTK_EXE_PREFIX is set.

In the ideal world, we'd mimick this behaviour.

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #34)
> We don't support systems older than CentOS 6.0 and this has Gnome 2.28, so I
> assume we no longer need to strip atk-bridge.

I think we support some systems older than CentOS 6.0, but they're likely not very much older than CentOS 6.0

    
    

    
  
And indeed, I did read the requirement as being gtk 2.24.2, which is probably too recent, but gnome 2.24.2 is old enough.

    
    

    
  
I'm however not sure NO_AT_BRIDGE=1 would allow us to initialize properly while not touching GTK_MODULES to remove atk-bridge.

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #34)
> (In reply to Trevor Saunders (:tbsaunde) from comment #16)
> > (In reply to Karl Tomlinson (:karlt) from comment #8)
> > > Looks like it would be possible to persuade gtk to load another module by
> > > adding it to the list in the "gtk-modules" property of the default
> > > GtkSettings.
> > 
> > wouldn't this also break the weird ordering requirements ginn mentioned in
> > comment 6?
> 
> I don't know why you suspect that.
> The idea would be to set "gtk-modules" when it is appropriate to load
> atk-bridge.

ah, then I misunderstood

(In reply to Mike Hommey [:glandium] from comment #38)
> I'm however not sure NO_AT_BRIDGE=1 would allow us to initialize properly
> while not touching GTK_MODULES to remove atk-bridge.

aiui that's why it exists, but of course it would need testing.

    
    

    
  


  
(In reply to Mike Hommey [:glandium] from comment #30)

> I'd rather use our string API here.
I couldn't find anything helpful in Moz string API (no FindReverse), so I performed this without using any library.

> I don't think the path should be derived from the atk lib path,
> but from the gtk lib path.
Done.

Mike, if you prefer to do quick adjustments by yourself, you can commit without mentioning me. Actually there's nothing in this patch that I invented myself, so I don't feel like a real author.

        Attachment #8392422 -
        Attachment is obsolete: true

        Attachment #8394595 -
        Flags: review?(mh+mozilla)

    
    

    
  
Comment on attachment 8394595 [details] [diff] [review]
patch to detect gtk path v1.6 - after Mike's review

Review of attachment 8394595 [details] [diff] [review]:
-----------------------------------------------------------------

We should just try to remove this whole hack by not removing atk-bridge from GTK_MODULES.

        Attachment #8394595 -
        Flags: review?(mh+mozilla)

    
    

    
  
Mike, while we wait for the real solution to appear, could you install the patch to make the hack work? Or if someone is working on that, please say when we can expect progress.

    
    

    
  
A week passed. I don't hope this problem will be solved soon. I can only finish this thread with another workaround, which seems less invasive and does not require modification of system folders. Start Firefox with the following command:

LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu firefox

Where the 'i386-linux-gnu' part should actually be obtained from this command:

dpkg-architecture -qDEB_HOST_MULTIARCH

    
    

    
  
> We should just try to remove this whole hack by not removing atk-bridge from
> GTK_MODULES.

so, I finally got around to trying that, and realized that this only works if we start out with GTK_MODULES being set, but I'm not sure that's true in gnome any more, afaik they've moved to a11y always on or run time toggleable.  I'm checking with the gnome people, but I suspect this means we should keep this pile of hacks :(

    
    

    
  


  
Seems gnome still puts GTK_MODULES=gail:atk-bridge in the enviroment and
somehow gtk loads those modules if a11y is toggled at runtime.  So just doing
this will make things work if you start the session with a11y on or set
GTK_MODULES in your enviroment manually.  I'm not sure if other cases can work
but they matter much less so I'll defer worrying about them for now.

bsmedberg feel free to redirect this review someplace else if you have a better idea.

        Attachment #8416626 -
        Flags: review?(benjamin)

    
    

    
  
FWIW, on my machine, enabling "screen reader" in the gnome settings doesn't yield GTK_MODULES being set to anything, OTOH, I'm not sure if that's a side effect of *not* having a screen reader software installed.

    
    

    
  
Comment on attachment 8416626 [details] [diff] [review]
don't remove atk-bridge from GTK_MODULES during startup

The history of this goes back to bug 460926 and bug 468845. I don't know anything about it.

        Attachment #8416626 -
        Flags: review?(karlt)

        Attachment #8416626 -
        Flags: review?(ginn.chen)

        Attachment #8416626 -
        Flags: review?(benjamin)

    
    

    
  
(In reply to Mike Hommey [:glandium] from comment #46)
> FWIW, on my machine, enabling "screen reader" in the gnome settings doesn't
> yield GTK_MODULES being set to anything, OTOH, I'm not sure if that's a side
> effect of *not* having a screen reader software installed.

yeah, when I talked some gnome accessibility people (mostly mgorse) they didn't actually know what caused these gtk modules  to get loaded testing proved wrong what they thought that it was.  At any rate we might as well remove the code to take atk-bridge out of GTK_MODULES since we know we don't need it and then see what happens.

        Attachment #8416626 -
        Flags: review?(karlt) → review+

    
    

    
  
NO_AT_BRIDGE=0 only works after GNOME 2.24.2.
So with GNOME < 2.24.2, if we don't remove atk-bridge from GTK_MODULES during startup, atk-bridge will init before our a11y toolkit, it is the issue of Bug 460926.

Is there any other way to fix this bug?

    
    

    
  
Ginn, could you have a look at comment https://bugzilla.mozilla.org/show_bug.cgi?id=743580#c34 and a few in sequence (34-37)? Guys suspect there that there are no systems with older versions of Gnome. Can you give a counterexample? Now it seems like sacrifying current Debian for the sake of hypothetical archaic system with bleeding edge firefox running on it. And I doubt that accessibility works well on these old systems.

If there is a must, the fix can probably go 2 ways after detecting gnome version. But is it worth trouble? And what libraries should exactly be checked? Is it a specific glib or gtk version?

    
    

    
  
Do we actually still support gnome < 2.24.2?

    
    

    
  
(In reply to Mike Hommey [:glandium] from comment #51)
> Do we actually still support gnome < 2.24.2?

we might actually in so far as we support RH building for rhel5.  That said this won't effect anything for them unless they care about accessibility working which is totally stupid seeing as it was always totally awful in rhel5 (I tried to use it on school machines several years ago) and I believe accessibility will probably mostly still work, just the places we use native widgets like file pickers will be broken.

    
    

    
  
(In reply to Trevor Saunders (:tbsaunde) from comment #52)
> (In reply to Mike Hommey [:glandium] from comment #51)
> > Do we actually still support gnome < 2.24.2?
> 
> we might actually in so far as we support RH building for rhel5.  That said
> this won't effect anything for them unless they care about accessibility
> working which is totally stupid seeing as it was always totally awful in
> rhel5 (I tried to use it on school machines several years ago) and I believe
> accessibility will probably mostly still work, just the places we use native
> widgets like file pickers will be broken.

no, only file pickers will be in a11y hierarchy, most a11y objects in web window are not.

    
    

    
  
(In reply to Ginn Chen from comment #53)
> (In reply to Trevor Saunders (:tbsaunde) from comment #52)
> > (In reply to Mike Hommey [:glandium] from comment #51)
> > > Do we actually still support gnome < 2.24.2?
> > 
> > we might actually in so far as we support RH building for rhel5.  That said
> > this won't effect anything for them unless they care about accessibility
> > working which is totally stupid seeing as it was always totally awful in
> > rhel5 (I tried to use it on school machines several years ago) and I believe
> > accessibility will probably mostly still work, just the places we use native
> > widgets like file pickers will be broken.
> 
> no, only file pickers will be in a11y hierarchy, most a11y objects in web
> window are not.

that might be, but personally I really don't care.  If RH wants to spend time on this fine, but keeping a almost 10 year old platform slightly working is certainly not worth my time.

    
    

    
  
Comment on attachment 8416626 [details] [diff] [review]
don't remove atk-bridge from GTK_MODULES during startup

Review of attachment 8416626 [details] [diff] [review]:
-----------------------------------------------------------------

According to http://www.mozilla.org/en-US/firefox/29.0.1/system-requirements/
Firefox requires GTK+ 2.18 or higher and GNOME 2.16 or higher.
So I think we should remove the code.

A few comments:

1) According to https://bugzilla.mozilla.org/show_bug.cgi?id=460926#c0 ,
gtk+ loads gail and atk-bridge modules no matter what is set in GTK_MODULES.
So I'm wondering why it is not the case here.

2) Would you please save the comment of "it works after GNOME 2.24.2"?

        Attachment #8416626 -
        Flags: review?(ginn.chen) → review+

    
    

    
  
> 1) According to https://bugzilla.mozilla.org/show_bug.cgi?id=460926#c0 ,
> gtk+ loads gail and atk-bridge modules no matter what is set in GTK_MODULES.
> So I'm wondering why it is not the case here.

I'm not seeing AT_SPI_IOR set on my root x window, maybe it was only a thing in the days of at-spi1 / corba?

> 2) Would you please save the comment of "it works after GNOME 2.24.2"?

if you like

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/6b3e73a12bb6
Assignee: nobody → trev.saunders
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32

    
    

    
  
Should we get this fixed in esr31?

    
    

    
  
(In reply to Mike Hommey [:glandium] from comment #59)
> Should we get this fixed in esr31?

that'd be fine with me.

    
    

    
  
(In reply to Trevor Saunders (:tbsaunde) from comment #60)
> (In reply to Mike Hommey [:glandium] from comment #59)
> > Should we get this fixed in esr31?
> 
> that'd be fine with me.

can you request approval?

    
    

    
  
Comment on attachment 8416626 [details] [diff] [review]
don't remove atk-bridge from GTK_MODULES during startup

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Firefox isn't accessible when ESR 31 is used
Fix Landed on Version:32
Risk to taking this patch (and alternatives if risky): low, if it was going to break something we probably should have heard about it by know.  Also this should only have an effect in the case a11y tools are in use, so we can't really break things more than they are without this.
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

        Attachment #8416626 -
        Flags: approval-mozilla-esr31?

        Attachment #8416626 -
        Flags: approval-mozilla-esr31? → approval-mozilla-esr31+

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: