1092525 - [e10s] disabled-because-using-a11y pref is enabled due to touch screen

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Josh Tumath]

User Agent: Mozilla/5.0 (Windows NT 6.4; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141031061804

Steps to reproduce:

Enabled e10s in nightly using about:preferences


Actual results:

The pref browser.tabs.remote.autostart.disabled-because-using-a11y keeps getting enabled despite not using any accessibility software.

Comment 1

[Jim Mathies [:jimm]]

Does your 6.4 device have a touch screen?

Comment 2

[Josh Tumath]

(In reply to Jim Mathies [:jimm] from comment #1)
> Does your 6.4 device have a touch screen?

Yes.

Comment 3

[Jim Mathies [:jimm]]

(In reply to Josh Tumath from comment #2)
> (In reply to Jim Mathies [:jimm] from comment #1)
> > Does your 6.4 device have a touch screen?
> 
> Yes.

Our ime check is pretty lose to catch everything, and it ends up tripping on UIA running on win8 which is needed by the soft keyboard. You can flip that ally pref if you like, you shouldn't have any issues.

We'll need to figure out what we're going to do about this check since it's obviously not very exact.

Comment 4

[Josh Tumath]

(In reply to Jim Mathies [:jimm] from comment #3)
> Our ime check is pretty lose to catch everything, and it ends up tripping on
> UIA running on win8 which is needed by the soft keyboard. You can flip that
> ally pref if you like, you shouldn't have any issues.

Actually, I do tend to have some issues, but one might be an unrelated bug. If I reset the a11y pref to the default value, I just get prompted to restart and have it re-enabled again.

Also, the content process crashes when loading Twitter.

Comment 5

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

So this is hitting the "disable if IME" test right? Should this be resolved invalid?

Comment 6

[Jim Mathies [:jimm]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> So this is hitting the "disable if IME" test right? Should this be resolved
> invalid?

Hmm, looking through the whole tracking list, I see nothing filed on solving this for touch screen users on win8. Maybe we should keep this open to track that issue? Touch input devices represent about 10% of our release channel audience.

http://www.mathies.com/mozilla/win8-telemetry.html

Comment 7

[Jonathan Howard]

Telemetry - 28% blocked

138.27k Total nightly running reports on day of 8th
34.75k Total reports running on build 7 (e10s auto-start on by default)
(13.85k not auto 40%)
20.9k auto-start e10s 60%
9.71k blocked 28%
4.14k switched off e10s auto-start 12%


accessibility.force_disabled is easy enough to set manually.

Comment 8

[Mark Hammond [:markh] [:mhammond]]

Just saw this reported in #firefox

Comment 9

[Wellington Torrejais da Silva]

The accessibility detect not correct, because i am not use touch screen and not use accessibility tools.
But i' am i' am need E10S to test. 
Please force and make:
 browser.tabs.remote.autostart.disabled-because-using-a11y
,disabled for/on default. 
Sorry my English.

Comment 10

[Jonathan Howard]

(In reply to Wellington Torrejais da Silva from comment #9)
Set:
 accessibility.force_disabled = 1
AFAIK there are bugs when accessibility is on but not in use when used with e10s.


Using XFCE desktop seemed to be a reason behind accessibility enabled for me but never been inclined to dig to figure out why.

Comment 11

[Jim Mathies [:jimm]]

Attachment: patch

This should avoid disabling in the presence of a touch screen on windows 8 or remote desktop. The nsIXULRuntime api added here is temporary and will be removed within a year.

Comment 12

[Jim Mathies [:jimm]]

try builds - 

https://treeherder.mozilla.org/#/jobs?repo=try&revision=633a3165f7b3

I still need to check remote desktop on win7. I'm not sure if that uses uia or msaa.

Comment 13

[Jim Mathies [:jimm]]

I've tested connecting from a mac to my main win7 workstation and I didn't get a prompt with nightly. 

Dave/Marco, do either of you have any idea what we might be doing differently here? AFAICT your mac->win7 rdp sessions should work with current nightly without any changes.

Comment 14

[Trevor Saunders (:tbsaunde)]

Comment on attachment 8553686 [details] [diff] [review]
patch

I don't really know any of this code, but I guess I can pretend.

>+#if defined(ACCESSIBILITY) && defined(XP_WIN)
>+  // This is the same check the a11y service does to identify uia clients.
>+  if (GetAccService() != nullptr &&
>+      (::GetModuleHandleW(L"uiautomation") ||
>+       ::GetModuleHandleW(L"uiautomationcore"))) {
>+    *aResult = true;

it seems like it'd be somewhat better to use mozilla/a11y/Compatability.h, but meh.

Comment 15

[Jim Mathies [:jimm]]

(In reply to Trevor Saunders (:tbsaunde) from comment #14)
> Comment on attachment 8553686 [details] [diff] [review]
> patch
> 
> I don't really know any of this code, but I guess I can pretend.
> 
> >+#if defined(ACCESSIBILITY) && defined(XP_WIN)
> >+  // This is the same check the a11y service does to identify uia clients.
> >+  if (GetAccService() != nullptr &&
> >+      (::GetModuleHandleW(L"uiautomation") ||
> >+       ::GetModuleHandleW(L"uiautomationcore"))) {
> >+    *aResult = true;
> 
> it seems like it'd be somewhat better to use mozilla/a11y/Compatability.h,
> but meh.

Yeah, I didn't want to pull that in here, and really, this is temporary code and I'm confident that Compatibility.cpp check for uia isn't going to change.

Comment 16

[Jim Mathies [:jimm]]

Attachment: patch r=trevor

Comment 18

[Wellington Torrejais da Silva]

(In reply to Jonathan Howard from comment #10)
> (In reply to Wellington Torrejais da Silva from comment #9)
> Set:
>  accessibility.force_disabled = 1
> AFAIK there are bugs when accessibility is on but not in use when used with
> e10s.
> 
> 
> Using XFCE desktop seemed to be a reason behind accessibility enabled for me
> but never been inclined to dig to figure out why.

On recent updates: After create new and clean profile this problem solved.
Create new, blank and clean profile works for me.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c4ae38a60a42

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c4ae38a60a42

Comment 21

[rmamede]

Just to supply a little more information: Although I am still seeing this in Win8.1 64-bit desktop, the option [ File -> New e10s Window ] is accessible even though the checkbox in about:preferences is not.

Comment 22

[Jim Mathies [:jimm]]

(In reply to rmamede from comment #21)
> Just to supply a little more information: Although I am still seeing this in
> Win8.1 64-bit desktop, the option [ File -> New e10s Window ] is accessible
> even though the checkbox in about:preferences is not.

Hey rmamede, you are still seeing what exactly? The accessibility popup about "e10s will be disabled after you restart"?