Initially thought this was a Mac driver bug:
https://github.com/KhronosGroup/WebGL/pull/2418
but it seems like it probably isn't.

I don't think I'll be able to look at this today before I leave.

 Issue 736870  has been merged into this issue.

Blocking on  issue 696126  - not entirely related, but similar and it was the motivation for writing this test in the first place.

This same test is failing on several Linux configurations:  issue 738244 .

Fails on Chrome, passes on Firefox on the Linux/Intel machine below. It seems likely that  issue 738244  is a duplicate.

Version Information
Data exported	6/29/2017, 5:56:28 PM
Chrome version	Chrome/59.0.3071.115
Operating system	Linux 4.8.0-58-generic
Software rendering list version	13.8
Driver bug list version	10.102
ANGLE commit id	a9042d3c1952
2D graphics backend	Skia/59 ef6f9c65527412ec4057ea0551f2e051beb94d32
Command Line Args	--flag-switches-begin --flag-switches-end
Driver Information
Initialization time	23
In-process GPU	false
Passthrough Command Decoder	false
Supports overlays	false
Sandboxed	true
GPU0	VENDOR = 0x8086, DEVICE= 0x1916
Optimus	false
Optimus	false
AMD switchable	false
Driver vendor	Mesa
Driver version	17.2.0
Driver date	
Pixel shader version	4.50
Vertex shader version	4.50
Max. MSAA samples	16
Machine model name	
Machine model version	
GL_VENDOR	Intel Open Source Technology Center
GL_RENDERER	Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)
GL_VERSION	4.5 (Core Profile) Mesa 17.2.0-devel

 Issue 738244  has been merged into this issue.

Working on a fix. Issue is platform independent, but it's inside the workaround code for adjust_src_dst_region_for_blitframebuffer.

Typo.

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

commit e576154ffac06ecc3ee25cc7c383cfaca31aafbd
Author: Kai Ninomiya <kainino@chromium.org>
Date: Sat Sep 16 04:06:43 2017

Fix adjust_src_dst_region_for_blitframebuffer for depth-only framebuffers

Bug: 731877, 644740
Test: conformance2/renderbuffers/multisampled-depth-renderbuffer-initialization.html
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
Change-Id: I37f09a2bdbe4466cadd640abf76cacedaf364f31
Reviewed-on: https://chromium-review.googlesource.com/668568
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502486}
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/gpu/command_buffer/service/framebuffer_manager.cc
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/gpu/command_buffer/service/framebuffer_manager.h
[modify] https://crrev.com/e576154ffac06ecc3ee25cc7c383cfaca31aafbd/gpu/command_buffer/service/gles2_cmd_decoder.cc

Not closing this yet because there's still a failure on the CQ on Mac/Intel. I can't reproduce that issue on my machine, so it could just be a bug in an older OS or different hardware. I plan to double check before closing this off.

Thanks. FYI, all of those machines should be running 10.12.6 at this point.

NTS: The remaining task here is to figure out whether this is still failing on the CQ.

Apparently still failing:

Expected exception while running WebglConformance_conformance2_renderbuffers_multisampled_depth_renderbuffer_initialization
Traceback (most recent call last):
  _RunGpuTest at content/test/gpu/gpu_tests/gpu_integration_test.py:138
    self.RunActualGpuTest(url, *args)
  RunActualGpuTest at content/test/gpu/gpu_tests/webgl_conformance_integration_test.py:186
    getattr(self, test_name)(test_path, *args[1:])
  _RunConformanceTest at content/test/gpu/gpu_tests/webgl_conformance_integration_test.py:200
    self._CheckTestCompletion()
  _CheckTestCompletion at content/test/gpu/gpu_tests/webgl_conformance_integration_test.py:196
    self.fail(self._WebGLTestMessages(self.tab))
  fail at .swarming_module/lib/python2.7/unittest/case.py:410
    raise self.failureException(msg)
AssertionError: should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
FAIL should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
FAIL should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
FAIL should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
FAIL should be 0,0,255,255
at (40, 0) expected: 0,0,255,255 was 0,255,0,255
Locals:

from https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac_optional_gpu_tests_rel/8529

Which shard of webgl2_conformance_tests was that failure from?

I copied it from stdout. But before I remembered I could do that, I kicked off this experimental run, in which it failed in shard #5:
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac_optional_gpu_tests_rel/8548

Since this is both old hardware and an old OS should we just mark it flaky on this configuration? If so would you prepare a CL doing so? Thanks.