Bug 42125 – bufferData and bufferSubData generate wrong error when null buffer is bound

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

[Kenneth Russell]

When no buffer is bound to the ARRAY_BUFFER or ELEMENT_ARRAY_BUFFER binding point and bufferData or bufferSubData are called, the WebGLRenderingContext will synthesize INVALID_ENUM. In this case it should synthesize INVALID_OPERATION.

[Zhenyao Mo]

Created attachment 61432 [details]
patch

[Zhenyao Mo]

Created attachment 61723 [details]
revised patch

Sync the test with khronos conformance tests using kbr's script.  No other changes.

[Kenneth Russell]

Comment on attachment 61723 [details]
revised patch

Looks nice.

[Nate Chapin]

Comment on attachment 61723 [details]
revised patch

Ok.

[David Levin]

It looks like you change the behavior so that when usage is not a valid enum, it will set INVALID_ENUM but it did not do this before from what I can tell.

Would you add a test for that as well?

[Zhenyao Mo]

(In reply to comment #5)
> It looks like you change the behavior so that when usage is not a valid enum, it will set INVALID_ENUM but it did not do this before from what I can tell.
> 
> Would you add a test for that as well?

The test case was added by an earlier patch to invalid-passed-params.html.

See https://bugs.webkit.org/show_bug.cgi?id=41574

[Zhenyao Mo]

Seems like there is a bug in webkit-patch land.  Changeset message got mixed with a previous patch, and it didn't automatically close this bug.

Close it manually: http://trac.webkit.org/changeset/63505

[Zhenyao Mo]

(In reply to comment #7)
> Seems like there is a bug in webkit-patch land.  Changeset message got mixed with a previous patch, and it didn't automatically close this bug.
> 
> Close it manually: http://trac.webkit.org/changeset/63505

Seems like the cause is the automatic rebasing of WebCore/Changelog went wrong: a latest patch's log wasn't pushed on top; it was inserted second place.  Manually fix this issue in the ChangeLog: http://trac.webkit.org/changeset/63506

[Eric Seidel (no email)]

@abarth:  Could this be the new retry code failing?  Or did svn-apply somehow apply this (seeminly correctly created diff) wrong?

[Adam Barth]

> Could this be the new retry code failing? 

I doubt it.  That's for commit-queue only.

> Or did svn-apply somehow apply this (seeminly correctly created diff) wrong?

I be the committer ran update-webkit can got a clean merge so resolve-ChangeLogs didn't move the ChangeLog entry to the top.  We just need to error out of webkit-patch land if the diff to the ChangeLog isn't at the top.

[Eric Seidel (no email)]

Oh!  I was confused.  I thought this was landed by the cq.  Yes, if you landed it manually, git will often mangle your ChangeLogs like this.

We need to put some detection code in webkit-patch land to abort hte commit if your ChangeLog got git-mangled.