Opened 5 months ago

Last modified 3 hours ago

#27503 needs_review defect

Disabling accessibility on Windows breaks screen readers

Reported by: gk Owned by: gk
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-8.0-issues, tbb-regression, GeorgKoppen201901, TorBrowserTeam201901R
Cc: jacek, Rastislav+Kiss, onionsoup Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We need to compile Tor Browser 8 with accessibility disabled as mingw-w64 does not work with it right now. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1430149 for the Mozilla bug and https://sourceforge.net/p/mingw-w64/bugs/648/ for the underlying WIDL bug.

Maybe there is a workaround we can use? Or we could get the WIDL bug fixed?

Child Tickets

Change History (29)

comment:1 Changed 4 months ago by arma

I talked to a Windows user today on #tor who uses a screen reader and was reporting that Tor Browser 8 doesn't work for them. They reported that the Firefox ESR does work for them.

I guess it's because Firefox ESR is built with clang, and we want to build with mingw, for reproducible build purposes?

In any case, count another user affected by this bug.

comment:2 Changed 4 months ago by traumschule

It was not suggested before, just mentioning that this should not be activated per default (#26505), even if it worked (and users should be informed more about the consequences):

Firefox Accessibility Service is a technology built into Firefox that provides 3rd party applications running on the same device the ability to inspect, monitor, visualize, and alter web page content hosted within Firefox.

https://support.mozilla.org/en-US/kb/accessibility-services

Last edited 4 months ago by traumschule (previous) (diff)

comment:3 in reply to:  1 Changed 4 months ago by gk

Replying to arma:

I talked to a Windows user today on #tor who uses a screen reader and was reporting that Tor Browser 8 doesn't work for them. They reported that the Firefox ESR does work for them.

I guess it's because Firefox ESR is built with clang, and we want to build with mingw, for reproducible build purposes?

Yes and no. The reason for the bug is that mingw-w64 does not support the new accessibility related code in Firefox (widl is the problem here, to be more exact) *regardless* if you are using clang with it (which we will be doing soonish) or GCC (which we are doing now) as the compiler. mingw-w64 "just" provides the Windows headers etc.

comment:4 Changed 4 months ago by arma

We had another person on #tor today asking about this.

I wonder if we can use our twitter power to draw attention to the widl bug?

comment:5 in reply to:  4 Changed 4 months ago by gk

Replying to arma:

We had another person on #tor today asking about this.

I wonder if we can use our twitter power to draw attention to the widl bug?

We could do that. My idea was to ask around at a less noisy scale first to find someone who could help us with fixing this bug. But I guess we could to both in parallel.

comment:6 Changed 4 months ago by boklm

Cc: Rastislav Kiss added

#27862 is a duplicate.

comment:7 Changed 4 months ago by boklm

Cc: "Rastislav Kiss" added; Rastislav Kiss removed

comment:8 Changed 4 months ago by boklm

Cc: Rastislav+Kiss added; "Rastislav Kiss" removed

comment:9 Changed 4 months ago by traumschule

got an answer by jacekc on #mingw-w64 today

  1. try to avoid using the -acf option
  2. use an .idl input file instead
  3. we should look at widl bugs in wine

comment:10 Changed 3 months ago by pastly

Cc: onionsoup added

comment:11 Changed 2 months ago by gk

Note to self: when bumping the mingw-w64 version we can get rid of our CXXFLAGS in our mozconfig files as the widl changes we need come after commit a91a7e405752bbdbe39101f7aaeb1e1d932199db.

comment:12 Changed 2 months ago by gk

Status: newneeds_information

Could anyone being affected by this bug test the custom bundle below? It should have the fixes Jacek wrote for https://bugzilla.mozilla.org/show_bug.cgi?id=1430149 and is not exploding on my Windows 7 testing machine:

https://people.torproject.org/~gk/testbuilds/torbrowser-install-win64-tbb-nightly_27503_en-US.exe
https://people.torproject.org/~gk/testbuilds/torbrowser-install-win64-tbb-nightly_27503_en-US.exe.asc

Note: you might have trouble connecting to the Tor network when starting up Tor Browser the first time. In that case, closing Tor Browser and starting it again should fix that (I am currently looking into providing a bug report for that behavior for the network folks).

comment:13 Changed 2 months ago by onionsoup

Thank you for working on this! Tor button and browser controls are now accessible again. However, it appears that web content is not being exposed to the screen reader, so where the website should be rendered, there's just something called "unknown". I'm not sure what the cause of that is, but it is across all sites. I tested with about:tor, youtube and wikipedia. I tested with Windows 7 using NVDA as a screen reader. To summarise, screen reader users cannot interact with websites, but everything that is not web content works.

comment:14 in reply to:  13 Changed 2 months ago by gk

Keywords: TorBrowserTeam201811 GeorgKoppen201811 added
Owner: changed from tbb-team to gk
Status: needs_informationassigned

Replying to onionsoup:

Thank you for working on this! Tor button and browser controls are now accessible again. However, it appears that web content is not being exposed to the screen reader, so where the website should be rendered, there's just something called "unknown". I'm not sure what the cause of that is, but it is across all sites. I tested with about:tor, youtube and wikipedia. I tested with Windows 7 using NVDA as a screen reader. To summarise, screen reader users cannot interact with websites, but everything that is not web content works.

Thanks for the feedback. I guess the big question is "Is that caused by a missing accessibility patch OR by some other patches we ship"? I guess I compile a vanilla Firefox with the accessibility patches and we'll find out...

comment:15 Changed 7 weeks ago by gk

Keywords: GeorgKoppen201812 added; GeorgKoppen201811 removed

Moving my tickets to December.

comment:16 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

comment:17 Changed 7 weeks ago by gk

Status: assignedneeds_information

onionsoup (or anybody else): can you test the following zipped Firefox:

https://people.torproject.org/~gk/testbuilds/27503_test.zip
https://people.torproject.org/~gk/testbuilds/27503_test.zip.asc

?

On my Windows machine double-clicking on the .zip file in the explorer makes a Browser directory available. Then I dragged that one on the desktop and double-clicked on it. Double-clicking then on the firefox.exe should start Firefox. It's an ESR 60 Firefox just with Jacek's accessibility patches (without any we use for Tor Browser).

Does that one work for anyone with accessibility support (i.e. both chrome and content are rendering properly)?

comment:18 Changed 7 weeks ago by onionsoup

Hi
Web content is still not rendering properly for me with the clean Firefox, it behaves like the Tor Browser build. I run NVDA for screen reader on Windows 7.

comment:19 in reply to:  18 Changed 6 weeks ago by gk

Replying to onionsoup:

Hi
Web content is still not rendering properly for me with the clean Firefox, it behaves like the Tor Browser build. I run NVDA for screen reader on Windows 7.

Great, then let's dig deeper. One guess I have is that the problem is multi-process (e10s)/sandboxing related. Could you disable e10s by flipping browser.tabs.remote.autostart to false in your about:config and restart both Tor Browser and the Firefox I gave you? Does that change things?

(And no worries about not being well-versed in terminology. :) Just ask if I speak too jargon-y)

comment:20 Changed 6 weeks ago by onionsoup

Hi! :)
Yes!! Flipping browser.tabs.remote.autostart to false solved it, both on the Tor Browser and clean Firefox. Now everything is accessible. Awesome!
Ah excellent, will do! :)

comment:21 in reply to:  20 ; Changed 6 weeks ago by gk

Replying to onionsoup:

Hi! :)
Yes!! Flipping browser.tabs.remote.autostart to false solved it, both on the Tor Browser and clean Firefox. Now everything is accessible. Awesome!
Ah excellent, will do! :)

Great! So, we are on the right track then. Let's try a bit more to narrow the problem down. Can you flip back browser.tabs.remote.autostart to true and restart the browser? Then look after security.sandbox.content.level in your about:config. Can you set that to 0 and the value you are seeing right now and restart the browser between every change (trying to figure out if the sandbox is breaking accessibility and, if so, at which level this is happening)? Does that already help? If so, what is the first sandbox level that causes the trouble for you?

comment:22 in reply to:  21 Changed 6 weeks ago by onionsoup

Replying to gk:

Replying to onionsoup:

Hi! :)
Yes!! Flipping browser.tabs.remote.autostart to false solved it, both on the Tor Browser and clean Firefox. Now everything is accessible. Awesome!
Ah excellent, will do! :)

Great! So, we are on the right track then. Let's try a bit more to narrow the problem down. Can you flip back browser.tabs.remote.autostart to true and restart the browser? Then look after security.sandbox.content.level in your about:config. Can you set that to 0 and the value you are seeing right now and restart the browser between every change (trying to figure out if the sandbox is breaking accessibility and, if so, at which level this is happening)? Does that already help? If so, what is the first sandbox level that causes the trouble for you?

I tried all levels between 0 and 5 (the default), and accessibility seems to break at level 0, and doesn't work on any other levels.

comment:23 Changed 2 weeks ago by gk

Keywords: GeorgKoppen201901 added; GeorgKoppen201812 removed

Moving my tickets.

comment:24 Changed 12 days ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:25 Changed 6 days ago by gk

onionsoup: Mozilla is tracking the remaining part in https://bugzilla.mozilla.org/show_bug.cgi?id=1520177. Just to be sure: Accessibility works in Mozilla's official Firefox for you, right?

comment:26 Changed 3 days ago by OnionRing

Replying to gk:

onionsoup: Mozilla is tracking the remaining part in https://bugzilla.mozilla.org/show_bug.cgi?id=1520177. Just to be sure: Accessibility works in Mozilla's official Firefox for you, right?

Well I am not onionsoup, but I did not see a reply to this comment and I am affected by this issue. I can confirm that the official version of Firefox 64.0.2 works just fine for me with both NVDA and the latest version of JAWS. All of the recent versions of FF since version 60 have not presented any accessibility issues for me.

comment:27 in reply to:  26 Changed 3 days ago by onionsoup

Replying to OnionRing:

Replying to gk:

onionsoup: Mozilla is tracking the remaining part in https://bugzilla.mozilla.org/show_bug.cgi?id=1520177. Just to be sure: Accessibility works in Mozilla's official Firefox for you, right?

Well I am not onionsoup, but I did not see a reply to this comment and I am affected by this issue. I can confirm that the official version of Firefox 64.0.2 works just fine for me with both NVDA and the latest version of JAWS. All of the recent versions of FF since version 60 have not presented any accessibility issues for me.

My apologies for the late reply, I've been without internet. Indeed, the official Firefox builds are accessible to me, using the latest NVDA on Windows.

comment:28 in reply to:  12 ; Changed 2 days ago by cypherpunks3

Jacek's patches landed in Firefox 66 (Firefox Nightly now) which should be tested instead of Firefox 64.0.2.

Replying to gk:

it crashes early on my Windows 7 test box

Is it up-to-date?

comment:29 in reply to:  28 Changed 3 hours ago by gk

Keywords: TorBrowserTeam201901R added; TorBrowserTeam201901 removed
Status: needs_informationneeds_review

Replying to cypherpunks3:

Jacek's patches landed in Firefox 66 (Firefox Nightly now) which should be tested instead of Firefox 64.0.2.

Nope 64.0.2 was good as the point was to check whether the accessibility support Mozilla provides right now is working while the Tor Browser one is not (and the former is not related to Jacek's patches).

So, I think we should move a step forward and test what we get with the switch to ESR 60.5.0. At least this allows the workaround in comment:19 and allows us to shake out more bugs. Additionally, it allows us to start from a better position to debug the problem.

bug_27503_v3 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_27503_v3) in my tor-browser-build repo has the two fixes for review. We should have committed the first one when fixing #28874 but forgot about it. The second one is actually enabling accessibility support. To test everything one needs a rebased branch against 60.5.0esr, which e.g. be found in #29104.

Previously, I needed an additional mingw-w64 patch to unbreak the build but that's not needed anymore. It's not clear yet why that happens. I verified the patches I used back then are the same that are on esr60 and the diff between the mingw-w64 versions used then (172cf5520c61a607cc5acb59e2709bf303e5ec47) and now (2d4e517ad0c7a9f0bd7001c42e6c131b977c15d9) does not show anything obvious. I am not complaining... :)

Note: See TracTickets for help on using tickets.