1096834 - e10s disabled due to accessibility when connecting with Microsoft Remote Desktop

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Marco Bonardo [:mak]]

Today e10s disabled itself on my profile stating I'm using a11y, but I'm not, nothing changed on my system, I don't have a touch screen and I didn't install anything new (unless Windows itself updated something at the last shutdown)

browser.tabs.remote.autostart.disabled-because-using-a11y is true

How do I figure what is causing this behavior?

Comment 1

[Jim Mathies [:jimm]]

Under about:telemetry histograms, is ally getting instantiated?

Comment 2

[Marco Bonardo [:mak]]

do you mean A11Y_INSTANTIATED_FLAG 1 samples, average = 0, sum = 0?

Comment 3

[Jim Mathies [:jimm]]

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #2)
> do you mean A11Y_INSTANTIATED_FLAG 1 samples, average = 0, sum = 0?

yeah that's it so afaict ally isn't instantiated. Can you step through this code to figure out what switch flips this?


http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#588

Comment 4

[Marco Bonardo [:mak]]

from what I see in that code, if the problem would be IME I should get "The keyboard being used has activated IME" message in prefs.

instead I get "An accessibility tool is active" message, that is bound to disabledForA11y, that is bound to browser.tabs.remote.autostart.disabled-because-using-a11y

So the real question sounds more like: what caused that pref to be flipped to true?
That looks like the "a11y-init-or-shutdown" notification catched in nsBrowserGlue.

I actually don't think I did anything to init a11y though. And I definitely didn't notice a toolbar or a dialog asking me if I wanted to disable e10s, even if it likely was shown (According to the code). It's possible I dismissed it without even noticing? But still, I don't recall doing anything with a11y in years.
Is it possible something inits nsAccessibilityService without user intervention?

Sounds like the only way to fix this is to go to about:home and flip disabled-because-using-a11y pref to true, indeed once the pref gets enabled in nsBrowserGlue, there's no code to disable it.

Comment 5

[Jim Mathies [:jimm]]

Sorry I was confusing ime and ally code.

Comment 6

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

We definitely have some issues where a11y is incorrectly causing e10s to be disabled. If you have time, it would be great if you could set a breakpoint in nsAccessibilityService::Init, start up the browser, and then get a callstack (and maybe a JS stack via DumpJSStack()) when the breakpoint hits.

Comment 7

[Marco Bonardo [:mak]]

I will try, for now I've reset the pref and on restart it didn't flip back to disabled... so it must be some rare event. If I can get a stack I will post it.

Comment 8

[Marco Bonardo [:mak]]

I didn't get a stack yet, but I figured something, basically this happens when I access my computer through Remote Desktop, Firefox is usually open and then I see the popup asking me to disable E10S due to accessibility... I guess it could have something to do with RDP supporting virtual keyboard.

Comment 9

[Marco Bonardo [:mak]]

fwiw, Remote Desktop with e10s also causes crashes like bug 1088148, that is an a11y crash, so it's clear there's something starting up a11y

Comment 10

[Marco Bonardo [:mak]]

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #9)
> fwiw, Remote Desktop with e10s also causes crashes like bug 1088148, that is
> an a11y crash, so it's clear there's something starting up a11y

I think RD uses some accessibility APIs, like Snagit in the above bug, and then our a11y starts up and we disable e10s. It's unfortunate but I think at this point the only solution is to make a11y work with e10s...

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

dbolter, what is the plan for a11y in e10s?

Comment 12

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

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #11)
> dbolter, what is the plan for a11y in e10s?

Meta bug is bug 1029143 but we haven't filed most of the dependent bugs yet. Trevor is working on our e10s solution and is far enough along that he is ready for help. We have a lot of 'unknown' users of a11y and now one less (this bug -- I worry we'll see more).

I'll work with Trevor, Martin, and Johnny to explicitly roadmap more of the work ahead and reach out for engineering help as appropriate.

Comment 14

[Jim Mathies [:jimm]]

I was just testing this and I'm not seeing any issues. Details:

- connecting from Win7 to a remote Win8 tablet
- initially I am prompted about accessibility when I launch nightly
- restart nightly (e10s is off)
- modify prefs to get e10s turned on:

browser.tabs.remote.autostart.disabled-because-using-a11y = false
accessibility.force_disabled = 1
browser.tabs.remote.autostart = true

After setting these and restarting the browser runs with e10s enabled and rendering looks fine.

Comment 15

[Dave Townsend [:mossop]]

(In reply to Jim Mathies [:jimm] from comment #14)
> I was just testing this and I'm not seeing any issues. Details:
> 
> - connecting from Win7 to a remote Win8 tablet
> - initially I am prompted about accessibility when I launch nightly
> - restart nightly (e10s is off)
> - modify prefs to get e10s turned on:
> 
> browser.tabs.remote.autostart.disabled-because-using-a11y = false
> accessibility.force_disabled = 1
> browser.tabs.remote.autostart = true
> 
> After setting these and restarting the browser runs with e10s enabled and
> rendering looks fine.

I'm connecting over RDP from a mac to a Win7 machine. Nightly doesn't say anything about accessibility to me and e10s is enabled by default, but most remote pages don't render, you just see the throbber. Google works for some reason when most sites don't. Nightly tells me that hardware acceleration is disabled for the RDP graphics driver due to unresolved driver issues.

Comment 16

[Marco Bonardo [:mak]]

(In reply to Jim Mathies [:jimm] from comment #14)
> I was just testing this and I'm not seeing any issues. Details:

> - modify prefs to get e10s turned on:
> 
> browser.tabs.remote.autostart.disabled-because-using-a11y = false
> accessibility.force_disabled = 1
> browser.tabs.remote.autostart = true

indeed this bug is about the fact the user should not have to go through setting all of those prefs just to restore things as they were.
We should not disable E10s just because I connected through rdp. I use rdp almost everyday, and I just decided to stop using E10s on my Win machine cause it's totally not convenient.

Comment 17

[Marco Bonardo [:mak]]

(In reply to Dave Townsend [:mossop] from comment #15)
> Google works for some
> reason when most sites don't. Nightly tells me that hardware acceleration is
> disabled for the RDP graphics driver due to unresolved driver issues.

yeah the gfx corruptions are another sad story, very often the tabs just disappear on gfx renderer switch, but it's unrelated to this bug.

Comment 18

[Jim Mathies [:jimm]]

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #16)
> indeed this bug is about the fact the user should not have to go through
> setting all of those prefs just to restore things as they were.
> We should not disable E10s just because I connected through rdp. I use rdp
> almost everyday, and I just decided to stop using E10s on my Win machine
> cause it's totally not convenient.

We need e10s support in our accessibility library first, then the prefs hacks go away. You can follow the progress on this work via the 'e10sa11y2' bug.

Comment 20

[Marco Bonardo [:mak]]

I can still reproduce the bug just connecting with MS remote desktop from my MacBook pro to my win8.1pro box, so it doesn't appear to be fixed by bug 1092525.

Comment 21

[Jim Mathies [:jimm]]

should be fixed.

Comment 22

[Jim Mathies [:jimm]]

You may need to reset browser.tabs.remote.autostart.disabled-because-using-a11y on the target machine. I don't think we auto reset that.

Comment 23

[Marco Bonardo [:mak]]

yep, it looks fixed. Sorry for late answer but somehow I didn't notice bugmail for this bug...