1125442 - e10s mysteriously gets force-disabled, because it thinks an accessibility tool is active (but I'm not knowingly running any such tool). This force-disables e10s via pref browser.tabs.remote.autostart.disabled-because-using-a11y

Status: RESOLVED DUPLICATE of bug 1115956

(Core :: Disability Access APIs, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 0. (I'm using a completely fresh profile)
 1. Start firefox. Make sure e10s is enabled. (Should be by default)
 2. Perform STR for bug 1124821.
 3. Crash (per that bug). Or, reload until you crash, if necessary.
 4. Repeat steps 1-3 until you notice e10s being disabled.
 5. Try to turn on e10s.

ACTUAL RESULTS:
For some reason, at some point, e10s is turned off & is grayed out in about:preferences (can't be enabled), with an explanation "(disabled: An accessibility tool is active)".

I have no accessibilty tools active.

This seems to indicate that the pref browser.tabs.remote.autostart.disabled-because-using-a11y has been set in my profile. I have no idea how/why.

EXPECTED RESULTS: a11y pref shouldn't be mysteriously set; e10s should remain on until I turn it off myself.

Comment 1

[Daniel Holbert [:dholbert]]

It looks like this pref is set by the function "_showE10sAccessibilityWarning()", which is called in two places nsBrowserGlue.js:
http://mxr.mozilla.org/mozilla-central/search?string=_showE10sAccessibilityWarning

Those places are here:
> 2518   checkStatus: function() {
[...]
> 2541       // e10s if a11y is enabled, now or in the future.
> 2542       Services.obs.addObserver(this, "a11y-init-or-shutdown", true);
> 2543       if (Services.appinfo.accessibilityEnabled) {
> 2544         this._showE10sAccessibilityWarning();
> 2545       }

..and then in the observer for "a11y-init-or-shutdown" that's registered in the code above:
> 2601   observe: function(subject, topic, data) {
> 2602     if (topic == "a11y-init-or-shutdown" && data == "1") {
> 2603       this._showE10sAccessibilityWarning();
> 2604     }

Noe that in the first place, we check Services.appinfo.accessibilityEnabled -- but in the second place, we don't check that.  So I'm guessing that I'm hitting this via the second place.  (And we seem to register the observer, which triggers the second place, unconditionally.)

Comment 2

[Daniel Holbert [:dholbert]]

Bill, it looks like you added this code in bug 1047076. Do you know what might be going on here?

Comment 3

[Daniel Holbert [:dholbert]]

(This seems similar to bug 1115956, except in this case I never actually toggled any a11y software, as far as I'm aware. I simply started Firefox, visited a webpage, and crashed, several times in a row -- and then this bug was triggered.

I've hit this several times, too, so it wasn't just a one-off.)

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Well, we're enabling the accessibility service, and that's supposed to permanently disable e10s. I agree that the UI for this is pretty bad, but the theory is that it should be rare and we can remove it once a11y works in e10s.

It sounds like you're not doing anything that you would expect would enable the a11y service. If so, could you break here in a debugger and paste the stack?
http://mxr.mozilla.org/mozilla-central/source/accessible/base/nsAccessibilityService.cpp#1115

If there's JS in the stack, it would also help to "p DumpJSStack()" in gdb and include the output of that as well.

Comment 5

[Daniel Holbert [:dholbert]]

Actually, I can reproduce this simply with a fresh profile, with current Nightly. I immediately get a notification saying that e10s doesn't support accessibility features & will be disabled when I restart.

It's possible I have some a11y tool installed that I forgot about, which is triggering the a11y service without me knowing it. I have used a screen-reader on this laptop in the past, though I had to install a Firefox add-on to get that working IIRC.

Unfortunately I can't look around in gdb, because I can't reproduce this in my own local debug build. :-/ (my debug build does have accessibility enabled [the default], too.)

Comment 6

[Daniel Holbert [:dholbert]]

Bill and I poked at this nightly a bit together, in gdb (which let us break on function calls but won't display lines of code w/out debug symbols). It looks like mozilla::a11y::ShouldA11yBeEnabled() is returning true, likely via its DBUS code-path, but I'm not entirely sure how I can follow up on the exact DBUS setting it's checking & how to figure out why that is the way it is.

Comment 7

[Trevor Saunders (:tbsaunde)]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> Bill and I poked at this nightly a bit together, in gdb (which let us break
> on function calls but won't display lines of code w/out debug symbols). It
> looks like mozilla::a11y::ShouldA11yBeEnabled() is returning true, likely
> via its DBUS code-path, but I'm not entirely sure how I can follow up on the
> exact DBUS setting it's checking & how to figure out why that is the way it
> is.

you can query dbus directly with dbus-send passing it some munging of the arguments in a11y::ShouldA11yBeEnabled() I forget exactly what it is though.  I imagine you can try and figure how stuff gets set with dbus-monitor, but I've never tried to use that one.  I think the cause may be that the gnome people may have switched to a11y being enabled by default in gtk.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Trevor Saunders (:tbsaunde) from comment #7)
> I think the cause may be that the gnome
> people may have switched to a11y being enabled by default in gtk.

FWIW, I can reproduce this on a second machine now -- my linux desktop (in addition to my laptop, which I filed this bug for).  I'm pretty sure I never installed any a11y-specific software here, so Trevor's theory (about this being switched on in gtk by default) seems believable, particularly if this might've been shipped in a recent package update [which I may have gotten on my laptop before updating my desktop].

> you can query dbus directly with dbus-send passing it some munging
> of the arguments in a11y::ShouldA11yBeEnabled()

It looks like the relevant invocation is in a11y::ShouldA11yBeEnabled()'s helper, a11y::PreInit() -- that has:
> 270   static const char* iface = "org.a11y.Status";
> 271   static const char* member = "IsEnabled";
> 272   DBusMessage *message;
> 273   message = dbus_message_new_method_call("org.a11y.Bus", "/org/a11y/bus",
> 274                                          "org.freedesktop.DBus.Properties",
> 275                                          "Get");
[...]
> 279   dbus_message_append_args(message, DBUS_TYPE_STRING, &iface,
> 280                            DBUS_TYPE_STRING, &member, DBUS_TYPE_INVALID);
http://mxr.mozilla.org/mozilla-central/source/accessible/atk/Platform.cpp#270

dbus_message_new_method_call's args are named as-follows:
>  dbus_message_new_method_call (const char *destination,
>                                const char *path,
>                                const char *iface,
>                                const char *method)
http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html

I'm trying to compose a "dbus-send" message that includes the right configuration of args.

Comment 9

[Daniel Holbert [:dholbert]]

From poking at "man dbus-send", my first guesses for the right invocation would be:
 dbus-send --dest=org.a11y.Bus /org/a11y/bus org.freedesktop.DBus.Properties.IsEnabled
or:
 dbus-send --dest=org.a11y.Bus /org/a11y/bus org.a11y.Status.IsEnabled

or either of those with ".Get" appended at the end. But all of those commands just produce no output, so I have no idea if they actually did anything.  (I'm unclear on whether dbus-send even reports back its results on the command line, or how to request that it do that.)

Comment 10

[Daniel Holbert [:dholbert]]

(Ah, ok -- I can add "--print-reply" towards the beginning, which gives me an error message instead of no output. That may help me progress & learn more.)

Comment 11

[Daniel Holbert [:dholbert]]

Actually, I found "dbus-monitor", which shows messages being sent to DBUS in real time (and the responses), so I just ran that after starting Firefox with a fresh profile, and that gave me:
{
method call sender=:1.246 -> dest=org.a11y.Bus serial=2 path=/org/a11y/bus; interface=org.freedesktop.DBus.Properties; member=Get
   string "org.a11y.Status"
   string "IsEnabled"
method return sender=:1.6 -> dest=:1.246 reply_serial=2
   variant       boolean true
}

I still have no idea if there's any way I can discover *why* that's set, or if there's a way I can turn it off [I'll bet I could do it by issuing some DBUS command, but I'd prefer to discover a supported way in the system UI somewhere].

I'm using gnome-shell (gnome 3) instead of Ubuntu Unity, btw -- I suspect that's relevant to causing this. There are probably other folks in the same position hitting this same bug, I imagine.

Comment 12

[Daniel Holbert [:dholbert]]

I asked around on irc.gnome.org #a11y and found out that this DBUS a11y-enabled query is really just querying a piece of "gsettings" configuration -- effectively this command, which returns "true" for me:
> gsettings get org.gnome.desktop.interface toolkit-accessibility

Comment 13

[Daniel Holbert [:dholbert]]

...and I can drill down & toggle that gsettings pref visually, using the "dconf-editor" tool (which shows that the default value is "false"). mgorse in irc.gnome.org #a11y says that orca (the screen-reader tool) turns that pref on, and leaves it on -- so that's likely what happened on my laptop. I have no idea what happened on my desktop, because I have no recollection of running orca there (and yet that pref is on there).

Anyway, bottom line, this is a dupe of bug 1115956, I think.