The problem is the application HAS TO TAKE ACTION if the context is lost and restored. So, if an webgl auto-restores the context and the app doesn't handle it the results are random and unpredictable. All resources are lost and you have to re-create them. If the app is creating resources on the fly some will get re-created some not. It was deemed that unpredictability is bad. Adding a listener to "webglcontextlost" is a signal to WebGL that "this app is going to handle lost/restored context". Any app that doesn't handle it should fail immediately on context lost which is why it's not auto-restored.The opposite way makes no sense. Apps that don't deal with lost-restored contexts are not going to start correctly marking themselves as unable to handle the situation. Rather, only apps that go to the effort to handle lost-restored contexts will tell WebGL they know how to handle it.