[whatwg] Canvas.getContext error handling

[Ian Hickson]

To summarise this thread:

WebGL has the unfortunate problem of being likely to run into hardware 
limitations more often that most other features, due to limited GPU
resources. Authors need to be able to distinguish the temporary failure of 
a context not being immediately available from the permanent failure of 3D 
not being supported on the system at all.

I think the proposal below handles this well already, with the HTML 
specification as it stands today. I'm happy to add more editorial text to 
the specification discussing this issue if that would help.


On Tue, 12 Apr 2011, Kenneth Russell wrote:
> 
> [...] a good quality WebGL implementation would like to notify the app 
> when the graphics card is available. In order for this to work, WebGL 
> would actually need to return a non-null WebGLRenderingContext, but 
> immediately dispatch a webglcontextlost event to the canvas.

This seems like the best way to go for any temporary error situation.


> To sum up, in general I think that whenever getContext("webgl") returns 
> null, it's unrecoverable in a high quality WebGL implementation.

Agreed.


On Thu, 14 Apr 2011, Cedric Vivier wrote:
>
> Applications could detect all possible context creation failure 
> scenarios with something like this :
> 
> var gl = canvas.getContext("webgl");
> if (!gl) {
>     if (!window.WebGLRenderingContext) {
>        // Your browser does not support WebGL. Please upgrade your browser.
>     } else {
>        // WebGL could not be initialized on your setup. Please check
>        // that your GPU is supported and/or upgrade your drivers.
>     }
> }
> if (gl.isContextLost()) {
>     // Not enough resources to initialize WebGL. Please try closing
>     // tabs/programs...
>     // (an application can, but is not required to, listen to
>     // webglcontextlost and use statusMessage to give more information) 
> }

Right.


> For the use case of detecting context restoration error, we could 
> possibly add an 'isRestorable' boolean to webglcontextlost event to 
> signal the app when restoration failed (and/or won't ever happen).

Seems reasonable.


> Therefore I believe we can get rid of webglcontextcreationerror 
> entirely, and we do not need to throw an exception either.

Sounds good.


On Tue, 12 Apr 2011, Glenn Maynard wrote:
>
> Based on some discussion[1], it looks like a clean way to handle the 
> "permanent failure" case is: If the GPU is blacklisted, or any other 
> permanent error occurs, treat "webgl" as an unsupported context.  This 
> means instead of WebGL's context creation algorithm executing and 
> returning null, it would never be run at all; instead, step 2 of 
> getContext[2] would return null.

Indeed. I've updated the spec to mention this explicitly.


> For transient errors, eg. too many open contexts, return a WebGL context 
> in the "lost" state as Kenneth described.

Indeed.


> It was mentioned that the GPU blacklist can change as the browser runs. 
> That's supported with this method, since whether a context type is 
> "supported" or not can change over time.

Right.


On Wed, 13 Apr 2011, Kenneth Russell 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.

This is something the browser should do directly. I don't think pages 
should be doing this, otherwise every page will have to reimplement the 
same error reporting logic.


On Wed, 13 Apr 2011, Glenn Maynard wrote:
> 
> 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.

It seems bad to have two modes here. Are there really 


On Wed, 13 Apr 2011, Kenneth Russell wrote:
> 
> 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.

It's partly a security issue and partly a privacy issue.

It's a security issue because it discloses to an attacker that the user's 
video drivers can be attacked. How much information we disclose depends on 
how useful this is, but it is always going to be useful to some extent, 
because it gives an attacker somewhere to start, or tells the attacker to 
concentrate on another area.

It's a privacy issue because it increases the fingerprintability of the 
user. How bad this is depends on how many bits of information we return, 
but at a minimum it provides one bit: has a bad driver vs does not.


> 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.

That assumes the attacker has no other way to get the user to use 3D. One 
might well imagine scenarios in which an attacker could use the 
information to try to social-engineer the victim into running software 
that usse 3D (e.g. a game that they own) in a way that they can abuse 
(e.g. because the game renders custom models or some such).

I agree that this is a minor threat. The question is how much benefit do 
users get from having each page be able to provide a custom message 
regarding the video card being blacklisted, instead of having the browser 
provide that message, vs how much risk is the user taking by us exposing 
that information to the page.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'