Closed Bug 1115956 Opened 9 years ago Closed 9 years ago

Improve message when E10S is disabled due to a11y ("An accessibility tool is or was active")

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows 8.1
Type:
defect
Priority:
Not set
Severity:
normal
Points:
1

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla39
Iteration:
39.1 - 9 Mar
Tracking Flags:
Tracking Status
firefox39 --- fixed

People

(Reporter: darren1olivier, Assigned: Felipe)

References

Details

Attachments

(2 files)

Screenshot showing no accessibility tools are active
68.33 KB, image/png
Details
Improve logged string
1023 bytes, patch
mconley
: review+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141227030218

Steps to reproduce:

As far as I'm aware, I did not do anything. I double clicked the search bar, and a message popped up saying "Multiprocess Processing (E10S) does not support accessibility features...." with a button in the message saying disable and restart. I did not want to disable E10S, so closed the message. 

When I restarted, E10S was disabled with the message saying "Disabled: An accessibility tool is active". I checked about:config and the accessibility.typeaheadfind.flashbar was user set to 1 (I don't actually remember setting this, so don't see how it was "user set").

I've since reset the value to its default (0), and still cannot enable E10S. All accessibility. preferences in about:config are set to default (see attached screenshot) yet I still cannot set E10S back to enabled. It's fairly annoying, as I've added no new addons, had E10S working with the same 4 addons I have (BluHell, ForecastFox, NoScript and The Addon Bar) for days on end, yet this issue keeps popping up


Actual results:

E10S was disabled on random(?) activation of an accessibility tool. Accessibility tool was since reset to default, but E10S cannot be switched on again still saying an accessibility tool is active.

I've looked in about:config, no accessibility tool has been user set after I reset the accessibility.typeaheadfind.flashbar


Expected results:

E10S should have been enabled once I reset the accessibility tool accessibility.typeaheadfind.flashbar. This did not happen
QA Whiteboard: [bugday-20141229]
Whiteboard: [e10s]
bug 1029143 has two such bugs in its dependencies: e10s disabled on MS Remote Desktop and e10s disabled on touch input devices.  Is either of them your case?
Flags: needinfo?(darren1olivier)
I experienced this error too after upgrading to todays Nightly.  I'm unsure if i clicked away a dialog or a popup "Multiprocess Nightly (e10s) does not yet support accessibility features..." or not.

This issue is solved by reseting the user preference 
browser.tabs.remote.autostart.disabled-because-using-a11y to false.

Disabling the E10S option when accessibility (a11y) is needed came in with bug 1047076.  It has a dialog which seems to run only once after the need-for-a11y is detected.  So the option to reset this preference in https://hg.mozilla.org/mozilla-central/rev/161056025760#l1.118 is never reached again under windows.

Hint: Accessibility here means "a11y" for people with screen readers or other helpers on operating system level.  The preferences on the screen shot are named "accessibility" too, but they care about some internal behavior of the browser.
Status: UNCONFIRMED → NEW
Component: Untriaged → Disability Access APIs
Depends on: 1047076
Ever confirmed: true
Product: Firefox → Core
Summary: E10S disabled with typeaheadfind.flashbar → E10S disabled forever when a11y was formerly active (Options: "An accessibility tool is active")
Whiteboard: [e10s] → [e10s] [a11y]
Version: 37 Branch → Trunk
(In correction to my comment #2)
> I experienced this error too after upgrading to todays Nightly.  
That was wrong. Correct is:

I got the dialog after activating a speech recognition software in the Location Bar.
As discussed in bug 1125442: on Gnome at least, Firefox will initialize its accessibility code and disable e10s if it sees that a11y is enabled in DBUS, which is really just a proxy for whether this command returns "true":
> gsettings get org.gnome.desktop.interface toolkit-accessibility

(That command returns true for me, because I ran a screen reader once, months ago, though I'm not actively running any accessibility tools now.)
I've found that if the "Services.ww.openWindow()" function is called with the "dialog=yes" feature set, then E10s will be disabled because of accessibility.  For example pasting the following into the browser console will disable E10s:

Services.ww.openWindow(null, "http://www.google.com", "_blank", "dialog=yes", null);

I would assume the following would also do this if pasted into the web console, but I've not been able to get it to actually open a window:

window.open("http://www.google.com", "test", "dialog=yes");


I'm not sure why this disables E10s since all dialog does is disable the icons in the toolbar according to https://developer.mozilla.org/en-US/docs/Web/API/window.open#Window_functionality_features


It's actually a good thing that opening a dialog window disables E10s since if an existing E10s browser window is closed after a dialog window is opened, then the main browser hangs (Windows 7) and the process needs to be killed.
tracking-e10s: --- → ?
Flags: needinfo?(darren1olivier)
The way that it works is that we get a chance to detect a11y and, if detected, we need to restart with e10s off. There's unfortunately not a lot we can do about this workaround, but we are actively working on a11y support on e10s and hopefully soon we won't need to block e10s for a11y anymore. In the meantime, dedicating more time to change the way the workaround works is probably not a good way to use time, so I believe this bug is a Wontfix.

Michael, if I understood correctly, what you report on comment 6 seems like a different (and valid) bug that we should look into. Could you file a new bug about it?
Status: NEW → RESOLVED
Closed: 9 years ago
tracking-e10s: ? → ---
Resolution: --- → WONTFIX
Please mind that the user interface shows "Options: 'An accessibility tool is active'".  This is misleading, as several comments show.

Not spending more time on the technical core of this workaround may be economical.  But misleading users who try to test E10 with bad descriptions should be avoided.  

Changing the visible description in something like "Options: An accessibility tool is or was active. See Bug 1115956" or "Options: An accessibility tool is or was active. Check browser.tabs.remote.autostart.disabled-because-using-a11y" would give users an accurate feedback. 

This will save a lot of their time. Please recheck the WONTFIX decision.
(In reply to :Hb from comment #9)
> Please mind that the user interface shows "Options: 'An accessibility tool
> is active'".  This is misleading, as several comments show.
> 
> Not spending more time on the technical core of this workaround may be
> economical.  But misleading users who try to test E10 with bad descriptions
> should be avoided.  
> 
> Changing the visible description in something like "Options: An
> accessibility tool is or was active. See Bug 1115956" or "Options: An
> accessibility tool is or was active. Check
> browser.tabs.remote.autostart.disabled-because-using-a11y" would give users
> an accurate feedback. 
> 
> This will save a lot of their time. Please recheck the WONTFIX decision.

Appreciate the feedback, and you're right this string could have been more specific. Note though that that prompt is just temporary, the a11y team is working on e10s support so that prompt will come out and a11y will work with e10s.
Changing the string should be a trivial thing to do if it's gonna save users from some confusion. Conley, what do you think?
Attachment #8573672 - Flags: review?(mconley)
TL;DR:
Clear the pref "browser.tabs.remote.autostart.disabled-because-using-a11y" to unblock e10s for you.


There's a bunch of software out there, both for Windows and Linux, such as mouse's drivers, digitizers (stylus) hardware, and other things, that uses the OS accessibility APIs and end up triggering system-wide "a11y is active" flags.

Since there's ongoing work to make a11y work with e10s, and we don't want to make Nightly unusable for a11y users, when these flags are detected, FF is temporarily soft blocking e10s with the pref above when a11y tools are detected. Since not all of them can be detected early enough during startup, once that pref is set, FF won't recheck the conditions and turn off the flag. You'll have to do it manually to use e10s for now, or wait until a11y support for e10s is active.
Summary: E10S disabled forever when a11y was formerly active (Options: "An accessibility tool is active") → E10S disabled forever when a11y was formerly active (Options: "An accessibility tool is or was active")
Whiteboard: [e10s] [a11y] → [e10s] [a11y] [READ COMMENT 12 TO UNBLOCK E10S FOR YOU]
Attachment #8573672 - Flags: review?(mconley) → review+
https://hg.mozilla.org/integration/fx-team/rev/9b1054acff88
Assignee: nobody → felipc
Status: RESOLVED → REOPENED
Iteration: --- → 39.1 - 9 Mar
Points: --- → 1
Resolution: WONTFIX → ---
Summary: E10S disabled forever when a11y was formerly active (Options: "An accessibility tool is or was active") → Improve message when E10S is disabled due to a11y ("An accessibility tool is or was active")
https://hg.mozilla.org/mozilla-central/rev/9b1054acff88
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
(In reply to :Felipe Gomes from comment #12)
> TL;DR:
> Clear the pref "browser.tabs.remote.autostart.disabled-because-using-a11y"
> to unblock e10s for you.
> 
> ...

I hit this issue as well. I don't think I've seen a notice, and came to this bug since the message on the e10s checkbox referred to here (took me a while to notice that e10s has been turned off on its own). So I guess it worked ;) thanks.

As a side note, I don't use accessibility features, and this might have triggered due to a touchpad (on an Asus T100). The funny thing is that Firefox actually performs (scrolls) much MUCH better in e10s compared to without e10s on this low-end laptop, especially now that Silk (proper vsync) is enabled by default on nightlies, so the sudden degraded scroll performance is what got me searching for things which changed.

Until the actual a11y fixes land, and because this seems to trigger also on cases where it seems it shouldn't, maybe we could make it easier for users to get e10s back, instead of sending them to read this bug and find the pref, link to this pref directly from the message itself?:

about:config?filter=browser.tabs.remote.autostart.disabled-because-using-a11y
And possibly link to this bug as well.
(In reply to Avi Halachmi (:avih) from comment #15)
> Until the actual a11y fixes land, and because this seems to trigger also on
> cases where it seems it shouldn't, maybe we could [...]
> link to this pref directly from the message itself?:

I don't think we should encourage users to tweak that pref, from the UI. Better to just have them test w/out e10s.  If Firefox thinks you have a11y enabled (and it likely still thinks that, if it's set this pref), then e10s mode can be crashy at popular sites.  For example, I hit bug 1128751 and bug 1138700, for crashes at forbes.com & wired.com. (Those two crashes are likely the same underlying issue, hence I've marked them as dupes for the moment; it's not fixed yet, though, and seems to be a bit tricky.)

Unless a user can figure out *why* Firefox thinks a11y code should be enabled, and manages to turn that off (which could mean tweaking a setting buried in a system-config tool somewhere), it's probably better that they not run with e10s right now.
(In my case, I hit the wired/forbes crashes because I happened to have a bit flipped in gsettings [from running an accessibility tool once], and that makes making Firefox *always* activate its a11y code, which is normally fine except for the current a11y+e10s stability problems.)
If it indeed makes Firefox more crash prone, then making it harder to reach this pref seems like the right thing to do.

That being said, maybe the temporary solution is to switch some a11 pref such that Firefox just doesn't even try to enter accessibility modes?

I don't know how far are the a11y fixes, but if it's more than right around the corner, and if such global "disable a11y" pref exist, then it might offer a better alternative than the pref suggested on this bug.
(In reply to :Felipe Gomes from comment #12)
> TL;DR:
> Clear the pref "browser.tabs.remote.autostart.disabled-because-using-a11y"
> to unblock e10s for you.

It seems that on my system (Windows 8.1), turning it to false affects only the next start. So this next start does have e10s but also this pref back to true. This means that in order to use e10s a user would need to turn this pref to false every time before closing Firefox (or right after starting it).
(In reply to Avi Halachmi (:avih) from comment #15)
> Until the actual a11y fixes land, and because this seems to trigger also on
> cases where it seems it shouldn't, maybe we could make it easier for users
> to get e10s back, instead of sending them to read this bug and find the
> pref, link to this pref directly from the message itself?:
> 
> about:config?filter=browser.tabs.remote.autostart.disabled-because-using-a11y

I don't think this is triggering in cases where it shouldn't, if the prompt shows up, accessibility is on. That's for a reason we probably don't control. For example, maybe you have a windows system with a touch screen.
(In reply to Avi Halachmi (:avih) from comment #19)
> That being said, maybe the temporary solution is to switch some a11 pref
> such that Firefox just doesn't even try to enter accessibility modes?

You could try:

accessibility.force_disabled = 1

This disables a11y for me on all my win8 touch capable systems. Normally I get the prompt all the time there, this disables that.

Also, note we have other bugs on this related to features like Remote Desktop and Citrix which you could be bumping into.
(In reply to Jim Mathies [:jimm] from comment #21)
> I don't think this is triggering in cases where it shouldn't, if the prompt
> shows up, accessibility is on. That's for a reason we probably don't
> control. For example, maybe you have a windows system with a touch screen.

The prompt never show up for me (I don't even know how it should look.. modal dialog? yellow notification bar below the navbar?), I do have a touchscreen, and this pref keeps setting to true on its own on each restart of Firefox even after I set it to false.


(In reply to Jim Mathies [:jimm] from comment #22)
> You could try:
> 
> accessibility.force_disabled = 1

Yes, I already found it and using it, since modifying the pref on each restart was not something I was going to do.

It did make the touch(screen)-scroll lose its momentum (so only following the touch point but not beyond), touchpad (point/click/scroll) seems to behave the same (and well), and so far I haven't noticed other cases of different behavior.

Does this mean e10s gets disabled on every windows system with a touchscreen, including all windows tablets?


> Also, note we have other bugs on this related to features like Remote
> Desktop and Citrix which you could be bumping into.

Maybe a bit off topic, but considering the subjects which were mentioned (screen readers, touch screen, touch pad, remote desktop) of which I'd only associate screen reader with the term accessibility/a11y, what's the features/scope of the "accessibility" detection as far as Firefox goes?
> (In reply to Jim Mathies [:jimm] from comment #22)
> > You could try:
> > 
> > accessibility.force_disabled = 1
> 
> Yes, I already found it and using it, since modifying the pref on each
> restart was not something I was going to do.

Great!

> It did make the touch(screen)-scroll lose its momentum (so only following
> the touch point but not beyond), touchpad (point/click/scroll) seems to
> behave the same (and well), and so far I haven't noticed other cases of
> different behavior.

Expected. Touch scrolling isn't well supported on Windows desktop with or without e10s. You just get the basics. This isn't going to change soon, although you can file a bug on that momentum issue, which is known but afaik unfiled.

> Does this mean e10s gets disabled on every windows system with a
> touchscreen, including all windows tablets?

Yes. Once we have more stable a11y + e10s we'll stop disabling. The meta bug on this is bug 1029143.

> > Also, note we have other bugs on this related to features like Remote
> > Desktop and Citrix which you could be bumping into.
> 
> Maybe a bit off topic, but considering the subjects which were mentioned
> (screen readers, touch screen, touch pad, remote desktop) of which I'd only
> associate screen reader with the term accessibility/a11y, what's the
> features/scope of the "accessibility" detection as far as Firefox goes?

I don't understand this question. You might want to ask someone from the a11y team, they hang out in #a11y.
Just to give another datapoint: I do not use accessibility tools. I have also tried setting "force_disabled" to 1, but it makes no difference and e10s will still complain about "an accessibility tool being active".

I am running a standard desktop PC, I do not have special input devices, I do not have a touch screen, or touch pad (I use a standard wheel mouse on this system); I don't use remote desktop or VNC or other similar services. I have no need for a11y at all -- what does Firefox use to determine "a11y is on" when I've obviously completely disabled it?
(In reply to Mark Straver from comment #25)
> Just to give another datapoint: I do not use accessibility tools. I have
> also tried setting "force_disabled" to 1, but it makes no difference and
> e10s will still complain about "an accessibility tool being active".
> 
> I am running a standard desktop PC, I do not have special input devices, I
> do not have a touch screen, or touch pad (I use a standard wheel mouse on
> this system); I don't use remote desktop or VNC or other similar services. I
> have no need for a11y at all -- what does Firefox use to determine "a11y is
> on" when I've obviously completely disabled it?

Can you post a copy of your about:support?
Flags: needinfo?(mark)
(In reply to Jim Mathies [:jimm] from comment #26)
> 
> Can you post a copy of your about:support?

Application Basics
------------------

Name: Firefox
Version: 40.0a1
Build ID: 20150421030209
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Multiprocess Windows: 0/1 (default: false)

Crash Reports for the Last 3 Days
---------------------------------

Report ID: bp-006da4fb-9619-41db-8d74-ffe142150422
Submitted: 3 hours ago

All Crash Reports

Extensions
----------

Name: Classic Theme Restorer
Version: 1.3.0
Enabled: true
ID: ClassicThemeRestorer@ArisT2Noia4dev

Name: FireFTP
Version: 2.0.23
Enabled: true
ID: {a7c6cf7f-112c-4500-a7ea-39801a327e5f}

Name: Pale Moon Commander
Version: 1.6.1
Enabled: true
ID: commander@palemoon.org

Name: Persona Switcher
Version: 2.0.4
Enabled: true
ID: drsjb80@gmail.com

Name: uBlock
Version: 0.9.1.0
Enabled: true
ID: {2b10c1c8-a11f-4bad-fe9c-1c11e82cac42}

Name: WorldIP
Version: 3.0.8
Enabled: true
ID: {f36c6cd1-da73-491d-b290-8fc9115bfa55}

Graphics
--------

Adapter Description: AMD Radeon HD 6800 Series
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 1024
Asynchronous Pan/Zoom: none
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 0 Enhanced Contrast: 200
Device ID: 0x6738
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16492)
Driver Date: 11-20-2014
Driver Version: 14.501.1003.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 174b174b
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6800 Series Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

accessibility.force_disabled: 1
browser.cache.disk.capacity: 1048576
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size_cached_value: 358400
browser.cache.disk.smart_size.enabled: false
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 2
browser.download.importedFromSqlite: true
browser.download.useDownloadDir: false
browser.places.smartBookmarksVersion: 7
browser.search.useDBForOrder: true
browser.sessionstore.upgradeBackup.latestBuildID: 20150421030209
browser.startup.homepage_override.buildID: 20150421030209
browser.startup.homepage_override.mstone: 40.0a1
browser.tabs.drawInTitlebar: false
browser.tabs.remote.autostart.disabled-because-using-a11y: true
dom.apps.reset-permissions: true
dom.mozApps.used: true
extensions.lastAppVersion: 40.0a1
font.internaluseonly.changed: false
font.name.sans-serif.x-western: Trebuchet MS
gfx.direct3d.last_used_feature_level_idx: 0
media.gmp-eme-adobe.lastUpdate: 1429656555
media.gmp-eme-adobe.version: 8
media.gmp-gmpopenh264.lastUpdate: 1423580402
media.gmp-gmpopenh264.version: 1.3
media.gmp-manager.buildID: 20150421030209
media.gmp-manager.lastCheck: 1429657271
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1429690896
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
plugin.state.java: 0
plugin.state.npctrl: 2
plugin.state.npdeployjava: 0
plugin.state.nppdf: 0
privacy.cpd.cookies: false
privacy.donottrackheader.enabled: true
privacy.sanitize.migrateFx3Prefs: true
privacy.sanitize.timeSpan: 0
security.disable_button.openCertManager: false
security.ssl3.rsa_rc4_128_md5: false
security.ssl3.rsa_rc4_128_sha: false
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1429008155

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: true
Prevent Accessibility: 1

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.19 Basic ECC Beta
Version in use: 3.19 Basic ECC Beta

NSSSMIME
Expected minimum version: 3.19 Basic ECC Beta
Version in use: 3.19 Basic ECC Beta

NSSSSL
Expected minimum version: 3.19 Basic ECC Beta
Version in use: 3.19 Basic ECC Beta

NSSUTIL
Expected minimum version: 3.19 Beta
Version in use: 3.19 Beta

Experimental Features
---------------------
Flags: needinfo?(mark)
Thanks. Another thing to test - can you try disabling all your addons, restart, and check the about accessibility section to see if an addon is at fault?

Also, how secure is your system? Do you trust that you do not have any malicious software running on it?
Flags: needinfo?(mark)
(In reply to Jim Mathies [:jimm] from comment #28)
> Thanks. Another thing to test - can you try disabling all your addons,
> restart, and check the about accessibility section to see if an addon is at
> fault?
> 
> Also, how secure is your system? Do you trust that you do not have any
> malicious software running on it?

Regardless of those, would it be possible to add some code where the accessibility detection  places the reason for it being activated at some place? Maybe at about:support under the Accessibility section, also add the reason why it's activated?
(In reply to Avi Halachmi (:avih) from comment #29)
> (In reply to Jim Mathies [:jimm] from comment #28)
> > Thanks. Another thing to test - can you try disabling all your addons,
> > restart, and check the about accessibility section to see if an addon is at
> > fault?
> > 
> > Also, how secure is your system? Do you trust that you do not have any
> > malicious software running on it?
> 
> Regardless of those, would it be possible to add some code where the
> accessibility detection  places the reason for it being activated at some
> place? Maybe at about:support under the Accessibility section, also add the
> reason why it's activated?

Looks like we have limited support for this on Windows where we try to detect common clients based on dlls loaded into fx process space -

http://mxr.mozilla.org/mozilla-central/source/accessible/windows/msaa/Compatibility.cpp#52

Having this in about:support would certainly help. I'm not on the a11y team, they might have more ideas. Care to file a bug on this?
(In reply to Jim Mathies [:jimm] from comment #30)
> Having this in about:support would certainly help. I'm not on the a11y team,
> they might have more ideas. Care to file a bug on this?

I prefer not to since it seems to me like looking at a problem through a keyhole.

The real problem appears to me like "Accessibility" is "detected"/associated with features which seemingly have nothing to do with Accessibility as most people understand this term.

For instance, I could argue that if Firefox "enables accessibility" (whatever this actually means - which could mean incorrect things) if there exists a touchpad or touch screen, and these are "normal" features of systems these days which I don't think should have anything to do with "real" accessibility.

Same goes for remote desktop/vnc/whatever. These are features which people use regardless of them having any accessibility issues.

Now, it's possible that any of the features mentioned above do cause some issues with e10s, but if they do, then it still should probably has nothing to do with accessibility as most people know it.

From wikipedia:

> computer accessibility (also known as Accessible computing) refers to the accessibility of
> a computer system to all people, regardless of disability or severity of impairment.

and

> when software, hardware, or a combination of hardware and software, is used to enable use of
> a computer by a person with a disability or impairment, this is known as Assistive Technology.

So the existence of touchpad or touchscreen or using remote desktop (or other things I'm unaware of) should definitely NOT be considered as requiring Firefox to "enable accessibility" according to the definition above.

So before I file any bugs, I'd need to know:

1. What does "enable accessibility" actually mean in Firefox? In real, technical terms.

2. Do we incorrectly deduce that if some "normal" HW/SW features are available, then it's assumed that the user needs "real" accessibility features?

3. Do we disable e10s because these features exist (e.g. touchpad) on their own? or is that the fact that "accessibility is enabled" (possibly due to the existence of touchpad) which prevents usage with e10s?


Etc. I just know too little on accessibility in Firefox, so I don't think I can file useful bugs.
(In reply to Avi Halachmi (:avih) from comment #31)
> ...
> 1. What does "enable accessibility" actually mean in Firefox? In real,
> technical terms.

And also, probably a guiding question for this discussion:

- What does/should it mean semantically?
(In reply to Jim Mathies [:jimm] from comment #28)
> Thanks. Another thing to test - can you try disabling all your addons,
> restart, and check the about accessibility section to see if an addon is at
> fault?

I already tried safe mode before. I disabled all of them by hand, restarted, and it made no difference:

Accessibility
Activated 	false

> Also, how secure is your system? Do you trust that you do not have any
> malicious software running on it?

My system is 100% secure. Apart from being vigilant about not ever running untrusted software, I also use MSE as an extra layer of protection. I don't have malware, and if I ever did, I would immediately notice it as this is a tightly controlled development and "this is my livelihood" machine.

One thing I can think of, potentially, is that I do have a graphics tablet (not currently connected but the driver is installed) for my creative work. Perhaps Firefox mistakes this as "accessibility" hardware... What method is used to determine this anyway? it seems overly aggressive, whatever it is.
Flags: needinfo?(mark)
(In reply to Mark Straver from comment #33)
> (In reply to Jim Mathies [:jimm] from comment #28)
> > Thanks. Another thing to test - can you try disabling all your addons,
> > restart, and check the about accessibility section to see if an addon is at
> > fault?
> 
> I already tried safe mode before. I disabled all of them by hand, restarted,
> and it made no difference:
> 
> Accessibility
> Activated 	false
> 

Um, looks like it did! Activated is 'false', meaning accessibility was lever loaded.
My bad, it was because I forced accessibility off.

Doing it again, this time with the proper prefs to default and all add-ons disabled:

Accessibility
Activated 	true
Prevent Accessibility 	0

What happens when I don't force it off:
First start, e10s is enabled
I restart the browser, and it disables e10s
I can reset the pref from comment 12, restart, and it will enable e10s once, but upon next restart disables it again.
(In reply to Mark Straver from comment #35)
> My bad, it was because I forced accessibility off.
> 
> Doing it again, this time with the proper prefs to default and all add-ons
> disabled:
> 
> Accessibility
> Activated 	true
> Prevent Accessibility 	0
> 
> What happens when I don't force it off:
> First start, e10s is enabled
> I restart the browser, and it disables e10s
> I can reset the pref from comment 12, restart, and it will enable e10s once,
> but upon next restart disables it again.

Ok, thanks for testing. We can rule out the addons you have installed I guess.
(In reply to Mark Straver from comment #33)
> One thing I can think of, potentially, is that I do have a graphics tablet
> (not currently connected but the driver is installed) for my creative work.
> Perhaps Firefox mistakes this as "accessibility" hardware... What method is
> used to determine this anyway? it seems overly aggressive, whatever it is.

This is interesting. I'm trying to figure out what we can do here to debug. Will post back.
(In reply to Avi Halachmi (:avih) from comment #31)
> So before I file any bugs, I'd need to know:
> 
> 1. What does "enable accessibility" actually mean in Firefox? In real,
> technical terms.

Firefox received a request for accessibility services through our main window here - 

http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#5187

This request usually comes from a separate process through COM marshaling, so we have very little info on what is asking for it. Lots of software packages make this request, some might not be obvious a11y consumers. RDP is a good example, Citrix is another.

Extensions are a bit different as they can instantiate the XPCOM service internally which also turns the a11y library on.

> 2. Do we incorrectly deduce that if some "normal" HW/SW features are
> available, then it's assumed that the user needs "real" accessibility
> features?

With our a11y library consumers get "all or nothing". There are no levels to a11y support. The switch is binary and is tied to the request I detailed above.

> 3. Do we disable e10s because these features exist (e.g. touchpad) on their
> own? or is that the fact that "accessibility is enabled" (possibly due to
> the existence of touchpad) which prevents usage with e10s?

e10s moves content into another process. Our a11y library was designed for a single process. The a11y team is currently working on upgrading the a11y library to support e10s. Until that work is complete we disable because a11y + e10s can cause all sorts of problem including hangs and crashes.
I am not technically oriented to Firefox Nightly (and therefore really do not understand the 2015-04-22 06:25:15 PDT commenting exchange just above.

I am commenting here at the request of Anthony Hughes 2015-05-01.
Regarding the inability of my copy of Nightly 64bit 40.0a1 to access/option E10s windows (available prior to accepting the update on 2015-05-01.

This is the whole line that is greyed out under Tools/Options/General:
"Enable E10S (multi-process) (disabled: An accessibility tool is or was active. See bug 1115956.)"

I tried a "Restart with Add-ons disabled",(Safe Mode?) but it made no difference - seems to rule-out blocking by Add-on, IIRC.
Anthony suggested my user file was corrupted, I looked for it - found a .dll way down deep,
but I have no way to check nor correct.

I tried uninstalling Nightly back to 36.0a1 (10/21/2014) in which E10s were available and selected in the file menu.
(Should I have checked to Tools/Options/General E10s box then?)

Anthony says this may be an "edge case" . . . (?)
"We intentionally turn off e10s if accessibility is detected on your system, however if you could use e10s before it should not be broken by an update. My recommendation would be to comment on bug 1115966 as it appears there's some edge cases the developers are trying to investigate and your system is likely hitting one of those edge cases."

OK, per Anthony's recommendation, since he is currently out of the loop(2015-05-02)I am asking for help on finding a work around for this issue. 
Should I try another uninstall, check the box - and then run thru the updates back to current?

thnx,
Try this:

1) update to latest nightly
2) open firefox and navigate to about:preferences
3) search for and reset the pref 'browser.tabs.remote.autostart.disabled-because-using-a11y'
4) restart

if you still get prompted, check the Browser Console under the tools menu for a diagnostic startup message. Also, please post your about support.
Whiteboard: [e10s] [a11y] [READ COMMENT 12 TO UNBLOCK E10S FOR YOU]
Jim,

The latest nightly no longer seems to disable e10s after resetting the pref and restarting a few times, so whatever was changed fixes the issue for me.
(In reply to Jim Mathies [:jimm] from comment #40)
> Try this:
> 
> 1) update to latest nightly
> 2) open firefox and navigate to about:preferences
> 3) search for and reset the pref
> 'browser.tabs.remote.autostart.disabled-because-using-a11y'
> 4) restart

In step 2 this should have been about:config, not preferences.
Flags: needinfo?(nedmoore1)
(In reply to Mark Straver from comment #41)
> Jim,
> 
> The latest nightly no longer seems to disable e10s after resetting the pref
> and restarting a few times, so whatever was changed fixes the issue for me.

Thanks!
Now THAT:  "In step 2 this should have been about:config, not preferences." made (scary) sense. Never seen that area before.)

I found the line as stated, altho it took me but a moment to equate "Reset" with the displayed  "Toggle", but it made sense.

I did a restart and the box was checked at "Enable E10s". Thanks Jim.
Flags: needinfo?(nedmoore1)
(In reply to Ned Moore from comment #44)
> Now THAT:  "In step 2 this should have been about:config, not preferences."
> made (scary) sense. Never seen that area before.)
> 
> I found the line as stated, altho it took me but a moment to equate "Reset"
> with the displayed  "Toggle", but it made sense.
> 
> I did a restart and the box was checked at "Enable E10s". Thanks Jim.

Excellent, glad it's working for you finally.
I don't quite understand, nightly disabled e10s because my IME has some accessibility tool feature, and after a restart, enable e10s check-box is gray out, said (See Bug 1115956 ), it's normal? Can I force e10s enable anyway?
I can't understand, why I'm getting this information every day. I don't using an accessibility tool or so on. I resetted the key in about:config "browser.tabs.remote.autostart.disabled-because-using-a11y" but after one-two hours I get the notification, that I would use one of these tools. But I didn't installed or performed something. I'm using only FF DevEdi, FileZilla + Microsoft WebMatrix & Windows Media Player - Not more...
Is there someone with similar problems? 

[Windows 8.1 x64]
(In reply to Kevin H. from comment #47)
> ... I don't using an accessibility tool or so on. 

As said in comment #2 the operating system alone may have the accessibility tools.  They are not necessarily separated software.
(In reply to Jim Mathies [:jimm] from comment #40)
> 3) search for and reset the pref
> 'browser.tabs.remote.autostart.disabled-because-using-a11y'

FYI: It seems to be (now) called "browser.tabs.remote.disabled-for-a11y".
On Friday I just had that message about a11y, I really haven't done anything. It took me 4 days to figure out how to re-enable e10s. There should be definitely a reset button in settings.
I have to go in and set browser.tabs.remote.disabled-for-a11y to false, then restart firefox dev ed every time I RDP to this box then later log in interactively.  Is this by design?
No, not by design.  It is an error handled in the meta bug 1029143. Windows counts an incoming RDP connection like a screen reader.
This bug affects also Firefox Developer Edition (42.0a2) on Linux (actually I'm using Fedora 22).
It seems setting browser.tabs.remote.disabled-for-a11y to false solve this problem.
Affected by the bug on Mac OS X 10.11 Beta (15A262e) with Firefox Developer Edition 42.0a2 (2015-08-24)
(In reply to Žilvinas from comment #54)
> Affected by the bug on Mac OS X 10.11 Beta (15A262e) with Firefox Developer
> Edition 42.0a2 (2015-08-24)

Seems I had some custom config set, as mentioned above my comment, resetting it fixed everything.
(In reply to aroblu94 from comment #53)
> This bug affects also Firefox Developer Edition (42.0a2) on Linux (actually
> I'm using Fedora 22).
> It seems setting browser.tabs.remote.disabled-for-a11y to false solve this
> problem.

Solved in 42.0a2 (2015-09-05). Thanks!
(In reply to aroblu94 from comment #53)
> This bug affects also Firefox Developer Edition (42.0a2) on Linux (actually
> I'm using Fedora 22).
> It seems setting browser.tabs.remote.disabled-for-a11y to false solve this
> problem.

Affected by this bug on Firefox Developer Edition 42.0a2 64bit on Windows 10. 
For now going to about:config, setting browser.tabs.remote.disabled-for-a11y to false solved the problem for me too.
Browser has brought me to this bug because it stated e10s is disabled because of this bug, even giving me the bug number, but this bug is "fixed". Reopen this bug or open a new one?
Yup, that's confusing.  The reason this bug is marked "fixed" is that (per its description) this bug is on improving the message (the one that you read) -- previously, that message said something like "You have an accessibility tool active", which was incorrect in most cases.  Now it's a bit clearer (hence, this bug being fixed).

The remaining issues that cause e10s to be disabled when Firefox thinks a11y tools might be active (or might have been active in the past) are tracked in bug 1029143 - you probably want to follow that bug or its dependencies.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: