352646 - Mac accessibility code not working after EM restart

Status: RESOLVED INCOMPLETE

(Core :: Disability Access APIs, defect)

Description

[Håkan Waara]

This is a weird bug that I've been hesistant to file, because I'm not sure if it's some problem with my environment.

Steps to reproduce:

1. Do a full build (make -f client.mk build)
2. Launch Firefox
3. Open Accessibility Inspector and point at different parts of the window

Expected results:

You can see the a11y hierarchy of whatever you're pointing at.

Actual result:

No elements respond. You see:

<AXApplication "Firefox">
  <AXWindow: "about:blank">

with no children.

After doing a restart, it always works.

Comment 1

[Håkan Waara]

Ginn, would you have the ability to pull the latest trunk code, and build with --enable-accessibility on mac (cocoa), to see if you can reproduce it?

I think you mentioned this while testing.

Comment 2

[Håkan Waara]

It seems enough to make in browser/app to make this occur. Probably because the .app bundle is regenerated then, and all cached (fastload?) info is thrown away.

Firefox starts up, shuts down (because of the extension manager?) and starts up again.

Comment 3

[Håkan Waara]

Attachment: Some relevant debug output from

Here's the console output from when Firefox starts (before the restart). Lots of weird things happening.

Comment 4

[Ginn Chen]

Hakan, I can reproduce this bug with latest trunk.

I suspect the restart after registering components caused it.

export NO_EM_RESTART=1
can avoid the restart.
But I don't know how to solve this bug.

Comment 5

[Håkan Waara]

Setting NO_EM_RESTART=1 makes this bug go away.

Without it, making in browser/app makes my code not run.

So apparently I'm hitting some kind of trouble due to the EM restart on mac. Benjamin, Mark - do you guys have any idea what it might be?

After all, my code is in non-chrome componenets (libaccessibility.dylib, and libwidget_mac.dylib), so I don't see how they could even theorethically be affected?

Comment 6

[Håkan Waara]

To clarify: the code does nothing *the first run* after the restart. Starting Firefox after this point makes it work fine.

Comment 7

[Mark Mentovai]

So, to clarify, is this correct?:

make -C browser/app and launch without NO_EM_RESTART: Firefox launches, restarts itself, and a11y doesn't work until a subsequent launch.

make -C browser/app and launch with NO_EM_RESTART: Firefox launches, doesn't restart itself, and a11y works.

Comment 8

[Håkan Waara]

(In reply to comment #7)
> So, to clarify, is this correct?:
> 
> make -C browser/app and launch without NO_EM_RESTART: Firefox launches,
> restarts itself, and a11y doesn't work until a subsequent launch.
> 
> make -C browser/app and launch with NO_EM_RESTART: Firefox launches, doesn't
> restart itself, and a11y works.

Correct.

Comment 9

[Benjamin Smedberg]

How does mac accessibility hook itself up? Are you doing anything during XPCOM registration?

Comment 10

[Mark Mentovai]

Or might this just be that the OS a11y stuff is getting upset through the restart?

Comment 11

[Håkan Waara]

(In reply to comment #9)
> How does mac accessibility hook itself up? Are you doing anything during XPCOM
> registration?

Mac a11y hooks up lazily. The first time some accessibility API is called by a third-party, calls from widget/cocoa will cause the accessibility hierarchy (in accessible/) to be created.

The only XPCOMy stuff I've been able to find is that nsAccessibilityService listens for xpcom start/shutdown, to make us webprogresslisteners and clean up properly. (http://landfill.mozilla.org/mxr-test/mozilla/source/accessible/src/base/nsAccessibilityService.cpp#115)

As far as I can see, even that service is instantiated lazily, so I don't see how a EM restart can be anything special.

Comment 12

[Håkan Waara]

I just verified that libaccessibility.dylib is not loaded before I explicitly do something with a11y that invokes it (after EM restart) by setting a breakpoint in the NS_GetAccessibilityService.

Comment 13

[Håkan Waara]

So, if our module is not loaded during the EM restart dance, I suppose the next step is to verify why not the widget/cocoa a11y methods are called / able to be called, after the EM restart.

Comment 14

[Håkan Waara]

Here are some debugging notes:

* The child process we start (before exiting the current one) retains the same PSN (the -psn_* argument). I hope this is not confusing anything in the system.

* Some experts in #macdev recommend to do this approach instead, for restart of self (to avoid having two concurrent processes and confusing the system):

  o Write a simple app that waits for stdin to close, and then starts it
  o Have the main app open this, and exit gracefully

My standard C knowledge is weak, so I haven't yet written a test-app for this. I should probably use wait() and exec() though...

Benjamin, Mark, does it sound like this makes sense?

Comment 15

[Håkan Waara]

Ok, I have a proof-of-concept of a new restart method working. Now I will need to confirm if it fixes the bug if used in Firefox too.

The concept is like this:

* The parent application that wants to restart, launches a subprocess with a pipe.
* The new process reads the pipe, which will block.
* It's blocking until the parent app dies.
* When the block is gone, the subprocess will go ahead and relaunch the app.

This is apparently the cleanest way to restart yourself in Cocoa world, according to some core mac people I've been discussing the problem with.

One problem with is that I guess it might prolong the relaunch time a bit, but I don't see a way around that. What we do now is a dirty hack, AFAICS.

Next step, test this on my local Firefox build; will keep you posted on how it goes.

Comment 16

[Håkan Waara]

Attachment: macRelauncher.c

So, I modified MacLaunchChild() to use this process for restart. It did successfully wait until firefox was closed until spawning a new one, but it didn't fix the bug.

So I'm at loss on how to fix this bug. It's impossible to debug since it's probably a bug [in the cocoa/carbon frameworks] triggered by our unique usage of carbon/cocoa in Mozilla. :-(

I attach the source to the subprocess for reference...

Comment 17

[Mark Mentovai]

Benjamin, what are the prospects for switching away from xpcom-restart-via-relaunch in 1.9?

Comment 18

[Benjamin Smedberg]

It would require some dedicated resources other than me: it's going to be somewhat destabilizing, and we'd still need to restart to apply updates.

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

Last activity was 2006-12-20 and I haven't heard mention of this issue in many years.