UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.41 Safari/537.36

Steps to reproduce the problem:
Load up a webgl example program. If necessary, modify its code so that it attempts to autorecover after a webglcontextloss. For example in a nutshell, if I have not misinterpreted various resources I've found, they suggest that a .preventDefault() can suppress the "Rats! WebGL hit a snag" popup:

	canvas.addEventListener("webglcontextlost", ev => this.onGlContextLost(ev), false);
	canvas.addEventListener("webglcontextrestored", ev => this.onGlContextRestored(ev), false);

	onGlContextLost(ev) {
		console.log('gl context lost. Waiting until it\'s restored...');
		ev.preventDefault();
		console.log('preventing default of event', ev);
		cancelAnimationFrame(this.animationRequest);
	}
	onGlContextRestored(ev) {
		console.log('... gl context regained! Reinitializing...');
		this.initFromFreshContext();
		console.log('... reinitialization complete!');
	}

Ensure that the example program can recover from a lost context. For example:

function _SIM_LOST_CONTEXT() {
	var ext = gl.getExtension('WEBGL_lose_context');

	console.log('simulating lost context for 2sec');
	ext.loseContext();

	var timeout = setTimeout(() => {
		if (gl.isContextLost()) {
			console.log('restoring simulated lost context');
			ext.restoreContext();
		}
	},2000);
}

Now, proceed to generate an 'authentic' webglcontextloss (the WEBGL_lose_context extension is *insufficient*... though I haven't tried any lower-level context loss API). One way I've found to force a context loss is running the test program in one tab, then loading up a very webgl-heavy site (e.g. as of right now, the shadertoy.com homepage or gallery will open up multiple webgl contexts, which are quite prone to crashing and heavy on resource utilization, and thus often take down all webgl in all tabs); I then navigate back to the tab with the test program which has crashed.

Alternatively on some machines, after many minutes or hours, an 'authentic' context loss may just spontaneously happen, perhaps while the webpage is open, or even in use.

-----------------

What is the expected behavior?
expected behavior:

Barring confounding circumstances (i.e. sorry if I'm messing something up here), I was hoping that the webgl context loss info bar was ignored by preventDefault(). In the ideal world, one could squelch the infobar, and furthermore a transient webgl context could recover very quickly without the need for user intervention. (At least, the web application would be allowed to try to recover.)

This seems possible for transient webgl hiccups; if I very quickly hit [Reload] and refresh the page, the webgl test program works fine immediately without any problem.

However, a quick refresh-free recovery may be particularly important, since the webgl may be interactive and the user may be in the process of taking keyboard or mouse input which ideally should not be lost (though if a context loss happens in the middle of e.g. a swipe gesture, I'm not sure if chromium keeps track of the timestamps in this situation correctly).

-------------------

What went wrong?
what went wrong:

The behavior which actually occurs is as follows: The "context loss info bar" (the yellow dropdown notification bar) appears saying "Rats! WebGL hit a snag. [Ignore] [Reload]". It was not prevented by [webglcontextloss event].preventDefault().

It is now necessary to hit the [Reload] button, and possibly refresh the webpage. The program is unable to recover from the webgl context loss without an awkward user intervention: asking the user to refresh the entire webpage manually, then reloading the exact state the application was in.

To make matters worse, if one does not respond to the yellow infobar, it remains through refreshes; until the user clicks [Reload], all attempts to reinitialize or otherwise create webgl contexts on the same page will fail. One can test this by checking .isContextLost() on the original context, then creating a new canvas and trying to create a new context: the new context thus returned will also have .contextLost()==true.

----------------------------------

Crashed report ID: yes

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? N/A 

Chrome version: 54.0.2840.41  Channel: beta
OS Version: 6.3
Flash Version: 

Additional comments: When using the above replication strategy, if the refreshing won't fix things, it may be necessary to check about:gpu to see if the GPU process has crashed in the log.

(The only workaround I can think of is to, with the help of the server redirecting /app1 /app2 /app3 ... all to the same webpage, increment the webpage and reload with location.href... though that is almost too much of a hack to fathom.)

various conversations I encountered on the net while researching this problem:
https://www.khronos.org/webgl/wiki/HandlingContextLost
http://stackoverflow.com/questions/28135551/webgl-context-lost-and-not-restored
(also mozilla and chromium have implemented per-page and per-domain limits on simultaneous webgl contexts... so there ought to be a way for developers to gracefully recover from such context losses)