Closed Bug 1198459 Opened 9 years ago Closed 9 years ago

Disable a11y in content when we detect e10s is enabled and disable e10s on startup if a11y recently loaded

Categories

(Core :: Disability Access APIs, defect)

42 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
e10s m8+ ---
firefox44 + wontfix
firefox45 --- fixed

People

(Reporter: jimm, Assigned: jimm)

References

(Blocks 1 open bug)

Details

Attachments

(13 obsolete files)

1) disable e10s when a11y is detected, this includes a11y clients like remote desktop and touch screen windows devices.

2) do this on Aurora and up. a11y + e10s will remain on Nightly until it is stable.

3) try and find a way to do this without a restart + prompt.

#3 is hard, we looked at this previously. The prompt + restart though is unacceptable on release channel as it would hit too many users.

Some a11y enabled release channel stats for reference:

mac: <0.5% 
linux: 13%
windows: 7%
windows 8 and up: 15%
This decision is being reconsidered. Moving back into triage for now.
Summary: Disable e10s when we detect a11y is enabled, regardless of a11y client (aurora and up) → Disable e10s when we detect a11y is enabled
The plan here is to get a patch out in a early release that saves a date in prefs when a11y activates. Then in a follow up e10s release we'll first check for this pref and if present, avoid turning e10s on. The date will get updated each time a11y turns on, and after a period non a11y activity get reset.

There is one kink in this plan however, a11y clients can start after the browser is running. This is a pretty common occurrence for certain classes of a11y clients. Good examples include: magnifier tools, remote desktop clients, and stand alone a11y clients that run like normal desktop apps.

Currently when we detect the startup of an a11y client in an e10s enabled browser we prompt using a doorhanger to restart. The message reads:

"Multi-process does not yet support accessibility features. Multi-process will be disabled if you restart Firefox. Would you like to restart?"

This prompt gives users the option of restarting or continuing to run.

I don't think this messaging works for beta/release channels and the option of continuing to run should probably be removed. For example some tools like remote desktop clients aren't interpreted by users as accessibility related but activate a11y anyway. This is probably going to cause some confusion.

I would like to suggest we change the messaging to something more friendly and generic, for example:

"A 3rd party application has requested access to Firefox and is not compatible with new Firefox features. Firefox needs to restart to insure compatibility, your session will reload after the restart."

[Restart]

Also the restart should be forced. If the user doesn't respond or tries to dismiss the prompt, Firefox should restart anyway.

We could use product / UX feedback on this. ni'ing dcamp, can you help get the right people involved here?
Flags: needinfo?(dcamp)
Attached patch patch (obsolete) — Splinter Review
This also adds a new pref, 'browser.tabs.remote.force-enable', which people can use to override the forced disable of a11y + e10s.
Attachment #8690972 - Flags: feedback?(felipc)
Attached patch patch (obsolete) — Splinter Review
cleanup
Attachment #8690972 - Attachment is obsolete: true
Attachment #8690972 - Flags: feedback?(felipc)
Attachment #8690975 - Flags: feedback?(felipc)
Comment on attachment 8690975 [details] [diff] [review]
patch

hey David, can you confirm if nsBaseWidget is the best place to pick up accessibility init? Pretty everything goes through here on desktop, but I could be wrong.
Attachment #8690975 - Flags: feedback?(dbolter)
(In reply to Jim Mathies [:jimm] from comment #3)
> Created attachment 8690972 [details] [diff] [review]
> patch
> 
> This also adds a new pref, 'browser.tabs.remote.force-enable', which people
> can use to override the forced disable of a11y + e10s.

I think this shouldn't be necessary. It used to not work properly in the past, but nowadays setting browser.tabs.remote.disabled-for-a11y to *false* has this same effect.

i.e.: pref undefined => perform a11y checks and possibly define it to true
      pref true  => disable e10s
      pref manually set to false => don't perform checks, don't disable

but maybe this doesn't fit the new timestamp model. Just wanted to throw it out there
Comment on attachment 8690975 [details] [diff] [review]
patch

Review of attachment 8690975 [details] [diff] [review]:
-----------------------------------------------------------------

Jim, take a look at the patch "e10s-a11ychecks" in bug 1226487. Could you build those changes on top of that one (in the E10SAccessibilityCheck object instead of E10SUINotification)? I separated the a11y checks in nsBrowserGlue.js from all the other e10s code, because I want to remove all that other code.  With the code separated it might be easier to do these changes that you're doing (for example, the new code there would already run for e10s/non-e10s on all channels to define the pref in advance in every profile)
Attachment #8690975 - Flags: feedback?(felipc) → feedback+
Tracked for FF44 as this might address top crashes on 44.0a2 that are owing to e10s + ally.
(In reply to Ritu Kothari (:ritu) from comment #8)
> Tracked for FF44 as this might address top crashes on 44.0a2 that are owing
> to e10s + ally.

Plus, this work needs to setup a pref for e10s + 45. So we should get it in beta / release in 44.
(In reply to Jim Mathies [:jimm] from comment #2)
> "A 3rd party application has requested access to Firefox and is not
> compatible with new Firefox features. Firefox needs to restart to insure
> compatibility, your session will reload after the restart."

We should request a final copy for this from someone in UX or so. I personally don't think we should completely hide from the user what kind of "new feature" that is, as IMHO that sounds like we consider our users to be dumb - we should make them feel informed rather than dumbed-out. But that's just my opinion, I don't want to bikeshed and I'm no UX/copy expert. We should ask one.

That said, IMHO from a release quality POV, we cannot at this time run any experiments of turning on e10s for any beta or release population without having this in place if we 1) want meaningful results from that and 2) want users in those experiments to stay with our product and 3) want our product (even in beta) to feel like decent quality.
(In reply to :Felipe Gomes from comment #6)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > Created attachment 8690972 [details] [diff] [review]
> > patch
> > 
> > This also adds a new pref, 'browser.tabs.remote.force-enable', which people
> > can use to override the forced disable of a11y + e10s.
> 
> I think this shouldn't be necessary. It used to not work properly in the
> past, but nowadays setting browser.tabs.remote.disabled-for-a11y to *false*
> has this same effect.
> 
> i.e.: pref undefined => perform a11y checks and possibly define it to true
>       pref true  => disable e10s
>       pref manually set to false => don't perform checks, don't disable
> 
> but maybe this doesn't fit the new timestamp model. Just wanted to throw it
> out there

Yeah I'd like to get rid of that a11y specific pref, and have a more general purpose pref similar to others that force something on. Sound good?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10)
> (In reply to Jim Mathies [:jimm] from comment #2)
> > "A 3rd party application has requested access to Firefox and is not
> > compatible with new Firefox features. Firefox needs to restart to insure
> > compatibility, your session will reload after the restart."
> 
> We should request a final copy for this from someone in UX or so. I
> personally don't think we should completely hide from the user what kind of
> "new feature" that is, as IMHO that sounds like we consider our users to be
> dumb - we should make them feel informed rather than dumbed-out. But that's
> just my opinion, I don't want to bikeshed and I'm no UX/copy expert. We
> should ask one.

That's why I ni'd dcamp. I think Philipp Sackl handles this work but I wanted to be sure it gets to the right person.
Depends on: 1226487
Comment on attachment 8690975 [details] [diff] [review]
patch

Review of attachment 8690975 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Jim Mathies [:jimm] from comment #11)
> Yeah I'd like to get rid of that a11y specific pref, and have a more general
> purpose pref similar to others that force something on. Sound good?

Sure. I tend to dislike general force-on prefs because it's an easy way for people to set that once and forget about it and break things. E.g., this pref will also force e10s on in the case where it should be disabled by lack of HW accel. If someone uses this pref to work around the remote-desktop a11y issues but then don't have HW accel support, it might break them?
Just the reasoning why I prefer per-issue force-on.  But if you think the advantages outweight this issue I'm open to be convinced

::: toolkit/xre/nsAppRunner.cpp
@@ +4718,5 @@
>  #endif // defined(XP_MACOSX)
>  
> +  // Uber override pref for manual testing purposes
> +  if (Preferences::GetBool("browser.tabs.remote.force-enable", false)) {
> +    gBrowserTabsRemoteAutostart = true;

you'll need to also update the `status` variable here, otherwise the E10S_AUTOSTART_STATUS telemetry will be wrong. (worth adding a new field to tell forced-on? this might be useful data)
Comment on attachment 8690975 [details] [diff] [review]
patch

Yeah nsBaseWidget::GetRootAccessible is a decent place. (I hear roc knows this part of the code the best)
Attachment #8690975 - Flags: feedback?(dbolter) → feedback+
Attached patch wip (obsolete) — Splinter Review
Attachment #8690975 - Attachment is obsolete: true
(In reply to Jim Mathies [:jimm] from comment #2)
> The plan here is to get a patch out in a early release that saves a date in
> prefs when a11y activates. Then in a follow up e10s release we'll first
> check for this pref and if present, avoid turning e10s on. The date will get
> updated each time a11y turns on, and after a period non a11y activity get
> reset.
> 
> There is one kink in this plan however, a11y clients can start after the
> browser is running. This is a pretty common occurrence for certain classes
> of a11y clients. Good examples include: magnifier tools, remote desktop
> clients, and stand alone a11y clients that run like normal desktop apps.
> 
> Currently when we detect the startup of an a11y client in an e10s enabled
> browser we prompt using a doorhanger to restart. The message reads:
> 
> "Multi-process does not yet support accessibility features. Multi-process
> will be disabled if you restart Firefox. Would you like to restart?"
> 
> This prompt gives users the option of restarting or continuing to run.
> 
> I don't think this messaging works for beta/release channels and the option
> of continuing to run should probably be removed. For example some tools like
> remote desktop clients aren't interpreted by users as accessibility related
> but activate a11y anyway. This is probably going to cause some confusion.
> 
> I would like to suggest we change the messaging to something more friendly
> and generic, for example:
> 
> "A 3rd party application has requested access to Firefox and is not
> compatible with new Firefox features. Firefox needs to restart to insure
> compatibility, your session will reload after the restart."
> 
> [Restart]
> 
> Also the restart should be forced. If the user doesn't respond or tries to
> dismiss the prompt, Firefox should restart anyway.

Is that acutally the right choice?it would seem to me that for some of those Apps user might well rather we fail the WM_GETOJBECT message and then sai an incompatible thing has been detected if you care about that you need to restart, but I'm not UX ;-)

(In reply to Jim Mathies [:jimm] from comment #5)
> Comment on attachment 8690975 [details] [diff] [review]
> patch
> 
> hey David, can you confirm if nsBaseWidget is the best place to pick up
> accessibility init? Pretty everything goes through here on desktop, but I
> could be wrong.

Well, if you want to get all cases I'd say you should do NS_GetAccessibilityService or something it calls.  addons that enable a11y don't go through the widget code, butI'm not really sure we want to disable e10s just because of them.

I'm not sure "everything" is what you want, I assume you want to keep e10s enabled with a11y on nightly / aurora, and I think we're in a pretty good spot to let it ride the trains for linux and maybe mac?  There are a few regressions, but I think we can deal with those before release.
(In reply to Trevor Saunders (:tbsaunde) from comment #16)
> (In reply to Jim Mathies [:jimm] from comment #2)
> > The plan here is to get a patch out in a early release that saves a date in
> > prefs when a11y activates. Then in a follow up e10s release we'll first
> > check for this pref and if present, avoid turning e10s on. The date will get
> > updated each time a11y turns on, and after a period non a11y activity get
> > reset.
> > 
> > There is one kink in this plan however, a11y clients can start after the
> > browser is running. This is a pretty common occurrence for certain classes
> > of a11y clients. Good examples include: magnifier tools, remote desktop
> > clients, and stand alone a11y clients that run like normal desktop apps.
> > 
> > Currently when we detect the startup of an a11y client in an e10s enabled
> > browser we prompt using a doorhanger to restart. The message reads:
> > 
> > "Multi-process does not yet support accessibility features. Multi-process
> > will be disabled if you restart Firefox. Would you like to restart?"
> > 
> > This prompt gives users the option of restarting or continuing to run.
> > 
> > I don't think this messaging works for beta/release channels and the option
> > of continuing to run should probably be removed. For example some tools like
> > remote desktop clients aren't interpreted by users as accessibility related
> > but activate a11y anyway. This is probably going to cause some confusion.
> > 
> > I would like to suggest we change the messaging to something more friendly
> > and generic, for example:
> > 
> > "A 3rd party application has requested access to Firefox and is not
> > compatible with new Firefox features. Firefox needs to restart to insure
> > compatibility, your session will reload after the restart."
> > 
> > [Restart]
> > 
> > Also the restart should be forced. If the user doesn't respond or tries to
> > dismiss the prompt, Firefox should restart anyway.
> 
> Is that acutally the right choice?it would seem to me that for some of those
> Apps user might well rather we fail the WM_GETOJBECT message and then sai an
> incompatible thing has been detected if you care about that you need to
> restart, but I'm not UX ;-)

I'd be fine with this actually. I'd rather disable a11y and prompt, we've take the opposite approach so far. I'll take a look at the code and see how complex it would be to switch to this.

> 
> (In reply to Jim Mathies [:jimm] from comment #5)
> > Comment on attachment 8690975 [details] [diff] [review]
> > patch
> > 
> > hey David, can you confirm if nsBaseWidget is the best place to pick up
> > accessibility init? Pretty everything goes through here on desktop, but I
> > could be wrong.
> 
> Well, if you want to get all cases I'd say you should do
> NS_GetAccessibilityService or something it calls.  addons that enable a11y
> don't go through the widget code, butI'm not really sure we want to disable
> e10s just because of them.

Thanks, I'll take a look at NS_GetAccessibilityService. 

Due to stability issues (at least on Windows) we want to disable e10s or prevent accessibility from starting up in all cases, including Windows tablets and remote desktop clients. We're going to be rolling out to beta and release, so this is very different from the experimenting we've been doing.

> I'm not sure "everything" is what you want, I assume you want to keep e10s
> enabled with a11y on nightly / aurora

I think we can keep nightly as it is, but aurora needs to be turned off. e10s stability for rollout to beta is judged there. Current 4 of the top crash signatures on aurora are a11y related.

> , and I think we're in a pretty good
> spot to let it ride the trains for linux and maybe mac?  There are a few
> regressions, but I think we can deal with those before release.

So on mac, I don't think it matters since a11y never gets instantiated on that platform - 

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2015-10-28&keys=__none__!__none__!__none__&max_channel_version=release%252F42&measure=A11Y_INSTANTIATED_FLAG&min_channel_version=null&os=Darwin&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2015-10-28&table=0&trim=1&use_submission_date=0

For Windows and Linux, looking at crash stats on aurora for both platforms it's pretty clear Windows isn't ready to ship. For Linux I'm not sure, there are a number of crash signatures associated with reports that have a11y enabled, but very few bugs filed. The top a11y signature falls in the overall top 20 though - 

https://crash-stats.mozilla.com/search/?product=Firefox&version=44.0a2&platform=Linux&accessibility=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

For simplicity sake I'll target all platforms first, we can broaden that as we go.
Hey felipe, have you had a discussion with anyone about exposing the about:preferences e10s checkbox on beta/release? If we offer that then we can look at flipping this around and failing a11y instantiation when e10s is enabled. But if we're not going to expose that checkbox we can't.
Flags: needinfo?(felipc)
I forgot to mention, initial rollout will be to users who do not have addons, so addons that turn a11y on won't be affected.
Jimm: yeah, from all the discussions that I heard, we really don't want to expose the checkbox for beta/release, because it's a technical decision that most users wouldn't understand and shouldn't have to take. But maybe it's worth discussing with UX for this point of view? Maybe that can be exposed in a limited way for a11y users.
Flags: needinfo?(felipc)
We very much want to avoid exposing the e10s checkbox to beta/release users in general. Most users won't have the context necessary to make this decision and we shouldn't be asking them to. We don't want people (with the exception of a11y) opting out of e10s as if it were an optional part of Firefox.

I guess it's possible to have some kind of option that only shows up if e10s is *disabled* which says something like "multi-process Firefox is disabled because you've used accessibility APIs. [Enable]" or something like that?
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #21)
> We very much want to avoid exposing the e10s checkbox to beta/release users
> in general. Most users won't have the context necessary to make this
> decision and we shouldn't be asking them to. We don't want people (with the
> exception of a11y) opting out of e10s as if it were an optional part of
> Firefox.
> 
> I guess it's possible to have some kind of option that only shows up if e10s
> is *disabled* which says something like "multi-process Firefox is disabled
> because you've used accessibility APIs. [Enable]" or something like that?

Yes, I'm sure we can do this.

One issue I'm concerned about.. lets say we disable accessibility features on startup when e10s is enabled and display a door hanger saying "accessibility is disabled because it's incompatible with a new firefox feature, see prefs to fix this". If the user is impaired in such a way that they can't interact with the doorhanger due to a lack of accessibility, we've pretty much screwed them. Trevor, what's your opinion?
Flags: needinfo?(tbsaunde+mozbugs)
I had made an assumption here which may not be true, that a11y would continue working properly *in the chrome process* even if we disabled it for content. So a screenreader-user would still be able to navigate around chrome, go into prefs, etc. If that's not the current plan, how hard would it be?
Yes, the chrome process should work fine to acknowledge a dialog or doorhanger. At least right now, if E10S is being disabled and the doorhanger appears, I can interact with it. Think a modal dialog that only gives an OK and restarts the browser would be preferred, since the user has no choice anyway, but a doorhanger would be fine, too, I think.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #23)
> I had made an assumption here which may not be true, that a11y would
> continue working properly *in the chrome process* even if we disabled it for
> content. So a screenreader-user would still be able to navigate around
> chrome, go into prefs, etc. If that's not the current plan, how hard would
> it be?

Looks like we can control initializing the ipc component of accessibility via a hook into IPCAccessibilityActive() [1]. This is checked in the two places where the child requests the creation of a new PAccessibleDoc [2] for a document.

[1] http://mxr.mozilla.org/mozilla-central/source/accessible/base/nsAccessibilityService.h#286
[2] http://mxr.mozilla.org/mozilla-central/search?string=SendPDocAccessible
> Due to stability issues (at least on Windows) we want to disable e10s or
> prevent accessibility from starting up in all cases, including Windows
> tablets and remote desktop clients. We're going to be rolling out to beta
> and release, so this is very different from the experimenting we've been
> doing.

for windows I totally agree its unstable and too broken to consider rolling out.

> > I'm not sure "everything" is what you want, I assume you want to keep e10s
> > enabled with a11y on nightly / aurora
> 
> I think we can keep nightly as it is, but aurora needs to be turned off.
> e10s stability for rollout to beta is judged there. Current 4 of the top
> crash signatures on aurora are a11y related.
> 
> > , and I think we're in a pretty good
> > spot to let it ride the trains for linux and maybe mac?  There are a few
> > regressions, but I think we can deal with those before release.
> 
> So on mac, I don't think it matters since a11y never gets instantiated on
> that platform - 
> 
> https://telemetry.mozilla.org/new-pipeline/dist.html#!
> cumulative=0&end_date=2015-10-28&keys=__none__!__none__!
> __none__&max_channel_version=release%252F42&measure=A11Y_INSTANTIATED_FLAG&mi
> n_channel_version=null&os=Darwin&product=Firefox&sanitize=1&sort_keys=submiss
> ions&start_date=2015-10-28&table=0&trim=1&use_submission_date=0

yeah, the number of a11y users on mac in ~0 as that shows.

> For Windows and Linux, looking at crash stats on aurora for both platforms
> it's pretty clear Windows isn't ready to ship. For Linux I'm not sure, there
> are a number of crash signatures associated with reports that have a11y
> enabled, but very few bugs filed. The top a11y signature falls in the
> overall top 20 though - 
> 
> https://crash-stats.mozilla.com/search/?product=Firefox&version=44.
> 0a2&platform=Linux&accessibility=__true__&_facets=signature&_columns=date&_co
> lumns=signature&_columns=product&_columns=version&_columns=build_id&_columns=
> platform#facet-signature

That actually looks pretty good.  There's a bunch of stuff that as far as I can tell is unrelated to a11y, and  a couple more a11y crashes unrelated to e10s.  Only crashes 1 and 14 seem to be caused by e10s and a11y.  The first could be hacked around with a null check that shouldn't be needed I think, and I'm hopefully we'll actually fix both of those soon.

> For simplicity sake I'll target all platforms first, we can broaden that as
> we go.

I'm really tempted to say make it windows only which is arguably simpler, but meh we can change that easily later.
Flags: needinfo?(tbsaunde+mozbugs)
(In reply to Jim Mathies [:jimm] from comment #25)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #23)
> > I had made an assumption here which may not be true, that a11y would
> > continue working properly *in the chrome process* even if we disabled it for
> > content. So a screenreader-user would still be able to navigate around
> > chrome, go into prefs, etc. If that's not the current plan, how hard would
> > it be?
> 
> Looks like we can control initializing the ipc component of accessibility
> via a hook into IPCAccessibilityActive() [1]. This is checked in the two
> places where the child requests the creation of a new PAccessibleDoc [2] for
> a document.

that's correct, though it would be even safer to not send PContent::ActivateA11y at all (but if you do that you need to be careful to only do it on desktop).
Flags: needinfo?(dcamp)
For the new text of the notification, this is what I have:

"Firefox accessibility has been partially disabled due to an incompatibility with new browser features."

For the default button I'm thinking of simply have an "Ok" button, with a secondary option in the drop down along the line of "Enable (requires restart)". If anyone has any alternative suggestions here I'd love to hear them.
Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r?tbsaunde
Attachment #8694742 - Flags: review?(tbsaunde+mozbugs)
Bug 1198459 - Add support for disabling e10s if a11y was run in the previous session, or run in a session over the previous week. r?felipe
Attachment #8694743 - Flags: review?(felipc)
Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r?felipe
Attachment #8694744 - Flags: review?(felipc)
(In reply to Jim Mathies [:jimm] from comment #29)
> Created attachment 8694742 [details]
> MozReview Request: Bug 1198459 - Prevent accessibility from initializing in
> content processes when e10s is running. r?tbsaunde
> 
> Bug 1198459 - Prevent accessibility from initializing in content processes
> when e10s is running. r?tbsaunde

I forgot to restrict this to Windows only. Will update in a follow up.
Attachment #8694743 - Flags: review?(felipc) → review+
Comment on attachment 8694743 [details]
MozReview Request: Bug 1198459 - Add support for disabling e10s if a11y was run in the previous session, or run in a session over the previous week. r?felipe

https://reviewboard.mozilla.org/r/26847/#review24385

It would be nice to update about:support and about:preferences to show more details about the e10s status with these changes. Can you file a follow-up bug for that?

::: toolkit/xre/nsAppRunner.cpp:4720
(Diff revision 1)
> +    gBrowserTabsRemoteAutostart = true;

can you create a new status code for force-enabling and also update it here in order for the E10S_AUTOSTART_STATUS telemetry to not be counted incorrectly in case of force-enable?
Comment on attachment 8694744 [details]
MozReview Request: Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r?felipe

https://reviewboard.mozilla.org/r/26849/#review24387

::: browser/components/nsBrowserGlue.js:3306
(Diff revision 1)
> +      return Services.prefs.getBoolPref("browser.tabs.remote.force-enable", false);

The JS API for the prefs services doesn't take a second argument for the default value. But you could remove the hasForcedPref function and just do:

try {
  return Services.prefs.getBoolPref("b.t.r.force-enable");
} catch (e) {}
return false;

::: browser/components/nsBrowserGlue.js:3315
(Diff revision 1)
> +        Services.obs.removeObserver(this, "a11y-init-or-shutdown");

you don't need to remove these observers because you added them as weak observers

::: browser/components/nsBrowserGlue.js:3319
(Diff revision 1)
> +          Services.prefs.setBoolPref("accessibility.loadedInLastSession", true);

This is gonna be a heisen pref that is gonna appear or disappear right when the application is quiting. It will be hard to diagnose problems with it.

Could you define it to always exist in firefox.js (with default value of false) and then set it here to true or false (instead of clearing?)

::: browser/components/nsBrowserGlue.js:3325
(Diff revision 1)
> +        if (data == "1") {

could you also set the loadedInLastSession pref to true here in order to help people diagnose issues with a11y+e10s?

::: browser/components/nsBrowserGlue.js:3366
(Diff revision 1)
> -        Services.startup.quit(Services.startup.eAttemptQuit | Services.startup.eRestart);
> +      Services.startup.quit(Services.startup.eAttemptQuit | Services.startup.eRestart);

Don't remove the notifyObservers call. I think it's important to keep it for some code that might want to clean up. Even if we ignore the cancel request afterwards (although I think it's too aggressive)

::: browser/locales/en-US/chrome/browser/browser.properties:770
(Diff revision 1)
> -e10s.accessibilityNotice.mainMessage = Multi-process does not yet support accessibility features. Multi-process will be disabled if you restart %S. Would you like to restart?
> +e10s.accessibilityNotice.mainMessage = Accessibility support is partially disabled due to compatibility issues with new %S features.

when changing a localized string, the string name needs to also be changed
Attachment #8694744 - Flags: review?(felipc)
Comment on attachment 8694742 [details]
MozReview Request: Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r?tbsaunde

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/26845/diff/1-2/
Comment on attachment 8694743 [details]
MozReview Request: Bug 1198459 - Add support for disabling e10s if a11y was run in the previous session, or run in a session over the previous week. r?felipe

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/26847/diff/1-2/
Comment on attachment 8694744 [details]
MozReview Request: Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r?felipe

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/26849/diff/1-2/
Attachment #8694744 - Flags: review?(felipc)
Comment on attachment 8694744 [details]
MozReview Request: Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r?felipe

https://reviewboard.mozilla.org/r/26849/#review24455
Attachment #8694744 - Flags: review?(felipc) → review+
Summary: Disable e10s when we detect a11y is enabled → Disable a11y when we detect e10s is enabled
yikes! i think this is right now! :)
Summary: Disable a11y when we detect e10s is enabled → Disable a11y in content when we detect e10s is enabled and disable e10s on startup if a11y recently loaded
arg mozreview, but anyway.

It seems to me like it would be simpler to just make the ContentParent bits #ifndef _WIN32.  I don't see why it makes sense to enable accessibility in child processes for !e10s, and I think we want accessibility on in android since that is fairly similar to b2g here.
Attached patch a11y patch v.2 (obsolete) — Splinter Review
Had a discussion with trevor on irc about this. This patch uses the ifndef for content process initialization. It also adds a pref check on Windows for 'browser.tabs.remote.force-enable' so the a11y team can turn e10s and content process accessibility on to test.
Attachment #8691618 - Attachment is obsolete: true
Attachment #8694742 - Attachment is obsolete: true
Attachment #8694742 - Flags: review?(tbsaunde+mozbugs)
Attachment #8695448 - Flags: review?(tbsaunde+mozbugs)
Attachment #8695448 - Flags: review?(tbsaunde+mozbugs) → review+
Attachment #8694743 - Attachment is obsolete: true
Attachment #8694744 - Attachment is obsolete: true
Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r=tbsaunde
Attachment #8696964 - Flags: review?(tbsaunde+mozbugs)
Bug 1198459 - Add support for disabling e10s if a11y was run in the previous session, or run in a session over the previous week. r=felipe
Attachment #8696965 - Flags: review?(felipc)
Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r=felipe
Attachment #8696966 - Flags: review?(felipc)
Bug 1198459 - Update telemetry data based on the use of the forced enable pref. r?felipe
Attachment #8696967 - Flags: review?(felipc)
Attachment #8696964 - Flags: review?(tbsaunde+mozbugs) → review+
Attachment #8696965 - Flags: review?(felipc) → review+
Attachment #8696966 - Flags: review?(felipc) → review+
(In reply to Jim Mathies [:jimm] from comment #46)
> Created attachment 8696967 [details]
> MozReview Request: Bug 1198459 - Update telemetry data based on the use of
> the forced enable pref. r?felipe
> 
> Bug 1198459 - Update telemetry data based on the use of the forced enable
> pref. r?felipe

Felipe, this is the patch for the one issue you raised in rb on the previous patch set.
Attachment #8695448 - Attachment is obsolete: true
Comment on attachment 8696967 [details]
MozReview Request: Bug 1198459 - Update telemetry data based on the use of the forced enable pref. r=felipe

https://reviewboard.mozilla.org/r/27471/#review24783
Attachment #8696967 - Flags: review?(felipc) → review+
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/b78e27e51c93#l2.14
Now would be a good time to replace this preprocessor directive with AppConstants.jsm
Attached patch appconst patch (obsolete) — Splinter Review
Added a couple of the AppConstant conversions. The build bustage that caused the backout was minor, I fixed that in a different patch and pushed to try - 

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6a7d7e9c03d1
Flags: needinfo?(jmathies)
Attachment #8697389 - Flags: review?(felipc)
Attachment #8697389 - Flags: review?(felipc) → review+
Comment on attachment 8696964 [details]
MozReview Request: Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r=tbsaunde

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27465/diff/1-2/
Attachment #8696964 - Flags: review+ → review?(tbsaunde+mozbugs)
Comment on attachment 8696965 [details]
MozReview Request: Bug 1198459 - Add support for disabling e10s if a11y was run in the previous session, or run in a session over the previous week. r=felipe

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27467/diff/1-2/
Attachment #8696965 - Flags: review+ → review?(felipc)
Comment on attachment 8696966 [details]
MozReview Request: Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r=felipe

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27469/diff/1-2/
Attachment #8696966 - Flags: review+ → review?(felipc)
Comment on attachment 8696967 [details]
MozReview Request: Bug 1198459 - Update telemetry data based on the use of the forced enable pref. r=felipe

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/27471/diff/1-2/
Attachment #8696967 - Attachment description: MozReview Request: Bug 1198459 - Update telemetry data based on the use of the forced enable pref. r?felipe → MozReview Request: Bug 1198459 - Update telemetry data based on the use of the forced enable pref. r=felipe
Bug 1198459 - Add some AppConstant use. r=felipe
Attachment #8697416 - Flags: review?(felipc)
Attachment #8696964 - Flags: review?(tbsaunde+mozbugs) → review+
Attachment #8696965 - Flags: review?(felipc) → review+
Attachment #8696966 - Flags: review?(felipc) → review+
Attachment #8697389 - Attachment is obsolete: true
Attachment #8697416 - Flags: review?(felipc) → review+
Keywords: checkin-needed
Passing-by note since I've seen the back-out: the correct spelling for 'OK' is not 'Ok'. That's a spelling error in English and can be fixed without using new IDs for the string.
Blocks: 1231921
I still get the "E10s has been blocked from running..." message in the console pointing to this bug, even though I've forced e10s by setting the new force-enable preference (and it is enabled apparently). Is this intended?
Flags: needinfo?(jmathies)
Blocks: 1232368
(In reply to Luís Miguel [:quicksaver] from comment #63)
> I still get the "E10s has been blocked from running..." message in the
> console pointing to this bug, even though I've forced e10s by setting the
> new force-enable preference (and it is enabled apparently). Is this intended?

Yes that's totally expected. The forced pref is for developer debugging only, the browser should still communicate e10s startup issues with it set.
Flags: needinfo?(jmathies)
Depends on: 1232408
Blocks: 1232416
The only way I can run e10s (32-bit) (on an Acer M5 with touch-screen) is to zero-out the preference "accessibility.lastLoadDate" prior to executionin "prefs.js".
Otherwise, I get the message about accessibility "is/was" active...
I'm on FF 46.0a1 (2015-12-15)
(In reply to Paul Dickler from comment #65)
> The only way I can run e10s (32-bit) (on an Acer M5 with touch-screen) is to
> zero-out the preference "accessibility.lastLoadDate" prior to executionin
> "prefs.js".
> Otherwise, I get the message about accessibility "is/was" active...
> I'm on FF 46.0a1 (2015-12-15)

That's expected. a11y and e10s aren't compatible. We'll re-enable on nightly for these devices once we're more confident about a11y support. Bug 1029143 tracks this work.
Jim, do we plan to mimic this behavior in FF44? If so, could you please nominate for uplift to Beta44?
Flags: needinfo?(jmathies)
(In reply to Ritu Kothari (:ritu) from comment #67)
> Jim, do we plan to mimic this behavior in FF44? If so, could you please
> nominate for uplift to Beta44?

No, we aren't targeting 44 for anything e10s related other than the 44/beta experiment running next week. That code has some a11y detection code in it.
Flags: needinfo?(jmathies)
Comment on attachment 8696964 [details]
MozReview Request: Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r=tbsaunde

Approval Request Comment
[Feature/regressing bug #]:
a11y + e10s stability issues work
[User impact if declined]:
a11y users are gonna have a bad time.
[Describe test coverage new/current, TreeHerder]:
running in nightly for a couple days.
[Risks and why]:
we just merged so uplifting this shouldn't be a problem.
[String/UUID change made/needed]:
Yes
Attachment #8696964 - Flags: approval-mozilla-aurora?
Note, the uplift request is for every patch in this set.
Comment on attachment 8696964 [details]
MozReview Request: Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r=tbsaunde

aurora is now 45 as the merge happened last Monday.
Attachment #8696964 - Flags: approval-mozilla-aurora? → approval-mozilla-beta?
Bugs that should uplift with this one - 

bug 1231921
bug 1232368
bug 1232408
Comment on attachment 8696964 [details]
MozReview Request: Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r=tbsaunde

This code isn't on aurora according to mxr.
Attachment #8696964 - Flags: approval-mozilla-beta? → approval-mozilla-aurora?
Comment on attachment 8696964 [details]
MozReview Request: Bug 1198459 - Prevent accessibility from initializing in content processes when e10s is running. r=tbsaunde

sorry, my mistake. some follow ups didn't make it but this set did.
Attachment #8696964 - Flags: approval-mozilla-aurora?
I landed on this bug after checking the e10s state in the current Nightly (46a1 2015-12-17)...

Setting browser.tabs.remote.force-enable to true
Setting browser.tabs.remote.disabled-for-a11y to false

I don't get e10s due to the presumed use of an a11y tool (none present that I know of!).

Also the preference accessibility.lastLoadDate is constantly updated (ticks every second) and can't be cleared.

Is there still a way for me to test e10s?
Sorry for the noise. I made a type on the force pref. It's working (even though the lastLoad still counts up constantly).
(In reply to Mark Straver from comment #76)
> Sorry for the noise. I made a type on the force pref. It's working (even
> though the lastLoad still counts up constantly).

that means accessibility is getting loaded by something on your system.
(In reply to Mark Straver from comment #76)
> Sorry for the noise. I made a type on the force pref. It's working (even
> though the lastLoad still counts up constantly).

OK, note that this a knowingly unstable configuration, but I guess the teams would still like feedback on it so we can get it fixed in the future.

There's a number of things that cause a11y to be loaded, among other things all Windows touch screen support is AFAIK triggering it.
I don't have a touch screen nor do I have anything loaded for it.

I've run into this before, and explained in one of the other bugs related to this issue: I don't have any accessibility tools running, I use default drivers for my keyboard and mouse (standard desktop setup with a normal monitor). There really is no reason why the code should ever think there's accessibility tools enabled or running (I actually make a point of disabling all shortcuts for it as well in Windows, because they just get in the way. I'm perfectly capable of using a computer without special help, like most other people out there...)

Maybe you should consider releasing a separate version of Firefox for the impaired, instead of trying to work around this issue in the default release? Just a thought.
(In reply to Mark Straver from comment #79)
> I don't have a touch screen nor do I have anything loaded for it.
> 
> I've run into this before, and explained in one of the other bugs related to
> this issue: I don't have any accessibility tools running, I use default
> drivers for my keyboard and mouse (standard desktop setup with a normal
> monitor). There really is no reason why the code should ever think there's
> accessibility tools enabled or running (I actually make a point of disabling
> all shortcuts for it as well in Windows, because they just get in the way.
> I'm perfectly capable of using a computer without special help, like most
> other people out there...)
> 
> Maybe you should consider releasing a separate version of Firefox for the
> impaired, instead of trying to work around this issue in the default
> release? Just a thought.

Are you using any type of remote desktop technology?
> Are you using any type of remote desktop technology?

None whatsoever.
No longer blocks: e10s-miscblockers
Similar to Mark Straver I am also not using any accessibility tools or remote desktop etc but could not enable e10's due to that feature/bug.

My PC is running Windows 10 64 bit, with Firefox 46.0a1 (2015-12-23) also 64bit if that helps.

Also I don't have a touch screen.
I have been upgraded to "46.0a1 (2015-12-25)" today and I've been prompted upon re-opening the app to enable multi process.
"Multi process is coming soon, enable and restart"
I do this and it comes up again, same box, ok enable again, it loops - never enabling.
Upon investigation it's disabled due to the bug listed on this site.

I AM running an RDP session in Windows to another machine - but that should make no difference? (I am not RDP'd 'into' this machine - I'm sitting at the console)

I do not have accessibility tools installed, I DID install a Wacom Tablet about 2 weeks ago, this may be  confused for a accessibility tools? But as the guy above states, I too am annoyed but accessibility **** and generally disable even the shortcuts.

About:Config:  "browser.tabs.remote.force-enable"  is also not available to me.

<b>What further information can I provide to assist with sorting this bug.</b>
NOTE: as per my last post, Windows 7, 64bit, all patched up to date.  This is also the first time I've had the E10S "prompt" box appear.  Infact, I was (blindly?) under the assumption it's been enabled in nightly for a long time, and was previously working, perhaps it hasn't been?
(In reply to bugzilla from comment #84)
> I have been upgraded to "46.0a1 (2015-12-25)" today and I've been prompted
> upon re-opening the app to enable multi process.
> "Multi process is coming soon, enable and restart"
> I do this and it comes up again, same box, ok enable again, it loops - never
> enabling.
> Upon investigation it's disabled due to the bug listed on this site.
> 
> I AM running an RDP session in Windows to another machine - but that should
> make no difference? (I am not RDP'd 'into' this machine - I'm sitting at the
> console)
> 
> I do not have accessibility tools installed, I DID install a Wacom Tablet
> about 2 weeks ago, this may be  confused for a accessibility tools? But as
> the guy above states, I too am annoyed but accessibility **** and generally
> disable even the shortcuts.
> 
> About:Config:  "browser.tabs.remote.force-enable"  is also not available to
> me.
> 
> <b>What further information can I provide to assist with sorting this
> bug.</b>

Would you mind filing a fresh bug? I think Wacom tablet drivers might load accessibility. The prompt to try e10s should not happen though, that was fixed in bug 1232368.
Hi Jim,


Thanks for the reply.

I would file another bug however! 
I reluctantly re-profiled my copy of FFox on the same machine, the pop up has stopped and e10s is working as confirmed going into settings and seeing it's turned on. Therefore, it's not the Wacom drivers.

I can only conclude from this, that something in my profile is causing the issue, as part of basic testing, I disabled *EVERY* addon in my profile, restarted FF, the option is still greyed out.
At this point, I suppose it's up to the development team if you care that only a small handful of users with 'finicky' profiles are going to have issues when they are officially upgraded to final versions which have e10s.

I'm happy to do further investigation if it'll help but at this point we've established a few things
e10s can work on this machine with wacom drivers installed.
e10s won't work on one particular profile, even with all addons disabled
e10s is very likely blocked, due to an issue in an older profile.


*TOTALLY SEPARATELY* The reprofiled 'fresh' FFox nightly has a major issue with lastpass, I'm able to consistently hang Firefox within 15 seconds of opening it, however that's not for this thread and potentially not a Firefox issue at all.
I have submitted a new bug regarding my issues with a fresh profile and FF, this is a low priority obviously, due to being nightly AND involving a plugin.
https://bugzilla.mozilla.org/show_bug.cgi?id=1235495
I have done further testing on this problem and while I did manage to test my copy of FFox Nightly, with ALL ADDONS disabled (still not fixing e10s being disabled)
I did install a fresh copy of nightly, with a fresh profile and the latest dev build of Lastpass.
Lo and behold, upon restarting FF, e10s is disabled on my normally well behaved VM.

https://bugzilla.mozilla.org/show_bug.cgi?id=1235495#c7

At this point I'm unsure, I guess e10s is extremely picky at staying 'active' and any sign of trouble it shuts down?
(In reply to bugzilla from comment #89)
> I have done further testing on this problem and while I did manage to test
> my copy of FFox Nightly, with ALL ADDONS disabled (still not fixing e10s
> being disabled)
> I did install a fresh copy of nightly, with a fresh profile and the latest
> dev build of Lastpass.
> Lo and behold, upon restarting FF, e10s is disabled on my normally well
> behaved VM.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1235495#c7
> 
> At this point I'm unsure, I guess e10s is extremely picky at staying
> 'active' and any sign of trouble it shuts down?

what vm software are you using? vm software might be accessing our accessibility layer for some reason.
VMWare Workstation 11.1.2 - 2780323
Considering the problem has been identical across multiple machines, I suspect it's not the VM software - but I'll do a test now on my Windows 7 PC, should only take a moment.
Assumptions are very silly things.
Lastpass dev build and FF Nightly *IS* working on the raw Windows 7 machine.

VMWare potentially causing E10S to get 'finicky'
Further to this, my other problem is resolved, with QBittorrent logins crashing FF.
https://bugzilla.mozilla.org/show_bug.cgi?id=1235495#c7  (requires Lastpass dev build to solve that though)
Jim, most of my problems are resolved, when was the last nightly build pushed out? I think I got a new one in the last 12 hours.  I suspect whatever is in there has fixed a great many things.  I can't re-create several issues I was definitely having.  (and not just me, so I'm not going crazy)
https://bugzilla.mozilla.org/show_bug.cgi?id=1235495

I wouldn't mind confirming 100% though, where would I find the 64bit Windows build from say ...48 to 60 hours ago?
I have the exe file I'm after for testing but Firefox continues to update, despite me disabling auto updates as soon as I open a fresh instance :/

I'd really like to CONFIRM my previous data on this, anyone know how to block nightly from pulling updates down? The program is NOT responding to the "do not download updates" option
1. How can I enable e10s/APZ/etc when I get this message that e10s is disabled due to accessibility in current nightly? I'm willing to "give up" stuff (accessibility?) which I'll have to.

This is a "normal" laptop which is being used as a desktop system, which also has touchscreen (which I'm willing to give up if I have to in order to enable e10s, as well as willing to give up remote desktop or other features if I have to).

I tried setting browser.tabs.remote.disabled-for-a11y=false and also browser.tabs.remote.autostart[1|2]=true, and e10s is still disabled.


2. What exactly will break/not-work when enabling e10s et al on such systems (and "disabling accessibility"?)
Modify your Firefox Shortcut to have the -p flag at the end of it. (Target field)
"C:\Program Files\Nightly\firefox.exe" -p

Once the profile manager opens upon next boot, create fresh, blank profile.
I'd wager, it'll work fine.  Tools, options will reveal e10s IS working and the accessibility issue is actually something "broken" in your profile.

For further testing, disable all plugins / extensions and reboot Firefox yet again (back on your normal profile)  If your problem is like mine, e10s will STILL not work, despite having no plugins running.

Conclusion: a flag, inside your profile is convincing firefox, some kind of accessibility option is enabled, when infact it is not.
Let me know how you go, I'm curious if other people have my problem.
That didn't work. Starting with an empty profile, on first run I get a "you're now helping test e10s etc" and e10s is enabled at the options.

Then I close and start Firefox again and go to the options page, e10s is now disabled and referring me to this bug, though no message was displayed that it got disabled.

There are no plugins/extensions installed except whatever happens on its own with a clean profile on first run.

FWIW, the extensions list is completely empty, and the plugins page shows the following:
- OpenH264 codec by Cisco
- Primetime content decryption by Adobe
- Google update
- Silverlight plugin

Closing and starting Firefox again stays the same (e10s disabled at the options page and refers me to this bug).
Also, I didn't mention that this is Windows 10 (and did mention it has a touchscreen and touchpad), and that Nightly is the currently latest official (46.0a1 2016-01-04).
Let me  totally clarify here, both boots of the application were into the new profile?
Try setting the new profile, as default temporarily.
I want to be certain the initial boot (with pop) is a new profile (obviously) and the subsequent, firefox initiated reboot of the application, is also booting back into the same profile.

If this is the case then yes, it's extremely like the fault is your system rather than your profile.
I have solved my nightly e10s issues with a new profile AND the latest developer / beta releases of my favourite plugins.
(In reply to Avi Halachmi (:avih) from comment #98)
> Also, I didn't mention that this is Windows 10 (and did mention it has a
> touchscreen and touchpad), and that Nightly is the currently latest official
> (46.0a1 2016-01-04).

Someone else mentioned that a touch screen laptop was not getting the a11y disabled prompt. This isn't such a bad thing really since most touch screen users don't understand what a11y is or why it would be running on their system. I silent disable with e10s turned off on the next restart seems ok. I haven't had a chance to poke at this but I think what happens is a11y is requested so early that we don't have a browser window yet for the notification.

One thing we do need to do is make sure that "you are now testing e10s" is turned off. I don't think we need that anymore. I'll file a bug on that.
(In reply to bugzilla from comment #99)
> Let me  totally clarify here, both boots of the application were into the
> new profile?

Yes. I do know how to use profiles. Let's get that out of the way. The first start of the application was with a profile folder which didn't exist and got created on that run, and the next run was with the same profile dir which used the profile which was just created on the previous run.


> If this is the case then yes, it's extremely like the fault is your system
> rather than your profile.

That's as plain as a system can come. It's windows 10 with no special setup and this system is only used for testing. Also, I don't care about who's fault it is, I was asking:

1. How can I force e10s and disable a11y etc if required.

2. what exactly break/regresses/doesn't work when I do 1.


> I have solved my nightly e10s issues with a new profile AND the latest
> developer / beta releases of my favourite plugins.

I'm not talking about developer/beta but rather about current latest nightly, as I've mentioned more than once.


(In reply to Jim Mathies [:jimm] from comment #100)
> Someone else mentioned that a touch screen laptop was not getting the a11y
> disabled prompt. This isn't such a bad thing ...
> One thing we do need to do is make sure that "you are now testing e10s" is
> turned off. ...

I wasn't concerned with either of those issues, but was just reporting them in case it helps.

My two questions here ^ and at comment 95 still remain unanswered.
"I'm not talking about developer/beta but rather about current latest nightly, as I've mentioned more than once."

I'm not talking about dev / beta either, I'm talking about the latest nightly.
The difference is my PLUGINS are now beta / dev editions.  You and I are both running the same version of Firefox.
That being said, regardless: your problem is your machine or firefox itself, not your profile / plugins like my 2 issues
> 1. How can I force e10s and disable a11y etc if required.

'browser.tabs.remote.force-enable' = true
'accessibility.force_disabled' = 1

> 2. what exactly break/regresses/doesn't work when I do 1.

I don't know of anything that breaks in this setup assuming you don't see accessibility tools.
(In reply to Jim Mathies [:jimm] from comment #103)
> > 1. How can I force e10s and disable a11y etc if required.
> 
> 'browser.tabs.remote.force-enable' = true
> 'accessibility.force_disabled' = 1

This seems to have worked, thanks. I hope Firefox will respect this in the future until e10s and a11y can be enabled together.


> > 2. what exactly break/regresses/doesn't work when I do 1.
> 
> I don't know of anything that breaks in this setup assuming you don't see
> accessibility tools.

For the record, the side effects on this system which I've noticed so far (and I'm not complaining about) appear to be that touch scroll works but lacks momentum (but touch click does work normally). Also, so far no crashes.

If, as far as I understand according to jimm on IRC, there shouldn't be any other dramatic side effects, I think it should be made more obvious to users how to disable a11y and enable e10s.

It's fine defaulting to preferring a11y over e10s if they can't co-exist, but it's not so fine for Firefox to assume that can't live without a11y just because I have a touchscreen.
Attachment #8697416 - Attachment is obsolete: true
Attachment #8696964 - Attachment is obsolete: true
Attachment #8696965 - Attachment is obsolete: true
Attachment #8696966 - Attachment is obsolete: true
Attachment #8696967 - Attachment is obsolete: true
Depends on: 1289473
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: