Closed Bug 1092525 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: DOM: Content Processes, defect)

36 Branch
x86_64
Windows NT
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
e10s m5+ ---

People

(Reporter: josh.tumath+bugzilla, Assigned: jimm)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
tracking-e10s: --- → ?
Summary: e10s disabled-because-using-a11y pref is enabled despite not using accessibility software → [e10s] disabled-because-using-a11y pref is enabled despite not using accessibility software
Blocks: e10s
Does your 6.4 device have a touch screen?
Flags: needinfo?(josh)
(In reply to Jim Mathies [:jimm] from comment #1)
> Does your 6.4 device have a touch screen?

Yes.
Flags: needinfo?(josh)
(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.
Component: IPC → DOM: Content Processes
(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.
So this is hitting the "disable if IME" test right? Should this be resolved invalid?
Flags: needinfo?(jmathies)
(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
Flags: needinfo?(jmathies)
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.
Summary: [e10s] disabled-because-using-a11y pref is enabled despite not using accessibility software → [e10s] disabled-because-using-a11y pref is enabled due to touch screen
Assignee: nobody → jmathies
Just saw this reported in #firefox
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
(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.
Attached patch patch (obsolete) — Splinter Review
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.
Attachment #8553686 - Flags: review?(tbsaunde+mozbugs)
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.
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 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.
Attachment #8553686 - Flags: review?(tbsaunde+mozbugs) → review+
(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.
Attached patch patch r=trevorSplinter Review
Attachment #8553686 - Attachment is obsolete: true
Keywords: checkin-needed
Duplicate of this bug: 1115871
(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.
https://hg.mozilla.org/mozilla-central/rev/c4ae38a60a42
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
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.
(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"?
Flags: needinfo?(rmamede)
Duplicate of this bug: 1096834
Flags: needinfo?(rmamede)
You need to log in before you can comment on or make changes to this bug.