Options: 1) Implement the Firefox support for this in the WebGL Inspector (http://benvanik.github.com/WebGL-Inspector/) so that all supported browsers have the same UI etc... 2) Write a specific (small) add-on for this specific use case I'd think (1) is the way to go, since the Chrome guys also want to develop an extension for this.

What is the current status of this feature request? As far as I can tell from bug 742781 it has been implement in Firefox and is viewable in about:support. Is it only accessible from extensions? Under what situations will it be exposed by getSupportedExtensions?

This extensions is implemented and always available to privileged content (i.e. Firefox extensions, etc). about:support is privileged content, that's why it's allowed to use it. General Web pages can't use it. If you want to expose privileged extensions like this one to general Web content, go to about:config and set webgl.enable-privileged-extensions to true. But you're on your own ;-)

Thanks! I did try the flag, but no luck getting it work (no additional extensions were exposed). Chrome 34+ appears to have this extension available by default now. Are there any plans for Firefox to do the same in the future?

That's strange: I can't reproduce this bug on current Nightly --- if I enable this flag, it takes effect immediately and reloading webglreport.sf.net shows it. I also checked source code (WebGLContextExtensions.cpp) and it looks fine. Regarding your question, I'm no longer directly involved in that side of things, you want to ask :jgilbert. The last time that I was involved, my thinking was that GL strings were a bad API to do the things that people asked them for at the time, which was adapting rendering code to the client system. That's a bad API for two reasons: because parsing these strings correctly is very hard due to their diversity; and because at best this would only tell you information about the GPU and driver version, and in the case of WebGL (contrary to OpenGL) that's not the only factor, and the CPU's speed, browser version, operating system version etc. play a much bigger role, making us think that the only way to tell reliably what rendering path will run fast enough on a given client system, is to benchmark it on that client system. That's why I have been telling application developers to run short benchmarks, for which they don't need any new API support. Secondarily, the other issue that would have to be considered if we otherwise wanted to expose GL strings, is privacy.