Plotly.js: »Webgl is not supported by your browser« in Brave, although it is supported

Created on 15 Mar 2019  ·  14Comments  ·  Source: plotly/plotly.js

Opening https://plot.ly/javascript/3d-scatter-plots/ in the Brave browser (https://brave.com, it's based on Chromium) yields »Webgl is not supported by your browser - visit http://get.webgl.org for more info«. Going to http://get.webgl.org in Brave, however, says »Your browser supports WebGL« and successfully displays an animation.

It would be nice if plotly WebGL plots would work in Brave.

bug

All 14 comments

It is working by disabling Brave Shields.
Brave

I see. Can confirm that allowing »All Device Recognition« it can be viewed. However, I think this shouldn't be the default state. Do I understand it correctly that Plotly tries to identify the browser and if it can't, it won't attempt to display WebGL? Or do you think this is an issue with Brave wrongly classifying something Plotly does?

Thanks @Xjs for testing that out. And glad that it worked.

Regarding your first question:

Do I understand it correctly that Plotly tries to identify the browser and if it can't, it won't attempt to display WebGL?

No that is not the case.

And in respect to the second question:

Or do you think this is an issue with Brave wrongly classifying something Plotly does?

It may be the case. I'll leave it to my colleague @etpinard who is super knowledgeable about browsers as well as Plotly.js.

I have the same problem with Firefox 65 on Fedora 29

Is this still a problem @Xjs ?

With »device recognition blocked« this is still a problem. I'm running Brave Dev Version 0.66.71 Chromium: 75.0.3770.38 (Official Build) dev (64-bit).

Still a problem with FF 67 on fedora 29. The interesting part is that https://get.webgl.org/ renders fine, but when using plotly i get this message in browser console:
Error: WebGL warning: checkFramebufferStatus: Framebuffer not complete. (status: 0x8cd6) Bad status according to the driver: 0x8cd6 plotly-latest.min.js:7:571000

When using the latest in a non-monified i get
Error: WebGL warning: checkFramebufferStatus: Framebuffer not complete. (status: 0x8cd6) Bad status according to the driver: 0x8cd6 plotly-latest.js:41647:19

Line 41647 is
var status = gl.checkFramebufferStatus(gl.FRAMEBUFFER)

status is 36054 which means GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

Same deal here, but FF 69 on Arch. I'm using Wayland, so I'm not sure if that could be relevant to anything. Also getting Framebuffer not complete in the console. (https://get.webgl.org works fine)

I see this on Chrome on Ubuntu. https://get.webgl.org/ works for me.

Plotly WebGL used to work too, by the way. So this is a regression. I just don't know _whose_ regression it is...

Chrome Version 77.0.3865.75 (Official Build) (64-bit)
uname -a: Linux [my machine's name] 4.15.0-1050-oem #57-Ubuntu SMP Wed Aug 7 10:34:10 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
I'm in an Xorg session, not Wayland.

With today's update of Google Chrome for Android devices v77.0.3865.62 and Android System WebView v74.0.3729.136 stopped the support for WebGL on their in-app browsering of Plot.ly charts. It says WebGL is not supported by your browser - visit get.webgl.org for more --> All project seem gone :(

Thank you @tvst @bayyolal for these reports.

I haven't been able to reproduce the problems on Chrome 77 on Windows 10 (via browserstack) and I haven't been able to get my hands on a Linux or an Android device that runs Chrome 77 yet.

cc @plotly/plotly_js

Hi with good news! With Autumn from Stack Overflow's help, we can still develop Plot.ly on Android webView with "Chrome Beta" browser as I downloaded from Google Play and removed Chrome's default app to install Chrome Beta, now I can see my graph in my app. This is a partial fix, but users gonna see WebGL is not supported warnings unfortunately. If Chrome Beta leads the way for next updates for Chrome, maybe on next updates everything will be alright, but Chrome made me sad about WebGL support. Check more: https://stackoverflow.com/a/15418752/2759236

By binary-searching through several versions from 1.21.1 to 1.51.3, it appears that this occurred first in version 1.42.0.
I don't see this issue in versions up to and including 1.41.3 .

Fixed via #4549.

Was this page helpful?
0 / 5 - 0 ratings