WebGLObject creation is now infallible, and starts Lost iff context Lost.

[kdashg]

A general design pattern for WebGL is that it should generally be possible for rare failures (like context lost) to be ignorable when possible, such that code Just Works, and doesn't have to be rigorously robust to unusual failure cases. This is particularly important for context loss, since it is absolutely random, and could happen between any two invocations in JS.

For example, getUniformLocation might fail if a program doesn't have an expected uniform name, or fails to link. (or if context is lost!) By making e.g. uniform1i take WebGLUniformLocation? location and not WebGLUniformLocation location, we can paper over certain (rare-ish?) partial failures, rather than snowballing failures into black screens or runtime exceptions.

It would be helpful to developers if object creation were infallible, since returning null here can cause hard-to-isolate bugs.
Infallible creation means that the following pattern is safe:

const fb = gl.createFramebuffer();
fb.gl = gl;

Object creation can still always fail due to true OOM situations, just as creating other dom and js objects can fail if you run out of memory. (it generates an exception)

Additionally, this makes it easier to add labels robustly in #3637, though there is no strict dependency between these PRs.

This PR does not provide a way to detect whether creation is infallible when running on a particular (version of a) user agent/browser, but I think that's ok if we have group consensus to add this, since there are not many implementations. (and most user code probably assumes this is the case anyways)

[kdashg]

For example, this code that I wrote for Best Practices is not robust against context-loss: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices#use_non-blocking_async_data_readback

[kenrussell]

Thanks for thinking about this so deeply and putting together this comprehensive change. I agree that apps will likely be more resilient to context losses with this spec update.

Have you had a chance to prototype this change in Firefox? Do the revised tests pass with the new context loss semantics?

I'd appreciate it if we could coordinate landing of this change so that we can minimize the time duration these top-of-tree tests are failing in various implementations, since these tests cover important functionality (context loss and restoration).

[kdashg]

Seems to be working properly in a prototype of Firefox:
https://treeherder.mozilla.org/jobs?repo=try&revision=63382bf6daa06fb9bd5a23e9217d3a18ec7bdace

[kdashg]

This landed in Firefox Nightly 130. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1892542

[kdashg]

Thanks all!