Bug 188825

Created attachment 347717 [details]
Patch

Comment on attachment 347717 [details]
Patch

Clearing flags on attachment: 347717

Committed r235206: <https://trac.webkit.org/changeset/235206>

All reviewed patches have been landed.  Closing bug.

<rdar://problem/43623888>

Comment on attachment 347717 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=347717&action=review

> LayoutTests/webgl/2.0.0/resources/webkit-webgl-test-harness.js:53
> +        list(msg, "green");

I think I misled you by suggesting using the <ol> since it doesn't carry into the expected results.

I think the output could be improved more. The |msg| reported by the tests are not in the usual format that we're used to reading, so when I read some of these comments, it's hard to tell whether it's a good thing that "default precision qualifier shouldn't work with vec2". And if everything passes, it's hard to tell, despite the final "PASS".

Can we reformat these so that they look like

resultNum + ": PASS. " + msg

Then something like attrib-location-length-limits is easier to read:

1: PASS. gl.getProgramParameter(program, gl.LINK_STATUS) is true
2: FAIL. getError expected: NO_ERROR. Was INVALID_VALUE :
3. FAIL. attrib location was -1, should not be
4: FAIL. getError expected: NO_ERROR. Was INVALID_VALUE :
5: PASS. wtu.loadProgramFromScriptExpectError(gl, "badVertexShader", "fragmentShader") is null
6: PASS. getError was expected value: NO_ERROR :
7: PASS. getError was expected value: INVALID_VALUE :
8: PASS. gl.getAttribLocation(program, attrib1025Name) is -1
9: PASS. getError was expected value: INVALID_VALUE :
successfullyParsed is true
FAIL

Also looking at the tests with expected results that changed, it looks like the "successfullyParsed is true" counts as a PASS? Is that necessary? Can we prevent that?