1166564 - [e10s] Prompted to disable e10s for accessibility when no accessibility features installed

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[barryvan]

I just opted into e10s on Aurora, and upon restart it prompted me to disable it. I *think* it happened when I shift-clicked the "Compose" button in GMail to open the "Compose" window in a new tab -- not sure if this is related or not.

I'm running Windows 8.1 on a Surface Pro 3 i7, with no accessibility features enabled. I haven't actively disabled or uninstalled anything enabled out of the box.

Comment 1

[barryvan]

This seems to be related to Gmail specifically. Having just re-enabled electrolysis to troubleshoot an unrelated bug, I found that the prompt appeared when I clicked the "download all attachments" link in Gmail. Unfortunately testing all of the circumstances in which this happens is rather arduous, as I believe the prompt will only be shown once per Firefox run -- so I would need to restart Firefox between tests. Apologies if this is just more noise -- I figured that more information could do no harm, and might be of at least some use. :)

Comment 2

[Tracy Walker [:tracy]]

If you could narrow down the steps to reliably reproduce, that would be great.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Oh, and do you have any Download Helper add-on, or perhaps some download helper software installed in the OS?

Comment 4

[barryvan]

Apologies for the delay in responding. It looks as though, since 40, Firefox automatically disables e10s without this prompt -- so I cannot easily tell how to reproduce the issue. Addons installed and enabled are:

- AdBlock Plus
- Addon Compatibility reporter
- Zendesk Comment Collapse

I have also installed the British English dictionary, and disabled the Dev Edition theme in favour of the "standard" theme.

There is no download helper software installed in the OS itself.

Under "Ease of Access" in Control Panel, I have the following setup:

- Narrator: Off
- Magnifier: Off
- High contrast: None
- Keyboard:
  - On-screen keyboard: off (but I am running a Surface Pro 3, so a separate on-screen keyboard is used at times)
  - Sticky keys: Off
  - Toggle keys: Off
  - Filter keys: Off
- Mouse:
  - Default pointer size
  - Default pointer colour
  - Use numeric keypad: Off
- Other options:
  - Play animations: On
  - Show Windows background: On
  - Show notifications for: 5s
  - Cursor thickness: default (thinnest)
  - Touch feedback:
    - Show visual feedback when I touch the screen: On (default)
    - Use darker, larger visual feedback: Off (default)

Comment 5

[Tracy Walker [:tracy]]

Barry,  Ok,  please try with a fresh profile.  If it works there, then try in your default profile to see which one of the add-ons may be causing the problem by disabling then all and re-enable, run test, one by one. Thanks.

Comment 6

[:Gijs (he/him)]

(In reply to barryvan from comment #4)
>   - On-screen keyboard: off (but I am running a Surface Pro 3, so a separate
> on-screen keyboard is used at times)

So, this is still not completely fixed, or rather, I think it regressed recently, because bug 1108607 was supposed to fix this case.

Right now, if I create a new profile on my surface pro 3, the following is the case:

1) "Enable multi-process Nightly" is ticked *AND* greyed out, with no reason given
2) gMultiProcessBrowser in the console returns false, so presumably it isn't actually using e10s.

Jim or Mike, can you clarify if that's expected right now, and/or where fixing this is tracked, if anywhere?

Comment 7

[Jim Mathies [:jimm]]

(In reply to :Gijs Kruitbosch from comment #6)
> Right now, if I create a new profile on my surface pro 3, the following is
> the case:
> 
> 1) "Enable multi-process Nightly" is ticked *AND* greyed out, with no reason
> given
> 2) gMultiProcessBrowser in the console returns false, so presumably it isn't
> actually using e10s.

What's the state after you restart?

Comment 8

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #7)
> (In reply to :Gijs Kruitbosch from comment #6)
> > Right now, if I create a new profile on my surface pro 3, the following is
> > the case:
> > 
> > 1) "Enable multi-process Nightly" is ticked *AND* greyed out, with no reason
> > given
> > 2) gMultiProcessBrowser in the console returns false, so presumably it isn't
> > actually using e10s.
> 
> What's the state after you restart?

The same. This doesn't change.

Comment 9

[Jim Mathies [:jimm]]

Here's that in-content checkbox management code - 

http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/in-content/main.js#85

do you have either of the following prefs set:

browser.tabs.remote.autostart
browser.tabs.remote.autostart.2

If you do, and e10s is disabled (likely due to accessibility) the state of that preference checkbox is expected. You've turned e10s on, but for some reason your system has disabled it.

Note that that checkbox is for debugging only, and is only visible in nighty and aurora.

You can work around this by setting 'browser.tabs.remote.force-enable' until our a11y layer is e10s ready.

Comment 10

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #9)
> Here's that in-content checkbox management code - 
> 
> http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/
> in-content/main.js#85
> 
> do you have either of the following prefs set:
> 
> browser.tabs.remote.autostart
> browser.tabs.remote.autostart.2
> 
> If you do, and e10s is disabled (likely due to accessibility) the state of
> that preference checkbox is expected. You've turned e10s on, but for some
> reason your system has disabled it.

I haven't set anything. This is a clean profile. Nightly comes with the .2 pref as true by default. I did not get a warning about e10s being or getting disabled.

> Note that that checkbox is for debugging only, and is only visible in nighty
> and aurora.

Yes, but the fact that it is both greyed out and checked but the actual functionality is *not* enabled is misleading, even if it's just visible on nightly and aurora. (not on the beta experiment? That seems... like a bad idea?)

Now if I report bugs I actually don't know if I'm testing e10s or non-e10s. It seems like it's the latter, but the prefs imply the former.

> You can work around this by setting 'browser.tabs.remote.force-enable' until
> our a11y layer is e10s ready.

But I'm not using a11y, I just have a machine with a touch screen. Naively, it seems like bug 1092525 fixed this and then that code disappeared, and now it's broken again. Why was that code removed (accessibilityUIA gets me 0 hits in dxr, but there are no comments or blocking bugs on that bug that have the removal...)?

Comment 11

[Jim Mathies [:jimm]]

(In reply to :Gijs Kruitbosch from comment #10)
> (In reply to Jim Mathies [:jimm] from comment #9)
> > Here's that in-content checkbox management code - 
> > 
> > http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/
> > in-content/main.js#85
> > 
> > do you have either of the following prefs set:
> > 
> > browser.tabs.remote.autostart
> > browser.tabs.remote.autostart.2
> > 
> > If you do, and e10s is disabled (likely due to accessibility) the state of
> > that preference checkbox is expected. You've turned e10s on, but for some
> > reason your system has disabled it.
> 
> I haven't set anything. This is a clean profile. Nightly comes with the .2
> pref as true by default. I did not get a warning about e10s being or getting
> disabled.
> 
> > Note that that checkbox is for debugging only, and is only visible in nighty
> > and aurora.
> 
> Yes, but the fact that it is both greyed out and checked but the actual
> functionality is *not* enabled is misleading, even if it's just visible on
> nightly and aurora. (not on the beta experiment? That seems... like a bad
> idea?)
> 
> Now if I report bugs I actually don't know if I'm testing e10s or non-e10s.
> It seems like it's the latter, but the prefs imply the former.

If the checkbox is disabled you know e10s is turned off. If you like you can file a bug on tweaking the state here, like I said it's a non release option so we can change it if we want without worrying about strings and such. cc felipe, he usually works on this area of our preferences code.

> > You can work around this by setting 'browser.tabs.remote.force-enable' until
> > our a11y layer is e10s ready.
> 
> But I'm not using a11y, I just have a machine with a touch screen. Naively,
> it seems like bug 1092525 fixed this and then that code disappeared, and now
> it's broken again. Why was that code removed (accessibilityUIA gets me 0
> hits in dxr, but there are no comments or blocking bugs on that bug that
> have the removal...)?

These devices load a11y and we don't have any control over that, and we don't have a way to differentiate between these devices and other types of accessibility software.

We ripped out all the special casing to turn e10s on for some Windows touch devices because there were stability issues showing up in crash stats that would have held up the roll out.