Opened 12 months ago

Closed 6 weeks ago

#27503 closed defect (fixed)

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, GeorgKoppen201903, tbb-8.5, TorBrowserTeam201907R, tbb-backport
Cc: jacek, Rastislav+Kiss, onionsoup, tbb-team, patrick@… 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 months ago.
TOR Debug.txt (14.6 KB) - added by OnionRing 7 months ago.
TOR debug file
debuglog.txt (16.6 KB) - added by onionsoup 7 months ago.

Download all attachments as: .zip

Change History (102)

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

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

Cc: Rastislav Kiss added

#27862 is a duplicate.

comment:7 Changed 11 months ago by boklm

Cc: "Rastislav Kiss" added; Rastislav Kiss removed

comment:8 Changed 11 months ago by boklm

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

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

Cc: onionsoup added

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

Keywords: GeorgKoppen201812 added; GeorgKoppen201811 removed

Moving my tickets to December.

comment:16 Changed 9 months ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

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

Keywords: GeorgKoppen201901 added; GeorgKoppen201812 removed

Moving my tickets.

comment:24 Changed 7 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:25 Changed 7 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 7 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 7 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 7 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 7 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 7 months ago by boklm

Reviewer: boklm

comment:31 Changed 7 months ago by cypherpunks33

:) #26148?

comment:32 in reply to:  31 Changed 7 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 7 months 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 7 months 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 7 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201901R removed

comment:36 Changed 7 months 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 months ago by Rastislav Kiss

Attachment: tor_accessibility.log added

Changed 7 months ago by OnionRing

Attachment: TOR Debug.txt added

TOR debug file

comment:37 Changed 7 months 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 months 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 months ago by onionsoup

Attachment: debuglog.txt added

comment:39 in reply to:  36 Changed 7 months 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 months ago by gk

Keywords: GeorgKoppen201902 added; GeorgKoppen201901 removed

Moving my tickets to Feb

comment:41 Changed 7 months ago by gk

Thanks for the logs, that was helpful.

comment:42 Changed 6 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:43 Changed 6 months 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 6 months 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 6 months ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving my tickets to March.

comment:46 Changed 6 months ago by gk

Keywords: GeorgKoppen201903 added; GeorgKoppen201902 removed

Now for my keyword.

comment:47 Changed 6 months ago by gk

Keywords: tbb-8.5 added

Tickets on our radar for 8.5

comment:48 Changed 5 months ago by pospeselr

Cc: tbb-team added
Owner: changed from gk to pospeselr
Status: newassigned

comment:49 Changed 5 months ago by gk

Keywords: tbb-8.5-must added; tbb-8.5 removed

Marking blockers for Tor Browser 8.5.

comment:50 Changed 5 months ago by PZajda

Cc: patrick@… added

comment:51 Changed 5 months ago by 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.

EDIT: also possible the issue only occurs on 64-bit with patches applied

Last edited 5 months ago by pospeselr (previous) (diff)

comment:52 in reply to:  51 ; Changed 5 months ago by gk

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?

comment:53 in reply to:  52 ; Changed 5 months ago by 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*

comment:54 in reply to:  53 ; Changed 5 months ago by 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: *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.

comment:55 in reply to:  54 Changed 5 months ago by pospeselr

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).

Last edited 5 months ago by pospeselr (previous) (diff)

comment:56 Changed 5 months ago by gk

Keywords: TorBrowserTeam201904 added; TorBrowserTeam201903 removed

Moving tickets to April.

comment:57 Changed 5 months ago by 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

comment:58 in reply to:  57 ; Changed 5 months ago by 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_v2 applied. 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_v2 could 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).

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

comment:59 in reply to:  58 Changed 4 months ago by gk

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_v2 applied. 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_v2 for the upcoming alpha to give it wider testing. That's commit f5f845f5fe14b5085f919ba46ec092b14c7fcb11 on tor-browser-60.6.1esr-8.5-1 and will hopefully be available in 8.5a11.

Leaving this ticket open to investigate and fix the remaining issues.

comment:61 Changed 3 months ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:62 Changed 3 months ago by pospeselr

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).

comment:63 Changed 2 months ago by pospeselr

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).

Last edited 2 months ago by pospeselr (previous) (diff)

comment:64 Changed 2 months ago by pospeselr

Status: assignedneeds_review

comment:65 Changed 2 months ago by cypherpunks

BTW, if you want to get a review from the Tor Browser team, you should set TorBrowserTeam201906R keyword.

comment:66 in reply to:  65 Changed 2 months ago by pospeselr

Keywords: TorBrowserTeam201906R added; TorBrowserTeam201905 removed

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/widl directory to mingw-w64/mingw-w64-tools/widl/src directory and do a git diff. This should generate the same 27503.patch file in tor-browser-build/projects/mingw-w64

NOTE: To build widl, from the wine root do a ./configure --without-x --without-freetype and the usual make

comment:67 Changed 2 months ago by Rastislav Kiss

I have tried the amd 64 test build. When I launch it, a connection is being established and when it's finished, program crashes without any error.

comment:68 Changed 2 months ago by pospeselr

Can confirm, NVDA reliably crashes Tor Browser (both 32 and 64-bit flavors) on 64-bit windows. An interesting puzzle... for next week.

comment:69 Changed 2 months ago by cypherpunks

Last edited 2 months ago by cypherpunks (previous) (diff)

comment:70 Changed 2 months ago by gk

Keywords: TorBrowserTeam201906 added; TorBrowserTeam201906R removed
Status: needs_reviewneeds_revision

comment:71 Changed 2 months ago by gk

Keywords: tbb-8.5 added; tbb-8.5-must removed

8.5 is out toning down the keywords.

comment:72 Changed 2 months ago by pospeselr

Keywords: TorBrowserTeam201906R added; TorBrowserTeam201906 removed
Status: needs_revisionneeds_review

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

Last edited 2 months ago by pospeselr (previous) (diff)

comment:73 in reply to:  69 Changed 2 months ago by pospeselr

Replying to cypherpunks:

Reader's questions (will be removed soon):

Can nullptr be 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.

Also https://github.com/pospeselr/wine/blob/2bf54a0f57566ad7b27194c5f45ccb895cb275ac/tools/widl/header.c#L506

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
element here, but elem in 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.

https://github.com/pospeselr/wine/commit/26df75e01e1313fd6f8d3fc8cb91ddd5678068dd#diff-e75b8f9447cd0082fdc2e72d13b6f240L56
Fixed?

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.

comment:74 in reply to:  72 Changed 2 months ago by pospeselr

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.

Last edited 2 months ago by pospeselr (previous) (diff)

comment:75 Changed 2 months ago by 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.

comment:76 in reply to:  75 Changed 2 months ago by pospeselr

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?

comment:77 Changed 2 months ago by Rastislav Kiss

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.

comment:78 Changed 2 months ago by Rastislav Kiss

Just to be sure, when I talked about leaving Tor browser window before loading page with NVDA, I meaned loading by screenreader to its internal buffer, not loading by the browser when it wants to open the page.

comment:79 Changed 2 months ago by pospeselr

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!

comment:80 Changed 2 months ago by Rastislav Kiss

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.

comment:81 Changed 2 months ago by pospeselr

Thank you very much for this breakdown Rastislav, that clears things up for me. I'm glad to hear 32-bit is working for you.

comment:82 Changed 2 months ago by pospeselr

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

comment:83 Changed 2 months ago by 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/

comment:84 Changed 2 months ago by 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

comment:85 in reply to:  83 ; Changed 2 months ago by 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

comment:86 in reply to:  84 Changed 2 months ago by pospeselr

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.

Last edited 2 months ago by pospeselr (previous) (diff)

comment:87 in reply to:  85 Changed 2 months ago by cypherpunks

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?

comment:89 Changed 2 months ago by pospeselr

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.

comment:90 in reply to:  88 Changed 8 weeks ago by onionsoup

I just tested the 64 build, and it works perfectly!
Not sure if this is the right place to put it, but thank you so much for making accessibility a priority! It is very, very much appreciated.
Replying to pospeselr:

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

comment:91 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201907R added; TorBrowserTeam201906R removed

No reviews in June 2019 anymore, moving them.

comment:92 Changed 7 weeks ago by pospeselr

Ok here's everything you should need to review gk:

wine: https://github.com/pospeselr/wine/commits/winedev2

This wine branch is my review dev branch as of yesterday. I have one more piece of feedback to work on (commit 8baf184001c6bcdc3ec1867c6bb6fa82b5ffed15 ) before it's again submitted for review. I'm be switching over to a new winedev3 branch to make sure everything stays lined up on our end.

mingw-w64: https://github.com/pospeselr/mingw-w64/commits/bug_27503

This branch has two commits on top of commit 2d4e517ad0c7a9f0bd7001c42e6c131b977c15d9 used in tor-browser-build.

The first is a copy of widl's .c, .h, .l and .y files from the last commit in my winedev2 wine branch (commit 0922d3d66976f7185ea81b797fa1081e097e71f8 ). Note this does include the sources generated from parser.y and parser.l as the mingw build system does not include widl's yacc and bison step and just has their outputs checked into the mingw source tree.

The second applies the mingw 0001-relocatable.patch which adds extra logic for finding mingw's header directories .

tor-browser-build
: https://gitweb.torproject.org/user/richard/tor-browser-build.git/commit/?h=bug_27503

This change adds a patch step to the mingw-w64 project. The included 27503.patch can be generated from the above mingw-w64 branch via git diff bug_27503~2


I believe that covers everything. I'm doing a few test nightly builds with the latest tor-browser-build patch set to verify things still work.

comment:93 in reply to:  92 Changed 7 weeks ago by gk

Replying to pospeselr:

Ok here's everything you should need to review gk:

wine: https://github.com/pospeselr/wine/commits/winedev2

This wine branch is my review dev branch as of yesterday. I have one more piece of feedback to work on (commit 8baf184001c6bcdc3ec1867c6bb6fa82b5ffed15 ) before it's again submitted for review. I'm be switching over to a new winedev3 branch to make sure everything stays lined up on our end.

mingw-w64: https://github.com/pospeselr/mingw-w64/commits/bug_27503

This branch has two commits on top of commit 2d4e517ad0c7a9f0bd7001c42e6c131b977c15d9 used in tor-browser-build.

The first is a copy of widl's .c, .h, .l and .y files from the last commit in my winedev2 wine branch (commit 0922d3d66976f7185ea81b797fa1081e097e71f8 ). Note this does include the sources generated from parser.y and parser.l as the mingw build system does not include widl's yacc and bison step and just has their outputs checked into the mingw source tree.

I see. What do I need to do to follow this step? In other words: how can I be sure that the thing we are about to commit to tor-browser-build does indeed match the stuff that is on winedev2?

comment:94 Changed 7 weeks ago by gk

Okay, here is the status so far. I double-checked all the widl sources files and it seems only some debugging leftovers slipped into the tor-browser-build patch (not sure how, though):

parser.y

+      	printf("dup_pointer_type!\n");
+      	printf("type : %p name : %s\n", *pt, (*pt)->name);
+      	/* ptr_attr is ref,unique or full (FC_RP, FC_UP, FC_FP) */
+      	/* *pt could be the var's declspec's type OR a type on a typedef */
+      	/* not an array */
+  printf("reg_type { name : %s, namespace : %s, type : %s, ptr : %p}\n", name, namespace->name, ts_to_str(t), type);

(twice)

+          error_loc("FOO %s: redefinition error; original definition was at %s:%d\n",
+  const var_t *v;

typetree.c

+        error_loc("BAZ %s: redefinition error; original definition was at %s:%d\n",
+        error_loc("BING %s: redefinition error; original definition was at %s:%d\n",

widltypes.h

+static inline const char* ts_to_str(int t)
+{
+  static const char* strings[] = {"tsNULL", "tsENUM", "tsSTRUCT", "tsUNION"};
+  return strings[t];
+}
+

Where is 0001-relocatable.patch is coming from? Is that a custom patch you needed to write?

comment:95 Changed 7 weeks ago by gk

I still need to figure out what to do with the parser.tab.c, parser.tab.h, and parser.yy.c diff.

comment:96 Changed 7 weeks ago by gk

Okay, I merged this to master to give it a chance to appear in the alpha build as commit b9696546f5416c79449a2f20044ae3ec9ee36e1b. The patch still needs to have at least some clean-up, though (see previous comment).

comment:97 in reply to:  94 ; Changed 6 weeks ago by pospeselr

Replying to gk:

Okay, here is the status so far. I double-checked all the widl sources files and it seems only some debugging leftovers slipped into the tor-browser-build patch (not sure how, though):

Yeah sorry, I generated the patch from my working winedev3 branch rather than winedev2. I've committed a FIXUP patch to my tor-browser-build branch with the correct patch :

https://gitweb.torproject.org/user/richard/tor-browser-build.git/commit/?h=bug_27503&id=ce6bc2621c79c3a66cff6f91c0ac38854190e1b0

And I've rebased my mingw-w64 tree with the correct winedev2 sources:

https://github.com/pospeselr/mingw-w64/tree/bug_27503

Where is 0001-relocatable.patch is coming from? Is that a custom patch you needed to write?

0001-reloctable.patch lives in /mingw-w64/mingw-w64-tools/widl/patches/ . It is not applied at build time during the mingw build process, but is instead applied to the widl sources when the latest version is ported over, with the resulting patched sources committed to the mingw tree.

I still need to figure out what to do with the parser.tab.c, parser.tab.h, and parser.yy.c diff.

Those are generated when building widl within wine.

Last edited 6 weeks ago by pospeselr (previous) (diff)

comment:98 in reply to:  97 Changed 6 weeks ago by gk

Replying to pospeselr:

Replying to gk:

Okay, here is the status so far. I double-checked all the widl sources files and it seems only some debugging leftovers slipped into the tor-browser-build patch (not sure how, though):

Yeah sorry, I generated the patch from my working winedev3 branch rather than winedev2. I've committed a FIXUP patch to my tor-browser-build branch with the correct patch :

https://gitweb.torproject.org/user/richard/tor-browser-build.git/commit/?h=bug_27503&id=ce6bc2621c79c3a66cff6f91c0ac38854190e1b0

Looks good to me. I've cherry-picked the patch onto master (commit 054c4d0f2502698f0803db7574bc0e229a66dfec).

comment:99 Changed 6 weeks ago by gk

Keywords: tbb-backport added
Resolution: fixed
Status: needs_reviewclosed

Okay, the bison stuff looks good, too. Let's close this and mark it as a possible backport as this might be important enough to get to stable users before 9.0. \o/

Note: See TracTickets for help on using tickets.