Touch input devices have e10s disabled due to accessibility

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: jimm, Assigned: jimm)

Tracking

Trunk
x86_64
Windows 8.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

Assignee

Description

5 years ago
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.
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).
Assignee

Comment 2

5 years ago
(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.
Duplicate of this bug: 1157505
(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.
Assignee

Comment 5

4 years ago
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
Assignee: nobody → jmathies
(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.
Assignee

Comment 7

4 years ago
Hey Chris, in the console can you check the value of Services.appinfo.accessibilityIsUIA?
Flags: needinfo?(chrislord.net)
Assignee

Comment 8

4 years ago
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
Assignee

Comment 9

4 years ago
Actually, nm, I can reproduce a false value on a surface pro.
Flags: needinfo?(chrislord.net)
Assignee

Comment 10

4 years ago
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!
Assignee

Comment 11

4 years ago
..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.
Assignee

Comment 12

4 years ago
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.
Assignee

Comment 13

4 years ago
This may have helped with RDP though, will test that.
Assignee

Updated

4 years ago
Blocks: 1159326
No longer blocks: e10sa11y2
Assignee

Updated

4 years ago
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Assignee

Comment 14

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

Comment 15

4 years ago
sorry, wrong bug.
You need to log in before you can comment on or make changes to this bug.