Opened 8 months ago

Last modified 9 days ago

#27503 assigned defect

Disabling accessibility on Windows breaks screen readers

Reported by: gk Owned by: pospeselr
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-8.0-issues, tbb-regression, GeorgKoppen201903, tbb-8.5-must, TorBrowserTeam201904
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 3 months ago.
TOR Debug.txt (14.6 KB) - added by OnionRing 3 months ago.
TOR debug file
debuglog.txt (16.6 KB) - added by onionsoup 3 months ago.

Download all attachments as: .zip

Change History (63)

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

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

Cc: Rastislav Kiss added

#27862 is a duplicate.

comment:7 Changed 7 months ago by boklm

Cc: "Rastislav Kiss" added; Rastislav Kiss removed

comment:8 Changed 7 months ago by boklm

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

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

Cc: onionsoup added

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

Keywords: GeorgKoppen201812 added; GeorgKoppen201811 removed

Moving my tickets to December.

comment:16 Changed 4 months ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

comment:17 Changed 4 months ago by gk

Status: assignedneeds_information

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

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

?

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

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

comment:18 Changed 4 months ago by onionsoup

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

comment:19 in reply to:  18 Changed 4 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 4 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 4 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 4 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 3 months ago by gk

Keywords: GeorgKoppen201901 added; GeorgKoppen201812 removed

Moving my tickets.

comment:24 Changed 3 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

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

Reviewer: boklm

comment:31 Changed 3 months ago by cypherpunks33

:) #26148?

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

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201901R removed

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

Attachment: tor_accessibility.log added

Changed 3 months ago by OnionRing

Attachment: TOR Debug.txt added

TOR debug file

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

Attachment: debuglog.txt added

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

Keywords: GeorgKoppen201902 added; GeorgKoppen201901 removed

Moving my tickets to Feb

comment:41 Changed 2 months ago by gk

Thanks for the logs, that was helpful.

comment:42 Changed 2 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:43 Changed 6 weeks ago by chpross

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

comment:44 Changed 6 weeks ago by chpross

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

comment:45 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving my tickets to March.

comment:46 Changed 6 weeks ago by gk

Keywords: GeorgKoppen201903 added; GeorgKoppen201902 removed

Now for my keyword.

comment:47 Changed 6 weeks ago by gk

Keywords: tbb-8.5 added

Tickets on our radar for 8.5

comment:48 Changed 6 weeks ago by pospeselr

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

comment:49 Changed 4 weeks ago by gk

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

Marking blockers for Tor Browser 8.5.

comment:50 Changed 3 weeks ago by PZajda

Cc: patrick@… added

comment:51 Changed 3 weeks 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 3 weeks ago by pospeselr (previous) (diff)

comment:52 in reply to:  51 ; Changed 2 weeks 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 2 weeks 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 2 weeks 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 2 weeks 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 2 weeks ago by pospeselr (previous) (diff)

comment:56 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201904 added; TorBrowserTeam201903 removed

Moving tickets to April.

comment:57 Changed 2 weeks 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 2 weeks 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 9 days ago by gk (previous) (diff)

comment:59 in reply to:  58 Changed 9 days 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.

Note: See TracTickets for help on using tickets.