Opened 7 months ago

Last modified 11 days ago

#27503 assigned defect

Disabling accessibility on Windows breaks screen readers

Reported by: gk Owned by: pospeselr
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-8.0-issues, tbb-regression, TorBrowserTeam201903, GeorgKoppen201903, tbb-8.5
Cc: jacek, Rastislav+Kiss, onionsoup, tbb-team Actual Points:
Parent ID: Points:
Reviewer: boklm 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

Attachments (3)

tor_accessibility.log (14.3 KB) - added by Rastislav Kiss 7 weeks ago.
TOR Debug.txt (14.6 KB) - added by OnionRing 7 weeks ago.
TOR debug file
debuglog.txt (16.6 KB) - added by onionsoup 7 weeks ago.

Download all attachments as: .zip

Change History (51)

comment:1 Changed 6 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 6 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 6 months ago by traumschule (previous) (diff)

comment:3 in reply to:  1 Changed 6 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 6 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 6 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 6 months ago by boklm

Cc: Rastislav Kiss added

#27862 is a duplicate.

comment:7 Changed 6 months ago by boklm

Cc: "Rastislav Kiss" added; Rastislav Kiss removed

comment:8 Changed 6 months ago by boklm

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

comment:9 Changed 6 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 5 months ago by pastly

Cc: onionsoup added

comment:11 Changed 4 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 4 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 4 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 4 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 4 months ago by gk

Keywords: GeorgKoppen201812 added; GeorgKoppen201811 removed

Moving my tickets to December.

comment:16 Changed 4 months ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

comment:17 Changed 4 months 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 4 months 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 3 months 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 3 months 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 3 months 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 3 months 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 months ago by gk

Keywords: GeorgKoppen201901 added; GeorgKoppen201812 removed

Moving my tickets.

comment:24 Changed 2 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:25 Changed 2 months 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 2 months 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 2 months 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 months 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 2 months 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... :)

comment:30 Changed 2 months ago by boklm

Reviewer: boklm

comment:31 Changed 2 months ago by cypherpunks33

:) #26148?

comment:32 in reply to:  31 Changed 2 months ago by gk

Replying to cypherpunks33:

:) #26148?

Yeah, I had the same idea but it's not that. So, I guess either a) Mozilla added some additional commit to esr60 that resolves this issue which I had not or b) the mingw-w64 diff explains this or c) I messed up the patch for this bug.

comment:33 Changed 8 weeks ago by cypherpunks33

Searching through a) doesn't show anything related, but https://bugzilla.mozilla.org/show_bug.cgi?id=1489605

comment:34 in reply to:  29 Changed 8 weeks ago by boklm

Status: needs_reviewnew

Replying to gk:

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.

This looks good to me. I merged those two patches to master with commit 97effd6d7380f76dd53e666b034113c84692f51a.

comment:35 Changed 8 weeks ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201901R removed

comment:36 Changed 7 weeks ago by gk

Okay, let's try finding out something with a debug build. I created one based on ESR 60.5.0 with accessibility support:

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

Could someone affected by this bug run it and attach the log output here reproducing the issue in comment:13? I hope we see some assertions in it that might give us a hint at what is going on and where to look closer.

Note: you might need to start Tor Browser several times until it finally starts up: once due to a crash on first start and the second time due to a bug in network status parsing on Windows which stalls the Tor startup.

Changed 7 weeks ago by Rastislav Kiss

Attachment: tor_accessibility.log added

Changed 7 weeks ago by OnionRing

Attachment: TOR Debug.txt added

TOR debug file

comment:37 Changed 7 weeks ago by Rastislav Kiss

I am affected by this too. I have run the test version. After several times it seemed like the connection was established, because the Firefox interface (accessible) showed up.
I was however unable to load any webpage, I tried several but nothing noticeable has actually happened.
I have copied output from Start tor browser window, i guess it is the log you are referring to.

Thank you for solving this!

comment:38 in reply to:  37 Changed 7 weeks ago by OnionRing

Replying to Rastislav Kiss:

I am affected by this too. I have run the test version. After several times it seemed like the connection was established, because the Firefox interface (accessible) showed up.
I was however unable to load any webpage, I tried several but nothing noticeable has actually happened.
I have copied output from Start tor browser window, i guess it is the log you are referring to.

Thank you for solving this!

Hi Rastislav Kiss,
I attached my debug as well as you can probably see. I'm not sure if it was very helpful though, because if I went to any web page for example google, the tab would keep crashing on me. This was not before I was able to reproduce the "unknown" message from NVDA however. Hopefully one of our logs will help.

Changed 7 weeks ago by onionsoup

Attachment: debuglog.txt added

comment:39 in reply to:  36 Changed 7 weeks ago by onionsoup

I consistently get a "your tab just crashed" message when running this build, so I can't actually load any webpages. The "your tab just crashed" page is accessible however.
Replying to gk:

Okay, let's try finding out something with a debug build. I created one based on ESR 60.5.0 with accessibility support:

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

Could someone affected by this bug run it and attach the log output here reproducing the issue in comment:13? I hope we see some assertions in it that might give us a hint at what is going on and where to look closer.

Note: you might need to start Tor Browser several times until it finally starts up: once due to a crash on first start and the second time due to a bug in network status parsing on Windows which stalls the Tor startup.

comment:40 Changed 7 weeks ago by gk

Keywords: GeorgKoppen201902 added; GeorgKoppen201901 removed

Moving my tickets to Feb

comment:41 Changed 7 weeks ago by gk

Thanks for the logs, that was helpful.

comment:42 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:43 Changed 2 weeks ago by chpross

Hi,
my name is Christopher and I am blind. I want to use the torbrowser, I had used it on 2016 but now I had this accessibility problems.
The Tor windows and all dialogs of the firefox browser are readable and for me no problem.
But the website is not accessible, with the newest torbrowser alpha on a windows 10 computer with NVDA 2018.4.1.
Do you work on the accessibility problems, can I help you with testing?
I hope you could fix the accessibility problems.

comment:44 Changed 2 weeks ago by chpross

Hi,
my name is Christopher and I am blind. I want to use the torbrowser, I had used it on 2016 but now I had this accessibility problems.
The Tor windows and all dialogs of the firefox browser are readable and for me no problem.
But the website-area is not accessible, with the newest torbrowser alpha on a windows 10 computer with NVDA 2018.4.1.
This means that if I tab to the area, where the website is shown and normaly the website is read out from NVDA, the Screenreader says now "unknown", what means that this is not readable or accessible for the screenreader.
Do you work on the accessibility problems, can I help you with testing?
I hope you could fix the accessibility problems.

comment:45 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving my tickets to March.

comment:46 Changed 2 weeks ago by gk

Keywords: GeorgKoppen201903 added; GeorgKoppen201902 removed

Now for my keyword.

comment:47 Changed 2 weeks ago by gk

Keywords: tbb-8.5 added

Tickets on our radar for 8.5

comment:48 Changed 11 days ago by pospeselr

Cc: tbb-team added
Owner: changed from gk to pospeselr
Status: newassigned
Note: See TracTickets for help on using tickets.