As there's currently no way to test a WebGL's implementation of context lost and restored events, add the WebGL extension proposed on the public_webgl mailing list for forcibly losing context. (Once committed, I will update the WebGL extension registry and the set of Khronos conformance tests. However, I wanted to get this reviewed first, as I'm sure there will be changes needed.)
Created attachment 77263 [details] Patch
Attachment 77263 [details] did not build on mac: Build output: http://queues.webkit.org/results/7316113
Created attachment 77278 [details] Patch
Created attachment 77342 [details] Patch
Attachment 77342 [details] did not build on mac: Build output: http://queues.webkit.org/results/7210140
Comment on attachment 77342 [details] Patch Can you look into the Mac build failure?
(In reply to comment #6) > (From update of attachment 77342 [details]) > Can you look into the Mac build failure? Will do.
Created attachment 77574 [details] Patch
Comment on attachment 77574 [details] Patch Really strange to have all this Chromium-specific stuff. An IDL file with Chromium in its name? Is this really platform-specific?
(In reply to comment #9) > (From update of attachment 77574 [details]) > Really strange to have all this Chromium-specific stuff. An IDL file with Chromium in its name? Is this really platform-specific? No, it's not. This patch implements a WebGL extension that is not necessarily browser-specific. There are really two issues here: 1) What to call the WebGL extension (currently CHROMIUM_lose_context). 2) What to call the class that implements it (currently ChromiumLoseContext). Chris Marrin suggested CHROMIUM_lose_context as an extension name on the public_webgl mailing list, so I went with that. I named the class analogously to how the existing OESTextureFloat class is named, as that seemed like a reasonable approach. So, that's how this patch ended up with a Chromium-named idl file. I don't feel very strongly about what this extension should be named. Thoughts from anybody else?
(In reply to comment #10) > I don't feel very strongly about what this extension should be named. Thoughts from anybody else? After some thought, since the extension will implicitly be supported in both Safari and Chromium, perhaps it should be called WEBKIT_lose_context. The primary disagreement on the WebGL mailing list was over making this an "official" extension with the WEBGL_ prefix.
(In reply to comment #11) > (In reply to comment #10) > > I don't feel very strongly about what this extension should be named. Thoughts from anybody else? > > After some thought, since the extension will implicitly be supported in both Safari and Chromium, perhaps it should be called WEBKIT_lose_context. The primary disagreement on the WebGL mailing list was over making this an "official" extension with the WEBGL_ prefix. That sounds great to me.
Created attachment 78071 [details] Patch
Created attachment 78074 [details] Patch
Comment on attachment 78074 [details] Patch Looks great. This will improve testability a great deal.
Committed r75271: <http://trac.webkit.org/changeset/75271>