Closed Bug 1108607 Opened 9 years ago Closed 9 years ago
Touch input devices have e10s disabled due to accessibility
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).
(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.
(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.
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.
Hey Chris, in the console can you check the value of Services.appinfo.accessibilityIsUIA?
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
Actually, nm, I can reproduce a false value on a surface pro.
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!
..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.
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.
This may have helped with RDP though, will test that.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You may need to reset browser.tabs.remote.autostart.disabled-because-using-a11y on the target machine.
sorry, wrong bug.
You need to log in before you can comment on or make changes to this bug.