New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 704708 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
OOO until 2019-01-24
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Unable to prevent "Rats, WebGL hit a Snag? popup with the webglcontextlost event handling

Reported by mbola...@desertdevco.com, Mar 23 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36

Steps to reproduce the problem:
We are looking for a way to properly handling the webgl context lost error so we can recover from it accordingly.

So far we have attached to the webglcontextlost and webglcontextrestored events and added some sort of the suggested steps for handing this kind of problem (https://www.khronos.org/webgl/wiki/HandlingContextLost) 

Here an extract of the code:
this.canvas.addEventListener("webglcontextlost", (function(ev) {
    ev.preventDefault();
    console.log('webglcontextlost for: ' + this.name);
  }).bind(this));

  this.canvas.addEventListener("webglcontextrestored", (function(ev) {
    ev.preventDefault();
    console.log('webglcontextrestored for: ' + this.name);
    this._webGLContext = null;
    this._initializeWebGL();
  }).bind(this));

We used the gl.getExtension("WEBGL_lose_context") to simulate the context lost and context restore events and the above code is working as expected.

However when the real error occurs the Rats, WebGL hit a Snag? Ignore, Reload popup is still being displayed and the webglcontextrestored event is never triggered.

What is the expected behavior?
The "Rats, WebGL hit a Snag? Ignore, Reload" popup should not being displayed and the webglcontextrestored event should be triggered

What went wrong?
There is no way to manually recover from the webgl context lost error

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 57.0.2987.110  Channel: stable
OS Version: 10.0
Flash Version:
 

Comment 1 by phistuck@gmail.com, Mar 23 2017

> Does this work in other browsers? Yes
Do other browsers generally show a message when a fatal WebGL issue such as context loss occurs?
If so, does this code prevent it in other browsers (which?)?

Comment 2 by kbr@chromium.org, Mar 23 2017

Owner: kbr@chromium.org
Status: WontFix (was: Unconfirmed)
You're testing your code correctly with the WEBGL_lose_context extension. Unfortunately, there are some situations where the browser can not detect whether it is safe to allow the JavaScript code to recover the context, or whether doing so would enable a denial-of-service attack. You're running into one of these situations.

If you have a specific scenario where you think the browser could or should detect that it's safe to recover, please provide it; but this is otherwise working as intended.

Comment 3 by kbr@chromium.org, Mar 23 2017

Blocking: 630728
Cc: sugoi@chromium.org capn@chromium.org
I'll note that we could plausibly fall back to software rendering via SwiftShader once that's deployed everywhere in  Issue 630728 . Linking these bugs but not blocking this on the other since this one's being closed.

What we are running is a slot machine game, we have multiple instance of such game (4), the game is set to auto-play, we believe it is not leaking memory since the lost context is occurring even if the gpu memory usage is stable (going up and down as texture are added/removed from gpu), it is more usually happening if the focus is located in another tab while the slot machines are constantly spinning.

So, we don't think we are running into a situation where recovering from such error could be considered unsafe.


You should be able to see some info on the cause of the lost context. Check the log at the bottom of chrome://gpu before and after a crash. If it turns out to be a safe context loss we can look into why it isn't recovering.

Comment 6 by kbr@chromium.org, Mar 23 2017

Labels: Needs-Feedback
Status: Unconfirmed (was: WontFix)
Please provide us a test case as well as about:gpu from your machine. Moving this back to the Unconfirmed state.

This is the delta in the chrome://gpu log after the crash:

[32576:23908:0323/171816.372:ERROR:interface_registry.cc(203)] : Failed to locate a binder for interface: chrome::mojom::ResourceUsageReporter requested by: exposed by: via InterfaceProviderSpec "service_manager:connector".
[32576:23908:0323/171816.372:WARNING:interface_registry.cc(210)] : InterfaceRegistry(service_manager:connector): --> InterfaceRegistry is not yet bound to a pipe.
[32576:23908:0323/173204.388:ERROR:gles2_cmd_decoder.cc(4209)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[32576:23908:0323/173204.388:ERROR:gpu_channel_manager.cc(228)] : Exiting GPU process because some drivers cannot recover from problems.
[32576:23908:0323/173204.389:ERROR:gpu_channel_manager.cc(228)] : Exiting GPU process because some drivers cannot recover from problems.
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
[21568:20472:0323/173205.432:ERROR:interface_registry.cc(203)] : Failed to locate a binder for interface: chrome::mojom::ResourceUsageReporter requested by: exposed by: via InterfaceProviderSpec "service_manager:connector".
[21568:20472:0323/173205.432:WARNING:interface_registry.cc(210)] : InterfaceRegistry(service_manager:connector): --> InterfaceRegistry is not yet bound to a pipe.
[33136:30048:0323/173303.179:ERROR:interface_registry.cc(203)] : Failed to locate a binder for interface: chrome::mojom::ResourceUsageReporter requested by: exposed by: via InterfaceProviderSpec "service_manager:connector".
[33136:30048:0323/173303.179:WARNING:interface_registry.cc(210)] : InterfaceRegistry(service_manager:connector): --> InterfaceRegistry is not yet bound to a pipe.
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.


Complete About:gpu is attached.


In regards of the test case, not sure exactly what you need. The application is not public since it is still under development, so it cannot be reach from the outside of my company. Could you please elaborate a little more here?


about_gpu.txt
14.1 KB View Download
Project Member

Comment 8 by sheriffbot@chromium.org, Mar 23 2017

Cc: kbr@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Interesting. I wonder if this is a reproducible case of  Issue 689350 . If so, we might be able to finally track it down.
Wait, never mind, probably not. That symptom is different (Context lost because SwapBuffers failed).
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
Please provide us the sample HTML test case for further triage from TE side.

Thank You...
So is the GPU log I sent confirming that we are actually hitting a situation where the browser can not detect whether it is safe to allow the JavaScript code to recover the context?

Project Member

Comment 13 by sheriffbot@chromium.org, Mar 24 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Comment 14 by kbr@chromium.org, Mar 24 2017

Labels: Needs-Feedback
mbolanos: I'm not sure why you're getting the error "Context lost during MakeCurrent" but regardless Chrome can almost never prove that it's safe to allow WebGL context recovery. On Windows, where you're running, it's impossible.

In order for us to make more progress on this bug we need a test case -- ideally, a minimized test case that does operations similar to what your application does, and provokes the same problem reliably.

Ok, I will try to provide such test case.
Project Member

Comment 16 by sheriffbot@chromium.org, Mar 24 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kbr@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
Labels: Needs-Triage-M57

Comment 19 by capn@chromium.org, Apr 13 2017

Blocking: -630728
mbolanos@ could you run your test with the latest Chrome Canary? We have SwiftShader fully integrated now.

I've verified in a local build that when the GPU process crashes three times, we're successfully falling back to using SwiftShader. But I don't think it helps in case of a lost GPU context. At the moment we can't have both the GPU and SwiftShader active simultaneously, but we plan to add support for that.

In any case, I don't think this is a blocker for  Issue 630728  itself.
I'll try that and let you know the results
Project Member

Comment 21 by sheriffbot@chromium.org, Apr 13 2017

Cc: kainino@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kainino@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
Status: WontFix (was: Unconfirmed)
Closing due to lack of feedback over 31 days.  Please re-open if issue still occurs and more information can be added.

Sign in to add a comment