Opened 4 months ago

Closed 13 days ago

Last modified 11 days ago

#27290 closed defect (fixed)

WebGL is broken in Tor Browser 8

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr, tbb-8.0-issues, tbb-regression, TorBrowserTeam201812R, tbb-backport
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Going to a demo e.g. http://webglsamples.org/aquarium/aquarium.html shows that WebGL is broken in Tor Browser. The first error is:

Error: WebGL warning: Unable to restrict WebGL limits to minimums.

The respective script breaks in the last line of

/**
 * Creates a webgl context.
 * @param {!Canvas} canvas The canvas tag to get context
 *     from. If one is not passed in one will be created.
 * @return {!WebGLRenderingContext} The created context.
 */
tdl.webgl.create3DContext = function(canvas, opt_attribs, opt_preferredContextType) {
  if (opt_attribs === undefined) {
    opt_attribs = {alpha:false};
    tdl.misc.applyUrlSettings(opt_attribs, 'webgl');
  }
  var names = ["webgl", "experimental-webgl"];
  if (opt_preferredContextType) {
    names.splice(0, 0, opt_preferredContextType);
  }
  var context = null;
  for (var ii = 0; ii < names.length; ++ii) {
    try {
      context = canvas.getContext(names[ii], opt_attribs);

.

Now, this works in Tor Browser if one toggles privacy.resistFingerprinting to false. The interesting part, however, is that this works in vanilla Firefox 60.1.0esr with privacy.resistFingerprinting enabled out of the box.

I wonder what else we do that is tied to that pref and breaks WebGL.

This got first noticed on our blog (https://blog.torproject.org/comment/276529#comment-276529).

Child Tickets

Change History (16)

comment:1 Changed 4 months ago by gk

This is as well easily visible on about:support, see: #26649. Marking that ticket as a dupliate.

comment:2 Changed 4 months ago by gk

The suggestion was that ANGLE is broken (at least according to the original bug report in our blog: ​https://blog.torproject.org/comment/275959#comment-275959).

comment:3 Changed 4 months ago by tom

I don't think this is the issue, but if nothing else is leading to it, it might be worth throwing in a

if(!mD3DCompilerModule)
  __builtin_trap();

(per https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking/DebuggingOnWindows#Breakingwherewewanttobreak)

at
https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/gfx/angle/checkout/src/libANGLE/renderer/d3d/HLSLCompiler.cpp#139
and
https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/gfx/gl/GLLibraryEGL.cpp#417

just to be certain out d3dcompiler dll is getting loaded... I had seen intermittent test failures (on a mingw build) where it wasn't but never could figure out why.

comment:4 Changed 4 months ago by gk

Yeah, the problem is more generic. It happens on Linux, too.

comment:5 Changed 3 months ago by arthuredelstein

Keywords: TorBrowserTeam201809R added
Status: newneeds_review

Here's a patch for review:

https://github.com/arthuredelstein/tor-browser/commit/27290

I confirmed this fixed the problem by toggling the pref and running http://webglsamples.org/aquarium/aquarium.html

comment:6 Changed 3 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201809R removed
Status: needs_reviewneeds_revision

Surprisingly, this does not fix the issue for me. First of all, flipping that pref alone is not enough. We seem to set that pref in Torbutton as well (https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutton.js#n1517) and it is clobbering the value again. But even with that fixed I can't get the demos on http://webglsamples.org/aquarium/aquarium.html to run.

Here is what I did on my Linux box:
1) Extract a new 8.5a1
2) Patch the omni.ja file in Browser/browser according to your patch
3) Patch Torbutton and copy it over to the extracted browser
4) Start 8.5a1 for the first time
5) Check that the value in about:config is okay (it was)
6) Go to http://webglsamples.org/aquarium/aquarium.html

One nit: s/was use for this purpose/was used for this purpose/

comment:7 in reply to:  6 Changed 3 months ago by arthuredelstein

Replying to gk:

Surprisingly, this does not fix the issue for me. First of all, flipping that pref alone is not enough. We seem to set that pref in Torbutton as well (https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutton.js#n1517) and it is clobbering the value again.

I had missed this usage. We should remove that line as well. I will post a patch when I have a full solution.

But even with that fixed I can't get the demos on http://webglsamples.org/aquarium/aquarium.html to run.

Well, this is interesting. It turns out disabling the pref fixes the problem in 8.0 (stable) but doesn't fix it in 8.5a1. Still investigating.

comment:8 Changed 3 months ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201809 removed

Moving tickets to October

comment:9 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:10 Changed 13 days ago by gk

Cc: mcs brade added
Keywords: tbb-8.0-issues tbb-regression TorBrowserTeam201812R added; TorBrowserTeam201811 removed
Status: needs_revisionneeds_review

Okay, this almost dropped off the radar. It turns out that I can't reproduce the issue with 8.5a1 anymore, which is kind of weird. The only explanation I have is that I used the new NoScript API in Torbutton back then but the NoScript 8.5a1 shipped was not ready for that one (a mistake that happened to me just a couple of minutes ago while re-investigating). The result is a broken NoScript denying JS by default preventing the WebGL demo from running.

At any rate, I picked up Arthur's patch and pushed a branch for tor-browser (bug_27290 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_27290&id=6eadc8186a20298ed6d0469f64586d63bec1cfd1)) and fixed the Torbutton issue in bug_27290_v2 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_27290_v2&id=7d98f3bd4348aa79efe040118763c77c84745173).

comment:11 Changed 13 days ago by mcs

r=mcs
Both patches look good to me. I also verified that setting webgl.min_capability_mode to false allows WebGL to begin working within macOS Tor Browser (I tested with 8.0.3 and 8.5a5).

comment:12 in reply to:  10 ; Changed 13 days ago by omg

Obviously,

 pref("webgl.disable-fail-if-major-performance-caveat", true);
 pref("webgl.enable-webgl2", false);

should be added to Torbutton.
#16473 is left behind the Android release.

comment:13 in reply to:  11 ; Changed 13 days ago by gk

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

Replying to mcs:

r=mcs
Both patches look good to me. I also verified that setting webgl.min_capability_mode to false allows WebGL to begin working within macOS Tor Browser (I tested with 8.0.3 and 8.5a5).

Thanks. Merged to Torbutton's master (commit 7d98f3bd4348aa79efe040118763c77c84745173) and to tor-browser-60.3.0esr-8.5-1 (6eadc8186a20298ed6d0469f64586d63bec1cfd1). Marking for possible backport.

comment:14 in reply to:  12 Changed 13 days ago by gk

Replying to omg:

Obviously,

 pref("webgl.disable-fail-if-major-performance-caveat", true);
 pref("webgl.enable-webgl2", false);

should be added to Torbutton.

I agree with the situation being not optimal but I think those prefs should not get added to Torbutton. Rather, we should rip out the respective Torbutton functions (both torbutton_update_fingerprinting_prefs() and torbutton_update_isolation_prefs()) as fingerprinting and linkability defenses are not optional. We don't expose those options in the browser UI either anymore. I've opened #28746 for that (and #28745 for the parent ticket covering the Torbutton clean-up).

comment:15 Changed 12 days ago by omg

You recommended to flip resist fingerprinting preference for testing purposes some time ago. But if you don't need that anymore, then sure.

comment:16 in reply to:  13 Changed 11 days ago by gk

Replying to gk:

Replying to mcs:

r=mcs
Both patches look good to me. I also verified that setting webgl.min_capability_mode to false allows WebGL to begin working within macOS Tor Browser (I tested with 8.0.3 and 8.5a5).

Thanks. Merged to Torbutton's master (commit 7d98f3bd4348aa79efe040118763c77c84745173) and to tor-browser-60.3.0esr-8.5-1 (6eadc8186a20298ed6d0469f64586d63bec1cfd1). Marking for possible backport.

Note for backporting: I think we should fix #21805 first, too, or amend our browser design doc which claims we are providing WebGL by click-to-play (which we currently do not do).

Note: See TracTickets for help on using tickets.