1108607 - Touch input devices have e10s disabled due to accessibility

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Jim Mathies [:jimm]]

Depending on the state of a11y, we may need to find a work around for this. Touch input hardware turns a11y on for some reason, and a11y also disables e10s. Currently we lose about 10% of our Win8 and up user base due to this.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Why touch input hw turns on a11y? Sounds rather bad, given that when a11y is enabled, performance
is at least a bit worse (it used to be a lot worse).

Comment 2

[Jim Mathies [:jimm]]

(In reply to Olli Pettay [:smaug] from comment #1)
> Why touch input hw turns on a11y? Sounds rather bad, given that when a11y is
> enabled, performance
> is at least a bit worse (it used to be a lot worse).

Windows requests it, exactly why I'm not sure yet.

Comment 4

[Chris Lord [:cwiiis]]

(In reply to Jim Mathies [:jimm] from comment #2)
> (In reply to Olli Pettay [:smaug] from comment #1)
> > Why touch input hw turns on a11y? Sounds rather bad, given that when a11y is
> > enabled, performance
> > is at least a bit worse (it used to be a lot worse).
> 
> Windows requests it, exactly why I'm not sure yet.

Probably because touch devices are likely to have the virtual keyboard enabled.

What's particularly irksome is that often, when you tell the dialog that warns you about e10s and accessibility not working 'Not now', it just ignores that and disables e10s anyway. For example, if you manually enable remote tabs and restart the browser, pick 'Now now' when that hangar pops up, then restart the browser due to automatic updates, e10s will be disabled.

I've force-disabled accessibility in about:config, which seems to have done the trick for now.

Comment 5

[Jim Mathies [:jimm]]

Thought this was fixed in bug 1092525, which I tested on Surface Pro 2. Apparently not though.

http://hg.mozilla.org/mozilla-central/annotate/0b202671c9e2/browser/components/nsBrowserGlue.js#l2815

Comment 6

[Chris Lord [:cwiiis]]

(In reply to Jim Mathies [:jimm] from comment #5)
> Thought this was fixed in bug 1092525, which I tested on Surface Pro 2.
> Apparently not though.
> 
> http://hg.mozilla.org/mozilla-central/annotate/0b202671c9e2/browser/
> components/nsBrowserGlue.js#l2815

For reference, I still experience this bug on a Dell XPS 12 running Win 8.1 64-bit.

Comment 7

[Jim Mathies [:jimm]]

Hey Chris, in the console can you check the value of Services.appinfo.accessibilityIsUIA?

Comment 8

[Jim Mathies [:jimm]]

Also a crash report from this machine would help so I can look at the module list. There's an addon that can help with this - 

https://github.com/luser/crashme

Comment 9

[Jim Mathies [:jimm]]

Actually, nm, I can reproduce a false value on a surface pro.

Comment 10

[Jim Mathies [:jimm]]

I wonder if this is a timing issue. For a local build on startup both Services.appinfo.accessibilityEnabled and Services.appinfo.accessibilityIsUIA are false on startup. But if I launch nightly in the same profile, accessibilityEnabled is true and accessibilityIsUIA is false. This weird!

Comment 11

[Jim Mathies [:jimm]]

..and if I run the local build without a debugger attached, accessibilityEnabled is true. So I guess ms's code is checking if a debugger is present and disabling.

Comment 12

[Jim Mathies [:jimm]]

I really have no idea why windows is initializing our a11y layer. It may be due to the soft keyboard, which has a dll loaded into our process space (tiptsf.dll). Either way this uiaautomation check isn't working right, the fail to init a11y thing associated with a debugger threw my testing off.

Comment 13

[Jim Mathies [:jimm]]

This may have helped with RDP though, will test that.

Comment 14

[Jim Mathies [:jimm]]

You may need to reset browser.tabs.remote.autostart.disabled-because-using-a11y on the target machine.

Comment 15

[Jim Mathies [:jimm]]

sorry, wrong bug.