Opened 8 weeks ago

Last modified 12 days ago

#27290 needs_revision defect

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, TorBrowserTeam201810
Cc: 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 (8)

comment:1 Changed 7 weeks ago by gk

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

comment:2 Changed 7 weeks 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 7 weeks 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 7 weeks ago by gk

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

comment:5 Changed 5 weeks 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 5 weeks 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 5 weeks 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 12 days ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201809 removed

Moving tickets to October

Note: See TracTickets for help on using tickets.