1232416 - Update accessibility last loads prefs only when clients request content accessible interfaces

Status: RESOLVED WORKSFORME

(Firefox :: General, defect, P3)

Description

[Jim Mathies [:jimm]]

Bug 1198459 disabled e10s for all users who have recently run with accessibility. This included users who run Windows on Win8 and Win8 touch screen devices. If possible we'd like to try and detect users who have apz enabled and who have a touch screen device and allow e10s, while also disabling content process accessibility from initializing.

Comment 1

[Jim Mathies [:jimm]]

In triage we changed the ask here - disable a11y support in content and keep e10s running but only on systems that invoke a11y due to Windows 8/10 soft keyboard / touch screen use.

The problem here is that we have no idea why Windows does this, but we have a bug on it. Hooking up dependencies.

Comment 2

[Jim Mathies [:jimm]]

We do not know how to detect these users accurately. We can detect touch screens, and we know if a11y was loaded, but we can't identify specific clients.

Comment 3

[Jim Mathies [:jimm]]

David, what are the chances we can delay initialization of content a11y until a client requests access to content?

cc'ing blassey who did some investigative work on this.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

I should defer that one to Trevor.

Comment 5

[Jim Mathies [:jimm]]

What I think we're looking for is a central location where we can detect when content data gets requested. We would fail these calls and prompt with the doorhanger we currently use. After a restart e10s would be disabled.

Comment 6

[Trevor Saunders (:tbsaunde)]

(In reply to Jim Mathies [:jimm] from comment #3)
> David, what are the chances we can delay initialization of content a11y
> until a client requests access to content?
> 
> cc'ing blassey who did some investigative work on this.

as you note later I don't think we want to activate a11y on release branches for content at the moment.


(In reply to Jim Mathies [:jimm] from comment #5)
> What I think we're looking for is a central location where we can detect
> when content data gets requested. We would fail these calls and prompt with
> the doorhanger we currently use. After a restart e10s would be disabled.

I don't believe such a thing exists.  There's a bunch of ways for a client to go from a chrome object to a content one, and I'm almost certainly forgetting some.

Comment 7

[Jim Mathies [:jimm]]

We're going to look at trying to detect when accessibility tools request content interfaces and use that to set the two a11y load prefs (accessibility.lastLoadDate, accessibility.loadedInLastSession) vs. setting this down in nsBaseWidget when the root accessible interface is requested.

Comment 8

[James Teh [:Jamie]]

E10s shipped for all users a long time ago.