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

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Jim Mathies [:jimm]]

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%

Comment 1

[Jim Mathies [:jimm]]

This decision is being reconsidered. Moving back into triage for now.

Comment 2

[Jim Mathies [:jimm]]

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?

Comment 3

[Jim Mathies [:jimm]]

Attachment: patch

This also adds a new pref, 'browser.tabs.remote.force-enable', which people can use to override the forced disable of a11y + e10s.

Comment 4

[Jim Mathies [:jimm]]

Attachment: patch

cleanup

Comment 5

[Jim Mathies [:jimm]]

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.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

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

[:Felipe Gomes (needinfo for replies!)]

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)

Comment 8

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for FF44 as this might address top crashes on 44.0a2 that are owing to e10s + ally.

Comment 9

[Jim Mathies [:jimm]]

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

Comment 10

[Robert Kaiser]

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

Comment 11

[Jim Mathies [:jimm]]

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

Comment 12

[Jim Mathies [:jimm]]

(In reply to Robert Kaiser (:[e-mail]) 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.

Comment 13

[:Felipe Gomes (needinfo for replies!)]

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 14

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

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)

Comment 15

[Jim Mathies [:jimm]]

Attachment: wip

Comment 16

[Trevor Saunders (:tbsaunde)]

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

Comment 17

[Jim Mathies [:jimm]]

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

Comment 18

[Jim Mathies [:jimm]]

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.

Comment 19

[Jim Mathies [:jimm]]

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.

Comment 20

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 21

[Benjamin Smedberg]

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?

Comment 22

[Jim Mathies [:jimm]]

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

Comment 23

[Benjamin Smedberg]

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?

Comment 24

[Marco Zehe (:MarcoZ)]

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.

Comment 25

[Jim Mathies [:jimm]]

(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

Comment 26

[Trevor Saunders (:tbsaunde)]

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

Comment 27

[Trevor Saunders (:tbsaunde)]

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

Comment 28

[Jim Mathies [:jimm]]

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.

Comment 29

[Jim Mathies [:jimm]]

Attachment: 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

Comment 30

[Jim Mathies [:jimm]]

Attachment: 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

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

Comment 31

[Jim Mathies [:jimm]]

Attachment: MozReview Request: Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r?felipe

Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r?felipe

Comment 32

[Jim Mathies [:jimm]]

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

Comment 33

[:Felipe Gomes (needinfo for replies!)]

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 34

[:Felipe Gomes (needinfo for replies!)]

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

Comment 35

[Jim Mathies [:jimm]]

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 36

[Jim Mathies [:jimm]]

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 37

[Jim Mathies [:jimm]]

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/

Comment 38

[:Felipe Gomes (needinfo for replies!)]

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

Comment 39

[Jim Mathies [:jimm]]

yikes! i think this is right now! :)

Comment 40

[Trevor Saunders (:tbsaunde)]

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.

Comment 41

[Jim Mathies [:jimm]]

Attachment: a11y patch v.2

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.

Comment 42

[Jim Mathies [:jimm]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=03e272073b80

Comment 43

[Jim Mathies [:jimm]]

Attachment: 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

Comment 44

[Jim Mathies [:jimm]]

Attachment: 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

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

Comment 45

[Jim Mathies [:jimm]]

Attachment: MozReview Request: Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r=felipe

Bug 1198459 - Modify existing a11y prompting to support disabling a11y in content until a restart. r=felipe

Comment 46

[Jim Mathies [:jimm]]

Attachment: 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

Comment 47

[Jim Mathies [:jimm]]

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

Comment 48

[:Felipe Gomes (needinfo for replies!)]

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

Comment 49

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bcb4ebf6ffac
https://hg.mozilla.org/integration/mozilla-inbound/rev/4b1d470d9f98
https://hg.mozilla.org/integration/mozilla-inbound/rev/b78e27e51c93
https://hg.mozilla.org/integration/mozilla-inbound/rev/b3a52644af28

Comment 50

[Carsten Book [:Tomcat]]

backed out for bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=18441228&repo=mozilla-inbound

Comment 51

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e948e192e8f7
https://hg.mozilla.org/integration/mozilla-inbound/rev/3fec04a95156
https://hg.mozilla.org/integration/mozilla-inbound/rev/4adab8e48607
https://hg.mozilla.org/integration/mozilla-inbound/rev/a1caa7e7949f

Comment 52

[Philip Chee]

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

Comment 53

[Jim Mathies [:jimm]]

Attachment: appconst patch

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

Comment 54

[Jim Mathies [:jimm]]

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/

Comment 55

[Jim Mathies [:jimm]]

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/

Comment 56

[Jim Mathies [:jimm]]

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/

Comment 57

[Jim Mathies [:jimm]]

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/

Comment 58

[Jim Mathies [:jimm]]

Attachment: MozReview Request: Bug 1198459 - Add some AppConstant use. r=felipe

Bug 1198459 - Add some AppConstant use. r=felipe

Comment 59

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/87dae52b4484
https://hg.mozilla.org/integration/mozilla-inbound/rev/da6bde2e7abd
https://hg.mozilla.org/integration/mozilla-inbound/rev/dd880f72d470
https://hg.mozilla.org/integration/mozilla-inbound/rev/42740b8ac380
https://hg.mozilla.org/integration/mozilla-inbound/rev/00f88afb10ac

Comment 60

[Francesco Lodolo [:flod]]

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.

Comment 61

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/87dae52b4484
https://hg.mozilla.org/mozilla-central/rev/da6bde2e7abd
https://hg.mozilla.org/mozilla-central/rev/dd880f72d470
https://hg.mozilla.org/mozilla-central/rev/42740b8ac380
https://hg.mozilla.org/mozilla-central/rev/00f88afb10ac

Comment 63

[Luís Miguel [:quicksaver] (not reading bugmail)]

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?

Comment 64

[Jim Mathies [:jimm]]

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

Comment 65

[Paul Dickler]

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)

Comment 66

[Jim Mathies [:jimm]]

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

Comment 67

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jim, do we plan to mimic this behavior in FF44? If so, could you please nominate for uplift to Beta44?

Comment 68

[Jim Mathies [:jimm]]

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

Comment 69

[Jim Mathies [:jimm]]

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

Comment 70

[Jim Mathies [:jimm]]

Note, the uplift request is for every patch in this set.

Comment 71

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 72

[Jim Mathies [:jimm]]

Bugs that should uplift with this one - 

bug 1231921
bug 1232368
bug 1232408

Comment 73

[Jim Mathies [:jimm]]

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.

Comment 74

[Jim Mathies [:jimm]]

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.

Comment 75

[Mark Straver]

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?

Comment 76

[Mark Straver]

Sorry for the noise. I made a type on the force pref. It's working (even though the lastLoad still counts up constantly).

Comment 77

[Jim Mathies [:jimm]]

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

Comment 78

[Robert Kaiser]

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

Comment 79

[Mark Straver]

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.

Comment 80

[Jim Mathies [:jimm]]

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

Comment 81

[Mark Straver]

> Are you using any type of remote desktop technology?

None whatsoever.

Comment 82

[Luís Miguel [:quicksaver] (not reading bugmail)]

Filed bug 1233874 for that.

Comment 83

[Erdin Kacan]

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.

Comment 84

[bugzilla]

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>

Comment 85

[bugzilla]

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?

Comment 86

[Jim Mathies [:jimm]]

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

Comment 87

[bugzilla]

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.

Comment 88

[bugzilla]

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

Comment 89

[bugzilla]

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?

Comment 90

[Jim Mathies [:jimm]]

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

Comment 91

[bugzilla]

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.

Comment 92

[bugzilla]

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)

Comment 93

[bugzilla]

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?

Comment 94

[bugzilla]

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

Comment 95

[Avi Halachmi (:avih)]

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"?)

Comment 96

[bugzilla]

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.

Comment 97

[Avi Halachmi (:avih)]

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

Comment 98

[Avi Halachmi (:avih)]

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

Comment 99

[bugzilla]

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.

Comment 100

[Jim Mathies [:jimm]]

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

Comment 101

[Avi Halachmi (:avih)]

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

Comment 102

[bugzilla]

"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

Comment 103

[Jim Mathies [:jimm]]

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

Comment 104

[Avi Halachmi (:avih)]

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