742781 - Implement WEBGL_debug_renderer_info extension

Status: RESOLVED FIXED

(Core :: Graphics, enhancement)

Comment 1

[Kenneth Russell]

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.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

Taking it; need it for bug 795701.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: implement WEBGL_debug_renderer_info

Boris for bindings aspects; Jeff for WebGL aspects.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: implement WEBGL_debug_renderer_info

Forgot new file.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: updated --- GetSupportedExtensions didn't list the new extension

carrying forward r+

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Chrome mochitest

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.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Chrome mochitest

Forgot a hg add.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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

Comment 18

[Benoit Jacob [:bjacob] (mostly away)]

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 19

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 671991 [details] [diff] [review]
Chrome mochitest

[Approval Request Comment]
See previous comment.

Comment 20

[Alex Keybl [:akeybl]]

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

Comment 21

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 22

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 23

[Alex Keybl [:akeybl]]

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.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 25

[Florian Scholz (Open Web Docs)]

https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug_renderer_info