Jim Mathies [:jimm] Assignee
	Description • 10 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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 1 • 10 years ago

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).

	Jim Mathies [:jimm] Assignee
	Comment 2 • 10 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.

	Chris Lord [:cwiiis]
	Comment 4 • 9 years ago

(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.

	Jim Mathies [:jimm] Assignee
	Comment 5 • 9 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

	Chris Lord [:cwiiis]
	Comment 6 • 9 years ago

(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.

	Jim Mathies [:jimm] Assignee
	Comment 7 • 9 years ago

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

	Jim Mathies [:jimm] Assignee
	Comment 8 • 9 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

	Jim Mathies [:jimm] Assignee
	Comment 9 • 9 years ago

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

	Jim Mathies [:jimm] Assignee
	Comment 10 • 9 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!

	Jim Mathies [:jimm] Assignee
	Comment 11 • 9 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.

	Jim Mathies [:jimm] Assignee
	Comment 12 • 9 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.

	Jim Mathies [:jimm] Assignee
	Comment 13 • 9 years ago

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

	Jim Mathies [:jimm] Assignee
	Comment 14 • 9 years ago

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

	Jim Mathies [:jimm] Assignee
	Comment 15 • 9 years ago

sorry, wrong bug.