Disabling accessibility on Windows breaks screen readers
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?
Designs
- #41280Sponsor 131 - Phase 3 - Major ESR 102 Migration
Activity
added GeorgKoppen201903 in Legacy / Trac TorBrowserTeam201907R in Legacy / Trac component::applications/tor browser in Legacy / Trac owner::pospeselr in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac reviewer::boklm in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tbb-8.0-issues in Legacy / Trac tbb-8.5 in Legacy / Trac tbb-backported in Legacy / Trac tbb-regression in Legacy / Trac type::defect in Legacy / Trac labels
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.
It was not suggested before, just mentioning that this should not be activated per default (legacy/trac#26505 (moved)), 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
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.
-
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.
legacy/trac#27862 (moved) is a duplicate.
Trac:
Cc: jacek to jacek, Rastislav, Kissgot an answer by jacekc on #mingw-w64 today
- try to avoid using the -acf option
- use an .idl input file instead
- we should look at widl bugs in wine
-
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).
Trac:
Status: new to needs_information 
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.
Trac:
Username: onionsoup-
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...
Trac:
Owner: tbb-team to gk
Keywords: N/A deleted, TorBrowserTeam201811, GeorgKoppen201811 added
Status: needs_information to assigned -
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.exeshould 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)?
Trac:
Status: assigned to needs_information -
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.autostarttofalsein yourabout:configand 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)
-
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.autostarttotrueand restart the browser? Then look aftersecurity.sandbox.content.levelin yourabout:config. Can you set that to0and 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? -
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.autostarttotrueand restart the browser? Then look aftersecurity.sandbox.content.levelin yourabout:config. Can you set that to0and 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.
Trac:
Username: onionsoup -
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?
-
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.
Trac:
Username: OnionRing -
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.
Trac:
Username: onionsoup -
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 mytor-browser-buildrepo has the two fixes for review. We should have committed the first one when fixing legacy/trac#28874 (moved) 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 legacy/trac#29104 (moved).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... :)
Trac:
Keywords: TorBrowserTeam201901 deleted, TorBrowserTeam201901R added
Status: needs_information to needs_review -
Replying to cypherpunks33:
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.
Searching through a) doesn't show anything related, but https://bugzilla.mozilla.org/show_bug.cgi?id=1489605
-
Replying to gk:
bug_27503_v3(https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_27503_v3) in mytor-browser-buildrepo has the two fixes for review. We should have committed the first one when fixing legacy/trac#28874 (moved) 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 legacy/trac#29104 (moved).This looks good to me. I merged those two patches to master with commit
97effd6d7380f76dd53e666b034113c84692f51a.Trac:
Status: needs_review to new -
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.
-
Trac:
Username: Rastislav Kiss -
Trac:
Username: OnionRing -
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!
Trac:
Username: Rastislav Kiss -
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.
Trac:
Username: OnionRing -
Trac:
Username: 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.
Trac:
Username: onionsoup -
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.
Trac:
Username: 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.
Trac:
Username: chpross -
Trac:
Username: PZajda
Cc: jacek, Rastislav+Kiss, onionsoup, tbb-team to jacek, Rastislav+Kiss, onionsoup, tbb-team, patrick@zajda.fr 
So after applying patches in ( https://bug1520177.bmoattachments.org/attachment.cgi?id=9039768 ) I've a working (albeit hacked together) build working with NVDA on Windows 10. The strange thing is that Mozilla folks are reporting a crash in their build with the same patches applied, so I'm a bit confused. It's possible there is a bug in the version of mingw or clang they are using that I haven't hit, will investigate further.
EDIT: also possible the issue only occurs on 64-bit with patches applied
-
Replying to pospeselr:
So after applying patches in ( https://bug1520177.bmoattachments.org/attachment.cgi?id=9039768 ) I've a working (albeit hacked together) build working with NVDA on Windows 10. The strange thing is that Mozilla folks are reporting a crash in their build with the same patches applied, so I'm a bit confused. It's possible there is a bug in the version of mingw or clang they are using that I haven't hit, will investigate further.
I've hit the problem with our setup as well, see e.g. my comment:36.
EDIT: also possible the issue only occurs on 64-bit with patches applied
That's interesting. Care to share a 32bit bundle so others affected in this bug can test/verify that assumption?
-
Replying to gk:
That's interesting. Care to share a 32bit bundle so others affected in this bug can test/verify that assumption?
I had bundle baking over night and it has the same (correct) behaviour as my hacked together one:
32-bit: https://people.torproject.org/~richard/builds/torbrowser-nightly_en-US-i686-27503.exe 64-bit: later today
-
Replying to pospeselr:
Replying to gk:
That's interesting. Care to share a 32bit bundle so others affected in this bug can test/verify that assumption?
I had bundle baking over night and it has the same (correct) behaviour as my hacked together one:
32-bit: https://people.torproject.org/~richard/builds/torbrowser-nightly_en-US-i686-27503.exe 64-bit: later today
I just ran the 32 bit test bundle. When I load pages now, NVDA doesn't seem to treat them as a web page, though it is able to tab around to links, form controls and such. I am, however, unable to switch to browse mode to interact with the document like a webpage (I tried pressing NVDA+space, nothing happened). To see what NVDA should be doing, try going into Firefox or Chrome, and navigate by element, such as to next heading (press h) or read the webpage with arrow keys. I suspect that the fix is simple, as NVDA definitely sees the rendered content, it just doesn't seem to treat it as a web document. Hopefully I make sense - I'm not very well-versed in terminology.
Trac:
Username: onionsoup -
Replying to onionsoup:
Replying to pospeselr:
Replying to gk:
That's interesting. Care to share a 32bit bundle so others affected in this bug can test/verify that assumption?
I had bundle baking over night and it has the same (correct) behaviour as my hacked together one:
32-bit: https://people.torproject.org/~richard/builds/torbrowser-nightly_en-US-i686-27503.exe 64-bit: https://people.torproject.org/~richard/builds/torbrowser-nightly_en-US-amd64-27503.exe
I just ran the 32 bit test bundle. When I load pages now, NVDA doesn't seem to treat them as a web page, though it is able to tab around to links, form controls and such. I am, however, unable to switch to browse mode to interact with the document like a webpage (I tried pressing NVDA+space, nothing happened). To see what NVDA should be doing, try going into Firefox or Chrome, and navigate by element, such as to next heading (press h) or read the webpage with arrow keys. I suspect that the fix is simple, as NVDA definitely sees the rendered content, it just doesn't seem to treat it as a web document. Hopefully I make sense - I'm not very well-versed in terminology.
Sorry, didn't know NVDA could do that. So what I see (on 32-bit Windows 10 with 32-bit Tor Browser) is that NVDA now reads out web content when it's moused-over (where as before it did not).
-
I've built and tested 64 bit as well and see the same behavior as described above in 64-bit Windows 10 with (ie able to read page contents via mouse-over using NVDA)
Here's the current changeset used to build the above nightlies (literally just the current patch from the Mozilla bug)
https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_27503_v2
-
Replying to pospeselr:
I've built and tested 64 bit as well and see the same behavior as described above in 64-bit Windows 10 with (ie able to read page contents via mouse-over using NVDA)
Here's the current changeset used to build the above nightlies (literally just the current patch from the Mozilla bug)
https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_27503_v2
Okay, I looked at the history of where I left dealing with the bug figuring out why this seems to work better now.
So, in ESR 60.5.0 all the patches done by Jacek in https://bugzilla.mozilla.org/show_bug.cgi?id=1430149 landed. The still relevant comments then start with comment:36. I think I built the bundle there with the patch in your
bug_27503_v2applied. While I did not expect the bundle closer it asserts at the same place as Tom's https://treeherder.mozilla.org/#/jobs?repo=try&revision=c5ef984f2726adce22144c7a0d843ae761b94c6e (see Jacek's comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1520177#c15 and the attached debuglog.txt to this bug). I think my https://bugzilla.mozilla.org/show_bug.cgi?id=1520177#c19 is referring to that.All those builds are debug builds, however, while yours are none it seems. Thus, one thing we could test is whether you see the same problem compiling with
--enable-debug.But then, why are non-debug builds working better now? Not sure, yet. I guess one of the fixes in your patch on
bug_27503_v2could have helped with non-debug builds as well. Might be worth figuring out which one of those changes does that (assuming you run into the same problem as described pre comment:36 without any of the patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1520177 applied). -
Replying to gk:
Replying to pospeselr:
I've built and tested 64 bit as well and see the same behavior as described above in 64-bit Windows 10 with (ie able to read page contents via mouse-over using NVDA)
Here's the current changeset used to build the above nightlies (literally just the current patch from the Mozilla bug)
https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_27503_v2
Okay, I looked at the history of where I left dealing with the bug figuring out why this seems to work better now.
So, in ESR 60.5.0 all the patches done by Jacek in https://bugzilla.mozilla.org/show_bug.cgi?id=1430149 landed. The still relevant comments then start with comment:36. I think I built the bundle there with the patch in your
bug_27503_v2applied. While I did not expect the bundle closer it asserts at the same place as Tom's https://treeherder.mozilla.org/#/jobs?repo=try&revision=c5ef984f2726adce22144c7a0d843ae761b94c6e (see Jacek's comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1520177#c15 and the attached debuglog.txt to this bug). I think my https://bugzilla.mozilla.org/show_bug.cgi?id=1520177#c19 is referring to that.All those builds are debug builds, however, while yours are none it seems. Thus, one thing we could test is whether you see the same problem compiling with
--enable-debug.Yes, that's been it: we are hitting the assert on the debug builds which result in a broken experience. The non-debug builds (i.e. those we ship) are less affected: there is accessibility support even though it's not fully on par with that offered by vanilla Firefox). I'll take the patch from pospeselr's
bug_27503_v2for the upcoming alpha to give it wider testing. That's commit f5f845f5 ontor-browser-60.6.1esr-8.5-1and will hopefully be available in 8.5a11.Leaving this ticket open to investigate and fix the remaining issues.
If you say https://gitweb.torproject.org/tor-browser.git/diff/toolkit/library/moz.build?h=tor-browser-60.6.1esr-8.5-1&id=f5f845f5fe14b5085f919ba46ec092b14c7fcb11, shouldn't you say https://gitweb.torproject.org/tor-browser.git/tree/toolkit/library/moz.build?h=tor-browser-60.6.1esr-8.5-1&id=477af8c709134b57b530b4b94ce6b4c82cb46fce#n111
-
Ok this thread's been a bit dead for awhile but lots of things have been happening in other parts of the internet. The root cause for this issue is that the widl build tool (wine's reimplmentation of midl.exe used to generate the code and binary blobs needed for RPC and COM Proxies to work) was generating bad bits in many interesting ways.
These issues have been added to the winehq bug-tracker : https://bugs.winehq.org/buglist.cgi?email1=richard%40torproject.org&emailreporter1=1&emailtype1=exact&list_id=663167
I've a wine fork with fixes for the various issues blocking us here: https://github.com/pospeselr/wine
The squashed branch has all needed fixes and I've verified with a hacked together windows build that the screen reader works as expected, doesn't crash Tor Browser, the ia2 interfaces are proxied correctly and pages are navigable via arrow keys (so if I get hit by a bus that's where you'll need to start).
The work that remains:
- patches for (wine) 47035, 47041, 47049, and 47050 need to be merged into wine (47035 is hard in particular as it requires a non-trivial refactor and the wine devs justifiably don't want to look at the giant diff)
- the updated widl needs to ride the trains into mingw
- and while we wait for that to happen, the updated widl need to be rebased against the mingw version and the resulting patch added to tor-browser-build's mingw project
I'm OOF in the wilderness starting tomorrow through Monday but I should be able to do a good chunk of this on Saturday, and I would guess we'd see a tor-browser-build patch ready for prime-time by middle of next week (the mingw 'branch' of widl is a bit weird and may cause some headaches).
-
Oh hey check it out a patch to review! This branch includes a temporary patch to mingw-w64 that brings over a squashed version of this patchset ( https://github.com/pospeselr/wine/tree/widldev ) along with a few mingw specific changes to the widl.c, configure, and VERSION files.
tor-browser-build: https://gitweb.torproject.org/user/richard/tor-browser-build.git/commit/?h=bug_27503
Test builds:
i686: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-i686-27503-candidate1.exe amd64: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-amd64-27503-candidate1.exe
NOTE: The final commit of the 'widldev' wine branch is a bit different from the final commit of the 'squashed' branch, as I discovered and fixed a few subtle problems through the processes of splitting up commits (as well as some const-correctness issues).
-
Ok for better reviewability, here is the widl changes that fix the various bugs, as well as a change to widl.c that mingw applies when building to handle mingw's default include directories.
wine: https://github.com/pospeselr/wine/commits/bug_27503
Once my current build finishes, I'll amend the tor-browser-build branch for mingw to remove the changes to VERSION and configure as they only update the version string to 4.9 from 3.20 but doesn't functionally alter any of the compiler output (apart from version strings)
To generate the mingw-w64 patch in the bug_27503 tor-browser-build branch for yourself, you will need to first build wine (to generate the parser source from the yacc grammar file), then copy all of the *.c, *.h, *.l, and *.y files from the
wine/tools/widldirectory tomingw-w64/mingw-w64-tools/widl/srcdirectory and do agit diff. This should generate the same 27503.patch file intor-browser-build/projects/mingw-w64NOTE: To build widl, from the wine root do a
./configure --without-x --without-freetypeand the usualmakeTrac:
Keywords: TorBrowserTeam201905 deleted, TorBrowserTeam201906R added -
Rebased against wine master after they pushed a fix to our crash from last week:
wine (with mingw patch applied): https://github.com/pospeselr/wine/commits/bug_27503 wine (dev branch, bug_27503~1) : https://github.com/pospeselr/wine/commits/winedev
Amended the 27503 patch with latest widl from wine and removed the VERSION related changes to mingw as they aren't necessary to get the build working:
tor-browser-build: https://gitweb.torproject.org/user/richard/tor-browser-build.git/commit/?h=bug_27503&id=388844385b50cf0502f758a11328f693cdac979d
Test builds:
i686: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-i686-27503-candidate2.exe amd64: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-amd64-27503-candidate2.exe
Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201906 deleted, TorBrowserTeam201906R added -
Replying to cypherpunks:
Reader's questions (will be removed soon):
Can
nullptrbe used?No the wine source is C89, not C++11
https://github.com/pospeselr/wine/commit/b7aec156edc46528e90338bf56bfef0ceaca4217 Different Wine-Bug?
This patch squashes together 18 patches and fixes all the Wine-Bugs as well as some un-filed wine bugs preventing screen readers from working.
https://github.com/pospeselr/wine/commit/7a77bb55dff25254b26309a56575f93586eb0203 " inline" instead of "inline "?
The difference between the two is on purpose.
/* FIXME: do we need to handle call_as? */
We do not, call_as attribute does not appear in the ia2 idl definitions.
https://github.com/pospeselr/wine/commit/c2d320d79644536ad988bda863b6f689451ee4e0 {{{ if (name && (t = find_type(name, namespace, tsENUM))) return t; }}} Is that coding style acceptable?
Yes, this section of the patchset was originally written by one of the wine devs, but couldn't be applied without the decl_spec_t refactor.
I don't like it either but code beautification was not the focus of this patch set.
https://github.com/pospeselr/wine/commit/8e043b2f955d76fbf11285e5477d97d89f5065c4#diff-e75b8f9447cd0082fdc2e72d13b6f240R36 No need to move
*?Fair enough.
https://github.com/pospeselr/wine/commit/a901af46040902d43d8ed0f70702d0a2f589fb15#diff-8905c813ddc5a5cf9d568bae351c24e5R2401
elementhere, butelemin all other places? Maybe, some better names?Where possible names were kept the same to minimize the size of the patch set. The 'elem' name here is a type_t and used on multiple lines whereas the 'element' (which is the name of the 'type' in an array) is a decl_spec_t and used in this one place. decl_spec_t has an instance of a type_t.
https://github.com/pospeselr/wine/commit/2bf54a0f57566ad7b27194c5f45ccb895cb275ac#diff-8d894b6473d010f03261aa6855bc65fdR64 Better naming than adding
2?Perhaps, I'll let the wine devs offer a better alternative.
Essentially, this was the culprit behind types being multiply defined in the generated typelib. The only remaining duplication is for a specific pointer type. This remaining dup is fine because the reason we wish to avoid duplicates is so that user defined structs, unions, and enums can be compared directly by pointer to determine if the 'thing' is the same type. Such a comparison is not needed for pointer types.
-
Replying to pospeselr:
Test builds:
i686: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-i686-27503-candidate2.exe amd64: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-amd64-27503-candidate2.exe
Verified these both now working as expected on both 32 bit and 64 bit windows: NVDA screen reading and navigation working, and pounding a representative sample of the IA2 APIs no longer causes a crash. If any screen reader users could try these out that'd be great.
-
Hi, I have tried again the 64-bit version, but it keeps crashing. The connection screen is okay, then NVDA announces the title of webpage: "About tor browser", and the window disappears immediately. There is no obvious error message, I'm using Windows 10 1809 64-bit pro.
Trac:
Username: Rastislav Kiss -
Replying to Rastislav Kiss:
Hi, I have tried again the 64-bit version, but it keeps crashing. The connection screen is okay, then NVDA announces the title of webpage: "About tor browser", and the window disappears immediately. There is no obvious error message, I'm using Windows 10 1809 64-bit pro.
Ok interesting, does it crash for you if you open tor browser first and then run NVDA?
-
Hmm, this seems very interesting. I have tried few screenreaders, turning them on after Tor browser's start, and there seem to be different reaction for everyone. Jaws, 64-bit screenreader, murders Torbrowser regardless of the current position in system immediately after startup. NVDA, 32-bit one, Torbrowser keeps running while I'm not in its window. After focusing it, even this can be survived if i left it before NVDA starts to load the page, what is announced by voice, then Torbrowser crashes. Microsoft Narrator, Windows built-in screenreader, totally surprisingly, this works! The page loads, can be read and there are no crashes. Although navigation by arrow keys doesn't work, it doesn't in Chrome as well, so this is rather Narrator's bug than Tor browser's problem I guess.
Trac:
Username: Rastislav Kiss -
Ok, sorry to be a pedant but can you clarify which version of which software you're running with each result? IE for each scenario I need to know:
- version of Windows and whether 32 or 64 bit
- 32 or 64 bit Tor Browser
- version of Screen Reader
- result vs expected
On my end there are 3 base scenarios (multiplied by the number of screen readers):
- 32 bit windows w/ 32 bit Tor Browser
- 64 bit windows w/ 32 bit Tor Browser
- 64 bit windows w/ 64 bit Tor Browser
I'm currently looking into NVDA crashing 64-bit Tor Browser on 64-bit Windows 10 when transitioning from the tor network connection window to the main browser window. From what I can tell both 32 bit Tor Browser scenarios are working (with NVDA at least).
Thanks!
-
Wow, I just tried the 32-bit version of Tor browser, and it works, with all screenreaders! Completely accessible. Amazing! But in order, here are my versions:
Windows 10 1809 pro 64-bit Jaws 2019.1906.10 pro 64-bit NVDA 2019.1.1 32-bit
Tor browser your test build 64-bit: NVDA: TB crashes when NVDA want to load the page from browser to its internal buffers Jaws: TB crashes, when a page is loaded. Windows Narrator: Works.
Tor browser, your test build, 32-bit: NVDA: Works. Jaws: Works. Window Narrator: Works.
So, as you said, problem is just with the 64-bit build of tor browser. 32-bit works, fantastic job.
Trac:
Username: Rastislav Kiss -
Ok so the crash we're seeing on 64-bit windows is an exception raised by combase.dllObjectStublessClient. Essentially that method bails out if it's found the stub was built with midl.exe older than version 5.2.202, so the fix is to just update the version constant inserted by widl. I've tested on 64-bit windows with NVDA and Tor Browser now transitions from the network dialog to the main browser window without crashing.
wine (for wine-devel review): https://github.com/pospeselr/wine/commits/winedev wine (with mingw include patch): https://github.com/pospeselr/wine/commits/bug_27503
tor-browser-build (ammended with updated widl patch): https://gitweb.torproject.org/user/richard/tor-browser-build.git/commit/?h=bug_27503
Test builds: i686: soon amd64: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-amd64-27503-candidate3.exe
What's the reason to not update the version to the latest one? As MinGW-W64 declares support for WinRT, it should be 8.1.622 or later: https://docs.microsoft.com/en-us/uwp/midl-3/
-
Hi, i have tried the 64-bit version and it works! With all threee screenreaders. Brilliant! I would like to thank you very very much and also all others, who worked on this issue so intensively. It's very nice to see developers who care about the accessibility.
Best regards and many thanks
Rastislav
Trac:
Username: Rastislav Kiss -
Replying to cypherpunks:
What's the reason to not update the version to the latest one? As MinGW-W64 declares support for WinRT, it should be 8.1.622 or later: https://docs.microsoft.com/en-us/uwp/midl-3/
https://github.com/wine-mirror/wine/blob/master/tools/widl/proxy.c#L70
-
Replying to Rastislav Kiss:
Hi, i have tried the 64-bit version and it works! With all threee screenreaders. Brilliant! I would like to thank you very very much and also all others, who worked on this issue so intensively. It's very nice to see developers who care about the accessibility.
Best regards and many thanks
Rastislav
I'm glad to hear that Rasislav, I really am. However, take care when using this test build. There were a few critical security fixes recently pushed out to Tor Browser and I do not know if these test builds have them. I would recommend holding off on using them until I can verify they are fully up to date.
EDIT: Ok it looks like the posted 64-bit build might have one of the fixes and definitely does not have the other. I will make some new builds with these security fixes ASAP.
Replying to pospeselr:
Replying to cypherpunks:
What's the reason to not update the version to the latest one? As MinGW-W64 declares support for WinRT, it should be 8.1.622 or later: https://docs.microsoft.com/en-us/uwp/midl-3/
https://github.com/wine-mirror/wine/blob/master/tools/widl/proxy.c#L70 And?.. What are the cons?
-
Test builds built against tor-browser-60.7.0esr-9.0-2 with security fixes I mentioned before:
i686: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-i686-27503-candidate4.exe amd64: https://people.torproject.org/~richard/builds/torbrowser-install-tbb-nightly_en-US-amd64-27503-candidate4.exe
-
To any future code archaeologists or devs having to deal with similar COM or IA2 problems when using the mingw toolchain, here's a couple tools for you:
ia2_test: https://github.com/pospeselr/ia2_test
This is basically a fake screen-reader. It grabs the IAccessible object at a given point in screen-space, and recursively iterates over all the children calling IA2 APIs. Not all the APIs are covered (as I stopped implementing calls when screen readers stopped crashing Tor Browser) but is easy enough to add more.
mingw_com: https://github.com/pospeselr/mingw_com
A standalone mingw-based project for construction a COM client, proxy and server. I used this briefly as a minimal COM test-bed for reproducing marshaling related crashes. Should note that the project as is will compile but will fail at runtime with the current stock version of mingw.
