failed: negativeTextureApi.copytexsubimage2d_max_level: Expected gl.INVALID_VALUE, but got gl.INVALID_OPERATION. failed: negativeTextureApi.texsubimage2d_max_level: Expected gl.INVALID_VALUE, but got gl.INVALID_OPERATION. failed: negativeTextureApi.texsubimage3d_max_level: Expected gl.INVALID_VALUE, but got gl.INVALID_OPERATION. failed: negativeTextureApi.copytexsubimage3d_max_level: Expected gl.INVALID_VALUE, but got gl.INVALID_OPERATION.

We should check the max texture size to return correct error type.

There is some tabs in the original patch. Replace them to spaces.

Sorry, the last patch was wrong. This should be the correct one.

Comment on attachment 8808921 [details] [diff] [review] check max size Review of attachment 8808921 [details] [diff] [review]: ----------------------------------------------------------------- This should already be handled properly in ValidateTexImageSpecification. Please re-check.

(In reply to Jeff Gilbert [:jgilbert] from comment #4) > Comment on attachment 8808921 [details] [diff] [review] > check max size > > Review of attachment 8808921 [details] [diff] [review]: > ----------------------------------------------------------------- > > This should already be handled properly in ValidateTexImageSpecification. > Please re-check. Right, I should reuse the code in ValidateTexImageSpecification.

I move the check from ValidateTexImageSpecification to ValidateTexImage. So ValidateTexImageSelection (for TexSubImage and CompressedTexSubImage) can do this check too.

(In reply to Ethan Lin[:ethlin] from comment #6) > Created attachment 8809292 [details] [diff] [review] > check max size > > I move the check from ValidateTexImageSpecification to ValidateTexImage. So > ValidateTexImageSelection (for TexSubImage and CompressedTexSubImage) can do > this check too. It should only be necessary for Specification. Too large width/height/depth will get automatically checked by Selection checking against the previously-specified extents.

It's likely this test is wrong. What's the actual invocation here? It's possible it's wrong in more than one way. Occasionally the conformance tests accidentally assume that some errors will occur before others, when actually any applicable error can be returned.

Comment on attachment 8809292 [details] [diff] [review] check max size Review of attachment 8809292 [details] [diff] [review]: ----------------------------------------------------------------- r- for now, because I don't think this is the correct solution.

This crashes on Windows+Intel.

Half the issue is the test is wrong: https://github.com/KhronosGroup/WebGL/pull/2207

Comment on attachment 8818769 [details] Bug 1315866 - Always-too-large level during tex image specification is INVALID_VALUE. - https://reviewboard.mozilla.org/r/98710/#review99230

Pushed by jgilbert@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/013060399bd7 Always-too-large level during tex image specification is INVALID_VALUE. - r=ethlin

Comment on attachment 8818769 [details] Bug 1315866 - Always-too-large level during tex image specification is INVALID_VALUE. - Approval Request Comment [Feature/Bug causing the regression]: webgl2 [User impact if declined]: [Is this code covered by automated tests?]: [Has the fix been verified in Nightly?]: [Needs manual test from QE? If yes, steps to reproduce]: [List of other uplifts needed for the feature/fix]: [Is the change risky?]: [Why is the change risky/not risky?]: [String changes made/needed]:

Comment on attachment 8818769 [details] Bug 1315866 - Always-too-large level during tex image specification is INVALID_VALUE. - Fix a WebGL 2 related issue. Beta51+ and Aurora52+. Should be in 51 beta 10.