[Public WebGL] Re: [whatwg] Canvas.getContext error handling

Mikko Mononen [email protected]
Sun May 8 01:52:51 PDT 2011

I included the get.webgl.org since it has been promoted at the main
vessel to help people to solve webgl issues. This discussion ties into
what the returned error message should be, and how is responsible to
deal with the error.

IMHO Error reporting is always more of an UX issue, than a code issue.
For that reason, I hope that there would a clear guideline (from
webgl) on what should be done in case of webgl errors (like console
TCRs) and a simple default implementation to help adobtation (like

+1 for David's proposal. I would be really happy if with the situation
that the browser could directly provide a browser specific link to a
trouble shooting site in the case the browser supports webgl, but it
could not be initialized (blacklisted, internal error, etc).

I'm fine with banner message boxes too as mentioned earlier. Would
that be something all browser vendors agree on implementing? I.e. it
is something I can refer to in the site copy? What if user chooses to
ignore it?

What should I do in other cases, direct people to get.webgl.org? For
me the biggest problem with get.webgl.org is that it does not look
something I can trust. It needs to look professional and it needs
branding which ties it to browser makers (I doupt the public knows
about khronos). I would be fine if get.webgl.org/troubleshooting would
be just just redirect service to browser vendors troubleshooting
pages. The mainpage should be more informative and written in a way
that it expects the user to come there because he/she does not not
have up to date browser or webgl is not supported in her platform. One
thing will always be missing here is what to do when none of the
upgrade options match the user's profile.

I apologize for dragging the discussion into tangent. My point is that
the decision you guys make on the error message has effect all the way
up to the end user. What I gather from the current proposals, it is
not clear who is responsible for trying to resolve the problem of the
end user.


On Sat, May 7, 2011 at 7:03 AM, David Sheets <[email protected]> wrote:
>> It's get.webgl.org I'm talking about.  This discussion is about
>> in-browser diagnostics (provided by the browser, with full access to
>> the system) versus in-site diagnostics like get.webgl.org, and how
>> useful the error messages provided to scripts by getContext are to the
>> latter in practice.
> Unfortunately, the most useful pieces of information (GPU vendor,
> driver version) appear to be verboten from crossing the sandbox
> boundary. Given this constraint, why not return a triple in the
> exception:
> localized error string
> standardized error code/object
> in-browser (chrome:? about:?) URL for diagnostics or graphics driver
> upgrade redirect (to protect vendor info)
> This gives the application developer control of the initial error
> condition and provides a link to a secure system to test the user's
> graphics subsystem and recommend further action. In many cases, the
> next time the user will return to the application site will
> necessarily be after a browser or OS restart and the diagnostic page
> is more noticeable and more usable than an infobar. Additionally, the
> diagnostic trigger is the standard web action of clicking a link and
> can be integrated into the application site.
> I don't know what the current feeling is on implementing web APIs that
> mandate Open Web -> In-browser links. I suppose this could be
> subverted for phishing attacks against graphics driver downloads. An
> on-error info bar doesn't seem quite right, however, as it takes
> control away from content developers who may wish to provide seamless
> fallbacks or handle certain known errors in special ways.
> Perhaps the error link could trigger a difficult-to-forge browser
> behavior like a native dialog or on-demand infobar.
>> If you're just talking about how to implement
>> in-site diagnostics, please start another thread so this one isn't
>> derailed.  Thanks.
> My aim with discussing in-site diagnostics was entirely to emphasize
> the abstraction of troubleshooting and error management. There had
> been discussion about developer burden and I was proposing a simple
> way to ease that burden by opening up an existing troubleshooting
> mechanism (get.webgl.org). I apologize for veering off-topic.
> David Sheets
>> --
>> Glenn Maynard

Mikko Mononen, Software Engineer
http://tinkercad.com - Solid modeling for artists & makers

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list