[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Firefox 4 and blacklist reporting


Hi all -- I work on Google Body. Our latest "check WebGL capabilities" code will look approximately like this:

    *    *    *

// 0 = OK. 1 = no GL. 2 = GL couldn't initialize. Other = error text.
function testGL() {
  try {
    if (!window.WebGLRenderingContext) { return 1; }
    var canvas = document.getElementById('gltest');
    var gl = canvas.getContext('webgl');
    if (!gl) {
      gl = canvas.getContext('experimental-webgl');
    if (!gl) { return 2; }
    return 0;
  } catch(err) {
    // [report err.message]

    *    *    *

Using FF4/Mac on OS X 10.5.8, the above throws an exception, with err.message =
    "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLCanvasElement.getContext]"

I understand from the Firefox blocklist wiki page that Firefox is blacklisting WebGL. I'm curious why this is being reported via an exception.
Does the spec say something about that? Or have other browsers agreed on behavior in that case?
The problem I'm having is that I want to show different UI for these two cases:
  - GL is blacklisted (=> fine, can take user to troubleshooting page and coach them through it)
  - A _javascript_ error occurred (=> not fine, need to investigate)

and I'm not sure what the best way going forward is to distinguish those cases.
I think I understand your concern: that adding this try {...} catch block may hide _javascript_ errors. But so far, this had been the standard way of creating WebGL contexts, see the WebGL conformance tests, get.webgl.org, etc.

If other browser implementers think that we should not generate JS exceptions in getContext() on blacklisted drivers/systems, I'm not opposed to such a change. Would getContext() then just return null? I couldn't find in the spec anything about errors in getContext and return values?