note that it works on desktop and any other phone brand we have

Got user Report for same bug on "Galaxy S7 Edge" 

Got user Report for same bug on "Samsung Note 5" 

Need to try to reproduce in house and gather a crash report. cblume@, could you possibly help with that?

Given that this used to work, it might be a newly introduced bug in the shader translator.

The about:gpu page says "[ERROR:gpu_watchdog_thread.cc(362)] : The GPU process hung. Terminating after 10000ms", so the GPU crash is from watch dog.

Good catch Mo. The shaders might be using some construct which causes the driver's GLSL compiler to take a pathologically long time. Submitter, I suggest you iteratively trim down your shaders until you find the problematic construct.

As said above, I tried already to trim shaders to  s simple repro case.
On shadertoy and shdr.bkcore to reproduce without success.

Scene posted above use basic shaders compared with what sketchfab shaders can be.
Would it be possible to be a combination between shader and gl state (uniform,attributes) that makes "hung" the gpu ?

As it's very hard to debug webgl on phone, if you could you give any more infos on when/where/what gl call/shader/geometry is the culprit, that would be a tremendous help here to try trimming further ?

Still no luck, with shaders nearly trimmed down to nothing, which makes me wonder about"shaders" only being the cause

Notes: 
- doing everything but "gl.drawElements" doesn't throw context lost. so shaders & program does compile & link, it's at "drawing" that we get those "GPU hung" causing webglcontext lost

Do you still have a system that can run without context lost?  If yes, you can use the WEBGL_debug_shaders extension to grab what's the translated shader sent to the driver without context lost and what's the one with context lost.  If there are any differences, then we have a clear idea what Chrome did and what the bug is (likely a driver bug)

no system without context lost.

further inquiriedon shader showed that replacing texture2d call with some functions returning ran values prevent context loss.

Seems more like a framebuffer/texture r/w from shader thing then

Note that it seems that it's not happening on phone that didn't do the "July samsung update".
Reportedly a phone with "June Samsung update" works

WebGL conformance test,; seems this crash regularly on Samsung phones with the bug: 
https://www.khronos.org/registry/webgl/sdk/tests/conformance/glsl/bugs/undefined-index-should-not-crash.html?webglVersion=1&quiet=0

I've contacted ARM since this phone contains a Mali GPU, asking for help investigating this problem.

I've also contacted Samsung asking for help investigating.

Thank you for providing more feedback. Adding requester "kbr@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Samsung has indicated they're investigating the problem. I'm marking this ExternalDependency for now.

Seems our latest website update make our codebase abvoid the bug, so the URL in the bug report may not reproduce the bug anymore.

Still have that WebGL conformance test that  crash regularly on Samsung phones with the bug: https://www.khronos.org/registry/webgl/sdk/tests/conformance/glsl/bugs/undefined-index-should-not-crash.html?webglVersion=1&quiet=0

Made a new URL server to repro the crash  on samsung S6 phone with latest update

https://thor.fatvertex.com/models/c7d7a68e73964960b63a358bfcd820f0/embed?autostart=1&postprocess=0

Was there any fix reported by Samsung? I have a 3d project in THREE.js and webgl is crashing after I updated my Samsung S6 edge (after factory reset). The scene lasts for 5 seconds before crashing.Used to work before , the same case as above. Its working on desktops and other phones.

No update yet on this topic from Samsung but I've just asked for one.

Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]

It's not a phone, but ARM Mali has copy problems with Figma on a:

  1. Samsung XE303C12 - ChromeOS Arm 32-bit w/Mali 
  2. Samsung XE513C24 - ChromeOS Dual ARM® Cortex®-A72, Quad Cortex-A53 big.LITTLE™ configuration - no info on GPU

Run figma.com on these machines.  Create a rectangle, and pan around the scene.  Copies of the data will appear in places that there shouldn't be.  This doesn't occur on other ChromeOS devices.  This is either a WebGL or driver bug with WebGL on these machines.  We only use gl.copyTexSubImage2D for all copies (full and partial copies). 

+marcheu because of report on Chrome OS

Alec, we really need a reduced test case in order to make progress on these reports. Please invest the time to create one.

@29: can you please file a separate bug? it seems like this is a different issue. If you do, please add me (marcheu@chromium.org) as the owner. Thanks!