Bug 31088 – Add overridePreference call to all WebGL layout tests

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Kenneth Russell]

The WebGL layout tests all need the call

if (window.layoutTestController)
    layoutTestController.overridePreference("WebKitWebGLEnabled", "1");

as a prologue. This bit is sticky across runs, but an initial run with this bit unset causes the layout tests to fail with the error

"TypeError: Result of expression 'context' [undefined] is not an object."

[Kenneth Russell]

Created attachment 42424 [details]
Patch

[Oliver Hunt]

Comment on attachment 42424 [details]
Patch

This should just be put in one place, the shader-test.js test prefix

[Kenneth Russell]

Created attachment 42430 [details]
Patch

Replacement patch factoring this call into new webgl-test.js for sharing among more tests.

[Oliver Hunt]

Comment on attachment 42430 [details]
Patch

There's no reason to use a separate file -- if absolutely necessary rename shader-test.js to webgl-test.js that way each test doesn't end up needing to include multiple files

[Kenneth Russell]

Created attachment 42433 [details]
Patch

Patch renaming shader-test.js to webgl-test.js, adding necessary code, and updating references from tests.

[Mark Rowe (bdash)]

(In reply to comment #0)
> The WebGL layout tests all need the call
> 
> if (window.layoutTestController)
>     layoutTestController.overridePreference("WebKitWebGLEnabled", "1");
> 
> as a prologue. This bit is sticky across runs, but an initial run with this bit
> unset causes the layout tests to fail with the error
> 
> "TypeError: Result of expression 'context' [undefined] is not an object.”

Can you clarify what you mean by “This bit is sticky across runs”?

[Kenneth Russell]

It appears that if a test is run once under DumpRenderTree and the overridePreference is executed, then subsequent runs will work even if the overridePreference call is not in place. In other words, the effect is similar to the "defaults write" command currently used to enable WebGL in WebKit nightly builds.

[Mark Rowe (bdash)]

(In reply to comment #7)
> It appears that if a test is run once under DumpRenderTree and the
> overridePreference is executed, then subsequent runs will work even if the
> overridePreference call is not in place. In other words, the effect is similar
> to the "defaults write" command currently used to enable WebGL in WebKit
> nightly builds.

That sounds like a bug in DRT.  It should be resetting preferences to a consistent state between tests, not letting them persist.

[Oliver Hunt]

Committed r50492

[Kenneth Russell]

(In reply to comment #8)
> (In reply to comment #7)
> > It appears that if a test is run once under DumpRenderTree and the
> > overridePreference is executed, then subsequent runs will work even if the
> > overridePreference call is not in place. In other words, the effect is similar
> > to the "defaults write" command currently used to enable WebGL in WebKit
> > nightly builds.
> 
> That sounds like a bug in DRT.  It should be resetting preferences to a
> consistent state between tests, not letting them persist.

After looking into this a little further, the overridePreference setting isn't sticky across runs, but if ObjC code was ever used to force this preference to true in the context of DumpRenderTree (and it looks like this was done on some of the developers' machines) then it is persistent. I've filed

DumpRenderTree can retain preferences state across runs
https://bugs.webkit.org/show_bug.cgi?id=31129