framebuffer-completeness-unaffected.html is failed due to the same root cause:

if READ_BUFFER or DRAW_BUFFERs point to an attaching point with no image, FRAMEBUFFER_MISSING_ATTACHMENT is returned by checkFramebufferStatus(). However, framebuffer completeness should not be affected by READ_BUFFER or DRAW_BUFFERs settings.

 Issue 604053  has been merged into this issue.

To clarify: the failing tests described here are:
https://www.khronos.org/registry/webgl/sdk/tests/deqp/functional/gles3/fbocompleteness.html

https://www.khronos.org/registry/webgl/sdk/tests/conformance2/rendering/framebuffer-completeness-unaffected.html

Radar 28236629 filed about this.

For the record, this is fixed in OSX 10.12.2 Beta (16C32f) on AMD, but not on Intel.

We have to decide to work around it or move it to WebGL conformance 2.0.1

Qiankun, Yunchao, anyone from Intel can take a shot at this one? Since it's not fixed in the 10.12.2 Beta on Intel.

The idea is to change READ_BUFFER and DRAW_BUFFERs settings if there are no images attached when calling CheckFramebufferStatus (and remember to reset if anything changes that might affect this, I think command buffer already has a dirty bit mechanism for CheckFramebufferStatus).

OK, Zhenyao, I will take a look. 

This is a corner case, when the readbuffer/drawBuffers has been designated attachment point(s), but the attachment point(s) have no image, the GLES spec think it should be FRAMEBUFFER_COMPLETE. But mac doesn't follow the spec. 

I think we can use a workaround to return FRAMEBUFFER_COMPLETE directly for this corner case. Instead of set the READ_BUFFER and DRAW_BUFFERS and restore them before reading/rendering. WDYT? 

Please see the patch at https://codereview.chromium.org/2496813002/. It works fine on Mac Intel. I suppose we can apply it to all MacOSX vendors. 

This will not work when you try to render to it at least.

Say, one of the drawBuffers buffer doesn't have an image, but other buffers do.  Now you try to draw to it (or clear), and then you fake the framebuffer completeness, but actual draw/clear will fail because the driver thinks it's incomplete.

You will have to modify the drawBuffers/readbuffer settings so the driver thinks it's fbo complete.

Zhenyao, you are correct. The current WebGL conformance tests don't cover this feature. So the bots are all green. However, My pr at https://github.com/KhronosGroup/WebGL/pull/2137/ can catch the error you pointed out. 

BTW, this error not only appears when we call checkFramebufferStatus on Mac, but also appears for all other reading/drawing related APIs when some designated attachment point(s) have no image(s). It always reports GL_FRAMEBUFFER_INVALID_OPERATION on Mac in this situation, because it thinks that it is FRAMEBUFFER_INCOMPLETE (this is wrong). 

https://github.com/KhronosGroup/WebGL/pull/2137/ was merged, does that mean this is fixed or what are the next steps yunchao?

The next step is to get Intel's (or Apple's) Mac driver team to fix this. Working around it seems very nasty and bug-prone to me.

This is fixed on AMD in OSX 10.12.2 (16C67).

As requested by Apple, filed another radar (29715965) for the same issue on Intel GPUs

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1733d120eb79e2d8d49b18892e60ee1297f646f7

commit 1733d120eb79e2d8d49b18892e60ee1297f646f7
Author: zmo <zmo@chromium.org>
Date: Thu Jun 08 23:24:48 2017

Update WebGL2 conformance test expectations for Mac bots.

BUG= 598930 , 617290 , 618464 ,630800, 641149 , 643866 , 645298 , 646182 , 654187 , 663188 ,665197, 665656 , 676848 , 679682 , 679684 , 679686 , 679687 , 679689 , 679690 , 679691 , 680278 , 684903 
TEST=mac bots on GPU FYI waterfall
TBR=kbr@chromium.org,kainino@chromium.org
NOTRY=true
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2931993002
Cr-Commit-Position: refs/heads/master@{#478121}

[modify] https://crrev.com/1733d120eb79e2d8d49b18892e60ee1297f646f7/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still fails for me on macOS 10.13.4, Intel HD Graphics 6000.

I think we can downgrade to P3. I just updated radar 29715965 with my latest test result, so marking as ExternalDependency.