Visiting the following site shows that WebGL is unavailable. http://webglreport.com/?v=1 The console says: Error: WebGL warning: Failed to create WebGL context: WebGL creation failed: * Error during native OpenGL init. * GL error 0x500 occurred during WebGL context initialization! * Exhausted GL driver options. I suspect this was regressed by a Mesa update and not Nightly, though I have not tried bisecting yet. I'm using Fedora 26 on Wayland (firefox in XWayland).

This is printed to stderr: libGL error: MESA-LOADER: failed to retrieve device information ATTENTION: default value of option force_s3tc_enable overridden by environment. libGL error: Version 4 or later of flush extension not found libGL error: failed to load driver: i915 libGL error: MESA-LOADER: failed to retrieve device information It might be caused by sandboxing.

With security.sandbox.content.level = 1 it works, but with 2 it doesn't.

Note that there is one special case, the vmwgfx module when built standalone and not part of the kernel tree, which then uses a dynamic number. For this I don't know if it'd be better to make a more complex rule (that involves parsing /dev/dri/*) or to patch libdrm to not fail when reading these paths.

Comment on attachment 8890631 [details] [diff] [review] 0001-Bug-1384718-Add-sandbox-rules-for-Mesa-17.1-driver-l.patch Review of attachment 8890631 [details] [diff] [review]: ----------------------------------------------------------------- ::: security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp @@ +149,5 @@ > // Bug 1312678: radeonsi/Intel with DRI when using WebGL > policy->AddDir(rdwr, "/dev/dri"); > > + // Bug 1384178: mesa driver loader > + policy->AddPrefix(rdonly, "/sys/dev/char/226:"); There's a separate block "Read permissions" below, please move this there.

(In reply to Thomas Daede [:TD-Linux] from comment #8) > Created attachment 8891113 [details] [diff] [review] > 0001-Bug-1365789-Fix-typo-in-urlbar-background-color-for-.patch This looks like it was meant for a different bug?

I ran into this bug while working on bug 1383888 (Mesa uses libudev and readlinkat(AT_FDCWD, ...)s the /sys/dev/char/226:* links), so I tried applying the patch from this bug, which made Mesa complain less, but there's still some "MESA-LOADER: could not get parent device". gcp, you might want to look at this; there's… something going on with symlink reversal and .. normalization that seems to be not quite working like we expected it to.

Whoops sorry, grabbed the wrong patch.

Comment on attachment 8891130 [details] [diff] [review] 0001-Bug-1384718-Add-sandbox-rules-for-Mesa-17.1-driver-l.patch carried forward

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #10) > gcp, you might want to look at this; there's… something going on with > symlink reversal and .. normalization that seems to be not quite working > like we expected it to. /sys/devices/pci0000:00/0000:00:0f.0/drm/card0 -> /sys/dev/char/226:0 I think what's happening is that the driver is trying to .. around in /sys/devices (which we don't allow). This is blocked, but after we see the block, we try symlink reversal to see if that ends up somewhere that we do allow, and that works *only* for the above file, which is the one actually white-listed, but not for anything else. We might need to detect during policy formation what PCI device the GPU is and apply the whitelist to that in /sys/devices instead of /sys/dev/char/226:0.

Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/00167e9fe0c0 Add sandbox rules for Mesa 17.1 driver loader. r=gcp