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.
Created attachment 61432 [details] patch
Created attachment 61723 [details] revised patch Sync the test with khronos conformance tests using kbr's script. No other changes.
Comment on attachment 61723 [details] revised patch Looks nice.
Comment on attachment 61723 [details] revised patch Ok.
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?
(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
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
(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
@abarth: Could this be the new retry code failing? Or did svn-apply somehow apply this (seeminly correctly created diff) wrong?
> 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.
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.