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

Glenn Maynard [email protected]
Fri May 6 00:10:16 PDT 2011


On Fri, May 6, 2011 at 2:34 AM, Mikko Mononen <[email protected]> wrote:
>> I know what you're saying, but to interject here: hopefully the common
>> case for displaying errors won't be from the developer to the end
>> user, but from the browser directly to the end user.  (They aren't
>> doing this at all yet.)
>
> As a developer I have to disagree with the idea of browser directly
> talking to the user. IMHO This is different situation that a missing
> plugin.
>
> Currently the situation is that a lot of the folks coming to a webgl
> site can indeed see the content (in our case I think it is something
> like >60%). A great deal of the rest of users can be encourage to
> upgrade to a more fresh browser to make things work. That leaves us
> about 10% of users who either have old or weird os/driver combination.
> Those people need to be handled with developers support, because it
> generally is too complicated for them to triage the problem
> themselves, or it is too complicated to write comprehensive guide how
> to fix things*.

It's not the job of every person running a webpage to give end-user
tech support.  If I'm expected, as a web developer, to be the first
line of support for this sort of thing, that's a serious deterrent to
using it at all.  Browsers can do a lot to help users, because browser
vendors already know a lot about the problems people are hitting, and
they're the first to find out about new issues.

> There is no way my mum could understand what to do if she gets "Cannot
> initialize webgl" alert box when entering a home planner site.

That's not what a browser troubleshooting dialog would look like, of
course--and people at a home planner site probably won't know what to
do, either.  On the other hand, if the browser knows that it's
disabling WebGL because the user is running old drivers that are known
to crash systems, and if it knows that newer versions of those drivers
fix the problem, it can point the user right at the GPU vendor's site
for drivers.  It'd take me a lot more work to do that; I don't know
any of those things until I spend time troubleshooting and researching
the problem; and once I figure it out I'm going to do the exact same
thing the browser would have done.

>  If simple request of upgrading a browser on developers site cannot fix
> the problem, then the user needs to be channeled to the developer
> support, and in that case the developer should be able to have as much
> information as possible (such as the messages explained below)

It's always nice as a developer to have more information, but as I
said, even with a mechanism in place to provide this information
(which there currently is, we're just trying to fix it up), I have
doubts about vendors actually putting enough information in these
messages to be useful to developers.  Browser vendors are defensive
about what information they expose to scripts.  If no production
browsers will ever say anything more than "unsupported GPU", it's not
going to be very useful to anyone.

(Do any current browsers expose anything useful to
webglcontextcreationerror yet--or anything at all, for that matter?
I've never seen any information in it.)

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