On Wed, Apr 13, 2011 at 4:43 PM, Glenn Maynard <gl...@zewt.org> wrote: > On Wed, Apr 13, 2011 at 4:21 PM, Kenneth Russell <k...@google.com> wrote: >> >> It's essential to be able to report more detail about why context >> creation failed. We have already received a lot of feedback from users >> and developers of popular projects like Google Body that doing so will >> reduce end user frustration and provide them a path toward getting the >> content to work. > > Hixie says this is a bad idea, for security reasons, and that the UA should > just tell the user directly: > http://krijnhoetmer.nl/irc-logs/whatwg/20110413#l-1056 > > That said, the discussion lead to another approach: > > Calling canvas.getContext("webgl", {async: true}) will cause it to *always* > return an object immediately, without attempting to initialize the > underlying drawing context. This context starts out in the "lost" state. > As long as WebGL is supported by the browser, getContext will never return > null, even for blacklisted GPUs. The context is initialized > asynchronously. On success, webglcontextrestored is fired, as if the > context had just come back from a normal context loss. On failure, > webglcontextcreationerror is fired with a statusMessage, and possibly a flag > indicating whether it's a permanent failure (GPU blacklisted) or a > recoverable one (insufficient resources). > > If {async: true} isn't specified, then an initial context failure returns > null (using the "unsupported contextId" approach), and there's no interface > to get an error message--people should be strongly discouraged from using > this API (deprecating it if possible). > > (If it's possible to make the backwards-incompatible change to remove sync > initialization entirely, that would be good to do, but I'm assuming it's > not.) > > There are other fine details (such as feature detection, and possibly > distinguishing "initializing" from "lost"), but I'll wait for people to give > their thoughts before delving in deeper. Aside from giving a consistent way > to report errors, this allows browsers to initialize WebGL contexts in the > background.
Providing a programmatic status message about why WebGL initialization failed (for example, that the user's card or driver is blacklisted) is not a security issue. First, there would be no way to issue work to the GPU to exploit any vulnerabilities that might exist, since the app couldn't get a WebGLRenderingContext. Second, there wouldn't be detailed enough information in the error message to find out what graphics card is in use and attempt any other kind of targeted attacks using other web rendering mechanisms. Adding support for asynchronous initialization of WebGL is a good idea, and should be proposed on public_webgl, but this discussion should focus solely on improving the specification of the existing synchronous initialization path, and its error conditions. Given that the proposed asynchronous initialization path above uses webglcontextcreationerror and provides a status message, I think that should continue to be the error reporting mechanism for the current initialization path. Then the introduction of any asynchronous initialization path would be very simple: the application should anticipate that it will receive a context lost event immediately, rather than assuming it can immediately do its initialization. Error reporting would be identical in the two scenarios. -Ken
