Oops, hitting 'return' accidentally submitted the bug. This is an RFE to please expose the "WEBGL_debug_renderer_info" WebGL extension to privileged contexts in Firefox; namely, in WebGL contexts instantiated from Firefox extensions. The MapsGL team at Google, in particular, is interested in gathering more detailed information for any problem reports, and being able to query this information is important. They are considering writing a Chrome extension for this purpose in that browser, and it would be good if the same were possible in Firefox.

Taking it; need it for bug 795701.

Boris for bindings aspects; Jeff for WebGL aspects.

Forgot new file.

Comment on attachment 670584 [details] [diff] [review] implement WEBGL_debug_renderer_info This needs a test that ensures that this debug extension cannot be gotten from content. Ideally one that ensures that this is still true after chrome code _has_ gotten it from the same context. r=me with that.

(In reply to Boris Zbarsky (:bz) from comment #5) > Comment on attachment 670584 [details] [diff] [review] > implement WEBGL_debug_renderer_info > > This needs a test that ensures that this debug extension cannot be gotten > from content. Ideally one that ensures that this is still true after chrome > code _has_ gotten it from the same context. > > r=me with that. Hm. How do you enable/disable chrome privileges in a mochitest? How do you test what privileges you currently have?

> Hm. How do you enable/disable chrome privileges in a mochitest? You write a mochitest-chrome test that runs part of itself as chrome and part as not....

Thanks, I guess 'mochitest-chrome' was the keyword I was missing.

For future reference, https://developer.mozilla.org/en-US/docs/Chrome_tests

carrying forward r+

This works here. It relies on the nontrivial assumption that messages will be received in the same order as they are posted. Is that OK? If not, what approach would you recommend? - is it safe to assume that message handlers won't run before the current JS callback returns? If yes, a simple counter-based solution is possible. - Otherwise we can do more postMessage, a form of SYN/ACK protocol if you want.

Note, the rationale for using postMessage here is that apparently the non-Chrome code may not call the Chrome mochitest ok() function directly.

Forgot a hg add.

> It relies on the nontrivial assumption that messages will be received in the same order > as they are posted. Is that OK? As long as the posting is only happening from a single frame and the receiving is only happening in a single frame, that assumption is correct.

Comment on attachment 671991 [details] [diff] [review] Chrome mochitest This is good, but I would like it to test one more thing. Specifically, in the iframe.onload, I would like the chrome code to test that it can get the WEBGL_debug_renderer_info on the subframe's WebGL context. And then trigger the subframe part of the test _after_ that. Also, I'm not sure why "chrome" is capitalized all over in the subframe. ;) r=me with those fixed.

http://hg.mozilla.org/integration/mozilla-inbound/rev/756d555fc3bf http://hg.mozilla.org/integration/mozilla-inbound/rev/e78db739d589 (In reply to Boris Zbarsky (:bz) from comment #15) > Comment on attachment 671991 [details] [diff] [review] > Chrome mochitest > > This is good, but I would like it to test one more thing. Specifically, in > the iframe.onload, I would like the chrome code to test that it can get the > WEBGL_debug_renderer_info on the subframe's WebGL context. And then trigger > the subframe part of the test _after_ that. OK, done -- repeating the whole chrome test on that second canvas, factored into a helper function. > > Also, I'm not sure why "chrome" is capitalized all over in the subframe. ;) thanks, fixed. Ken & Zhenyao --- I don't see a good way to share such privileged extension tests at Khronos in a systematic way, but if you are interested, this code should be rather easy to adapt as WebKit/Chromium tests. You'd just have to replace the boilerplate code to create a privileged-code test, and the non-privileged domain for your test harness (replace http://mochi.test:8888/... by whatever gives non-privileged pages in your harness).

https://hg.mozilla.org/mozilla-central/rev/756d555fc3bf https://hg.mozilla.org/mozilla-central/rev/e78db739d589

Comment on attachment 671555 [details] [diff] [review] updated --- GetSupportedExtensions didn't list the new extension [Approval Request Comment] Bug caused by (feature/regressing bug #): Not a regression. But blocker for the fix for bug 795701 which is a regression caused by WebIDL port (bug 779611). User impact if declined: Bug 795701 will ship to users, causing about:support to miss WebGL renderer info. WebGL will still work unaffected, only about:support will miss information. Testing completed (on m-c, etc.): on m-c for several days now Risk to taking this patch (and alternatives if risky): medium risk. It's a new feature that must be exposed to privileged code only, but it's covered by an extensive mochitest-chrome test. String or UUID changes made by this patch: none

Comment on attachment 671991 [details] [diff] [review] Chrome mochitest [Approval Request Comment] See previous comment.

(In reply to Benoit Jacob [:bjacob] from comment #18) > Risk to taking this patch (and alternatives if risky): medium risk. It's a > new feature that must be exposed to privileged code only, but it's covered > by an extensive mochitest-chrome test. Do we have any lower risk alternatives. Obviously backing out bug 779611 wouldn't fly, but we're concerned with the medium risk evaluation. If this is the only path forward, where could we find regressions?

The only options are: - either backport this - or ship one Firefox version with no 'WebGL renderer' info in about:support. If we are going to backport this, we should then backport the chrome mochitest as well and verify that it's run. It's really extensive so as long as it succeeds I'm not afraid of regressions.

Also, if this caused regressions in other WebGL extensions it would cause mochitest-1 to go orange.

Comment on attachment 671555 [details] [diff] [review] updated --- GetSupportedExtensions didn't list the new extension Given testing coverage here, where we are in the cycle, and the possible support impact if declined, we'll take a fix for FF18.

https://hg.mozilla.org/releases/mozilla-aurora/rev/b77766bbadc1 https://hg.mozilla.org/releases/mozilla-aurora/rev/76d096e915c7 Note that bug 779611 interfered a bit with this applying cleanly.