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

David Sheets [email protected]
Fri May 6 21:03:18 PDT 2011


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

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