Closed Bug 1417291 Opened 4 years ago Closed 1 year ago

WebGL content not working after update from Firefox 56 to Firefox 57+

Categories

(Core :: Canvas: WebGL, defect, P3)

57 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1623885

People

(Reporter: elkosmas, Unassigned, NeedInfo)

References

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [gfx-noted])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

Updated Firefox 56 (stable) to 57 (stable) on a Debian Stable machine (not via a .deb but by download a Firefox for Linux binary from Mozilla)
Visited https://get.webgl.org/

about:support output https://pastebin.com/Z4ZaywUy




Actual results:

Got an error "Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card."
Followed suggested solutions at SUMO https://support.mozilla.org/en-US/kb/upgrade-graphics-drivers-use-hardware-acceleration?redirectlocale=en-US&redirectslug=how-do-i-upgrade-my-graphics-drivers to no avail.

Tested on FIrefox 59 (Nightly) issue persists.
Tested on Firefox 52.4.0 (ESR) WebGL content renders seemingly properly


Expected results:

WebGL content should be rendered properly.
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
Could you upload the "about:support" page info?
Flags: needinfo?(elkosmas)
Whiteboard: [gfx-noted]
Would the pastebin link I provided on the original suffice?

If not I'm going to do so later today (UTC time)
Flags: needinfo?(elkosmas)
Could you help me take a look at "privacy.resistFingerprinting" at about:config if it is false?

It should be false.
Flags: needinfo?(elkosmas)
privacy.resistFingerprinting is 'false'
Flags: needinfo?(elkosmas)
It could be the sandbox issue at Bug 1416016.

Could you help me try to set "security.sandbox.content.level to 0"?
Flags: needinfo?(elkosmas)
Daosheng Mu interestingly this worked just fine!

Thanks a lot.

If there is anyway I can help or provide more info don't hesitate to say so!
See Also: → 1416016
Daosheng, could you please run firefox with the environment variable MOZ_SANDBOX_LOGGING=1, try again your problem, and output the console ? (of course with the sandbox back to normal :) ).

This is very likely the same bug as my bug 1416016 (Debian Stable as well here), but it would be interesting to see if you have different paths needed.

For me in that bug, whitelisting these files worked:

/sys/class/drm/card0/device/config
/sys/class/drm/renderD128/device/config
/sys/class/drm/controlD64/device/config

You can whitelist them by adding them to the pref security.sandbox.content.read_path_whitelist, separated by comma:
/sys/class/drm/card0/device/config, /sys/class/drm/renderD128/device/config, /sys/class/drm/controlD64/device/config

This is way better than disabling the sandbox :)
(In reply to Julien Wajsberg [:julienw] from comment #7)
> Daosheng, could you please run firefox with the environment variable
> MOZ_SANDBOX_LOGGING=1, try again your problem, and output the console ? (of
> course with the sandbox back to normal :) ).
> 
> This is very likely the same bug as my bug 1416016 (Debian Stable as well
> here), but it would be interesting to see if you have different paths needed.
> 
> For me in that bug, whitelisting these files worked:
> 
> /sys/class/drm/card0/device/config
> /sys/class/drm/renderD128/device/config
> /sys/class/drm/controlD64/device/config
> 
> You can whitelist them by adding them to the pref
> security.sandbox.content.read_path_whitelist, separated by comma:
> /sys/class/drm/card0/device/config, /sys/class/drm/renderD128/device/config,
> /sys/class/drm/controlD64/device/config
> 
> This is way better than disabling the sandbox :)

I think you are asking to Eleftherios? Eleftherios, please help us try it by following Comment 7. Hugely appreciate.
Hello, I have the same issue as Eleftherios Kosmas. Firefox 57 doesn't render WebGl on any page with a WebGl animation on a Debian Stretch system. Firefox ESR works.

I tried the solution "security.sandbox.content.level to 0" and it works ok. WebGL is rendered. 
Also, I tried the solution proposed by Julien Wajsberg and it didn't work. However, I am not 100% sure I did it right.

What I did was, add the following string "/sys/class/drm/card0/device/config,/sys/class/drm/renderD128/device/config,/sys/class/drm/controlD64/device/config" to security.sandbox.content.read_path_whitelist.
Set back security.sandbox.content.level to the level it was before 3.
Then, I run in shell:

$export MOZ_SANDBOX_LOGGING=1
$.local/firefox/firefox 

WebGL still doesn't work. On Firefox Devtools console I see:

Error: WebGL warning: Failed to create WebGL context: WebGL creation failed: 
* Error during native OpenGL init.
* Error during native OpenGL init.
* Error during native OpenGL init.
* Error during native OpenGL init.
* Error during native OpenGL init.
* Exhausted GL driver caps.
* Exhausted GL driver options.

I don't have a clue what these keys do. Is there an issue to set security.sandbox.content.level to 0?
I think I have the same problem as the OP on Firefox 61 on Debian. Disabling the sandbox fixes the issue, but adding to the whitelist does not. I am concerned about the security implications of completely disabling the sandbox.
Can confirm that setting security.sandbox.content.level to 0 "fixes" the issue for me on Arch Linux with Firefox version 61.0.2
Works for me again in Firefox 62.0.

Same problem on firefox 66.0.2.

Same in firefox 67

Hi,

WebGL stops working after update to 68.0.1 (64 bit) as well. Here's the about:support info for Graphics clipped for brevity - I think the last three lines are key:

Graphics
Features
Compositing Basic

[SNIP]

HW_COMPOSITING
blocked by env: Acceleration blocked by platform
OPENGL_COMPOSITING
unavailable by default: Hardware compositing is disabled
WEBRENDER
opt-in by default: WebRender is an opt-in feature
WEBRENDER_QUALIFIED
blacklisted by env: No qualified hardware

Updating my graphics driver fixed the problem.

Julian

I had the same issue and for me I had to whitelist this file /sys/devices/pci0000:00/0000:00:02.0/subsystem

See Also: → 1623885
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1623885
You need to log in before you can comment on or make changes to this bug.