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

commit 8e0f4b4d1a4293374634e672bc4b95d25db0ee6c
Author: Yuly Novikov <ynovikov@chromium.org>
Date: Tue Apr 10 00:25:46 2018

Mark a WebGL test Flaky

conformance/textures/misc/tex-video-using-tex-unit-non-zero.html
on Nexus 6

BUG= 830901 
TBR=kbr@chromium.org

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ib2cb08889cab634a8a026d0ef4619937e87cfbce
Reviewed-on: https://chromium-review.googlesource.com/1003286
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549344}
[modify] https://crrev.com/8e0f4b4d1a4293374634e672bc4b95d25db0ee6c/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

+kainino for WebGL triage

Also flaky on Nexus 9
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20FYI%20Release%20%28Nexus%209%29/3513
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20FYI%20Release%20%28Nexus%209%29/3464
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20FYI%20Release%20%28Nexus%209%29/3427

Same error:
    msg : u'Texture states were incorrect, rendering was wrong\nFAIL Texture states were incorrect, rendering was wrong\n'

Will expand the suppression.

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

commit 7b19c421e5dbecd59547b4493fb0626318d12a96
Author: Yuly Novikov <ynovikov@chromium.org>
Date: Fri May 18 18:28:03 2018

Mark a WebGL test Flaky

conformance/textures/misc/tex-video-using-tex-unit-non-zero.html
on Nexus 9

TBR=kbr@chromium.org

Bug:  830901 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Idbd42993d03c10ecb8f3167763e9444e45c3685e
Reviewed-on: https://chromium-review.googlesource.com/1066314
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559966}
[modify] https://crrev.com/7b19c421e5dbecd59547b4493fb0626318d12a96/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

Also Flaky on Nexus 6P:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20FYI%20Release%20%28Nexus%206P%29/4891
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20FYI%20Release%20%28Nexus%206P%29/4974

Will expand the suppression once again.

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

commit c2eb1381c791d60d8c5985d2b62acf887bedbbe3
Author: Yuly Novikov <ynovikov@chromium.org>
Date: Thu Jun 28 02:24:02 2018

Suppress a Flaky WebGL test

conformance/textures/misc/tex-video-using-tex-unit-non-zero.html
on Nexus 6P

TBR=kbr@chromium.org

Bug:  830901 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I46e417c564fe810d70fa7fa8b3614c6e8d16fa89
Reviewed-on: https://chromium-review.googlesource.com/1117316
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571000}
[modify] https://crrev.com/c2eb1381c791d60d8c5985d2b62acf887bedbbe3/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

 Issue 864965  has been merged into this issue.

Per  Issue 830901  this is being seen on Windows too. cwallez@ reports:

-----
This bot: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Debug%20%28NVIDIA%29?limit=200

Starting from this build: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Debug%20%28NVIDIA%29/1164

Flakes on WebglConformance_conformance_textures_misc_tex_video_using_tex_unit_non_zero by having the pixel compare of that test fail.

Looking in the changelogs for the 4 last builds, I found one slightly related commit if the failing video is h264, maybe: https://chromium.googlesource.com/chromium/src/+/22c1a0ffad44a60ab1ca4f18c1d414b311dc08aa

Unfortunately I don't have a Windows machine to try and reproduce this.
-----

It's being seen on the Mac trybots on the CQ too:

https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac_chromium_rel_ng/97349
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac_chromium_rel_ng/97469

A very rough blamelist based on the recent flakiness on this bot:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Debug%20%28NVIDIA%29?limit=200

would indicate:

http://crrev.com/b1877f022d1b8b9532da1b26e288211345ff0451..9f049de726d02630e1d1f04f3534cf1928b884fb

which is large.

I'm going to suppress this failure and restructure the test. It looks like its logic is possibly conceptually wrong and may allow different video frames to be uploaded to the two textures.

Looking at the test again, its logic is correct. I thought that the video was playing while the test was running, but it's paused:

https://cs.chromium.org/chromium/src/third_party/webgl/src/sdk/tests/conformance/textures/misc/tex-video-using-tex-unit-non-zero.html?type=cs&q=tex-video-using-tex-unit-non-zero.html&sq=package:chromium&g=0&l=142

Whatever is going wrong here is in the media stack and not in the test or WebGL. I'll still improve the logging from this test to hopefully get a better diagnosis.

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

commit 0e7f1e0f94bd5a8a844346400e2ab6f47038fcc8
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Jul 19 03:29:53 2018

Suppress flaky WebGL video upload test.

conformance/textures/misc/tex-video-using-tex-unit-non-zero.html is
failing intermittently on all platforms. Going to rewrite the test for
better correctness and improve its diagnostics.

Bug:  830901 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Ice9efc8cdcff75753bfd64c231dafc7c7a154790
Tbr: cwallez@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/1142698
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576349}
[modify] https://crrev.com/0e7f1e0f94bd5a8a844346400e2ab6f47038fcc8/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

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

commit 6f64860d89fdb6d3397286e722b42f18c7df7db7
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Jul 21 02:54:54 2018

Roll WebGL a5c263c..21dbf06

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/a5c263c..21dbf06

Bug:  830901 , 851870, 851873,  859400 ,  866089 
Tbr: zmo@chromium.org
Tbr: kainino@chromium.org
Cq-Include-Trybots: luci.chromium.try:win_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_angle_rel_ng;luci.chromium.try:win_angle_rel_ng
Change-Id: Icef8ddc970ccb6653e95920c28b4d003d1b27100
Reviewed-on: https://chromium-review.googlesource.com/1144306
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577063}
[modify] https://crrev.com/6f64860d89fdb6d3397286e722b42f18c7df7db7/DEPS
[modify] https://crrev.com/6f64860d89fdb6d3397286e722b42f18c7df7db7/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/6f64860d89fdb6d3397286e722b42f18c7df7db7/content/test/gpu/gpu_tests/webgl_conformance_revision.txt

You're the owner of a Pri-1 M-69 chrome media issue. M-69 is now in beta and will ship to stable in coming weeks. See go/chromeschedule. Please work on resolving your issue ASAP if it needs fixing for the M-69 branch.

Pri-1 means the work is required for the branch. Alternatively, update the milestone to M-70 or remove the milestone and drop the priority to P-3.

Removing the suppression to expose any remaining issues and hopefully get a better diagnosis. Downgrading to P3.

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

commit 33b6bb451566af421eee27c828f670278b6deefc
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Jul 27 20:58:49 2018

Revert tex-video-using-tex-unit-non-zero.html suppression.

Better diagnostics have been added to the test, so expose any flakes
that are still happening.

Tbr: kainino@chromium.org
Bug:  830901 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I5b1ba714f4854ef87b89f52c6bcfcf7652f06350
Reviewed-on: https://chromium-review.googlesource.com/1153556
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578776}
[modify] https://crrev.com/33b6bb451566af421eee27c828f670278b6deefc/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

Per  Issue angleproject:2748  this test is still flaky. It's not just failing on Debug bots:

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Debug%20%28NVIDIA%29/1245

but also on Release bots, for example:

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29/1827

 Issue angleproject:2748  has been merged into this issue.

With the improved logging, here is the output when a failure happens:

[337/462] gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest.WebglConformance_conformance_textures_misc_tex_video_using_tex_unit_non_zero failed unexpectedly 6.9060s:
  
  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\bin\Lib\unittest\case.py:410
      raise self.failureException(msg)
  AssertionError: Pixel 0: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 0: expected (13,67,100,127), got (13,67,100,255)
  Pixel 1: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 1: expected (13,67,100,127), got (13,67,100,255)
  Pixel 2: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 2: expected (13,67,100,127), got (13,67,100,255)
  Pixel 3: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 3: expected (13,67,100,127), got (13,67,100,255)
  Pixel 4: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 4: expected (13,67,100,127), got (13,67,100,255)
  Pixel 5: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 5: expected (13,67,100,127), got (13,67,100,255)
  Pixel 6: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 6: expected (13,67,100,127), got (13,67,100,255)
  Pixel 7: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 7: expected (13,67,100,127), got (13,67,100,255)
  Pixel 8: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 8: expected (13,67,100,127), got (13,67,100,255)
  Pixel 9: expected (13,67,100,127), got (13,67,100,255)
  FAIL Pixel 9: expected (13,67,100,127), got (13,67,100,255)
  Texture states were incorrect for video/webm; codecs="vp9", rendering was wrong: found 307200 differing pixels
  FAIL Texture states were incorrect for video/webm; codecs="vp9", rendering was wrong: found 307200 differing pixels


From instrumenting the test, the correct output for the upper-left corner is (13,67,100,255). It appears that occasionally the test is capturing a blank frame for the video.

The failures are happening at least for the video/webm; codecs="vp9" code path:
https://chromium-swarm.appspot.com/task?id=3ef6fd17b9038510&refresh=10&show_raw=1
https://chromium-swarm.appspot.com/task?id=3ef7125b30759f10&refresh=10&show_raw=1

and the video/webm; codecs="vp8, vorbis" code path:
https://chromium-swarm.appspot.com/task?id=3eea552e23ca8010&refresh=10&show_raw=1

I'm attempting to land a fix for this test in https://github.com/KhronosGroup/WebGL/pull/2680 which may address a race condition in the setup of the source image, but this shouldn't affect the behavior of the videos. (The test returns control to the browser before each test and in between tests.)

If you force disable chrome://flags/#enable-surfaces-for-videos do you still see this issue? CLI flag is --disable-features=UseSurfaceLayerForVideo

This might explain the last comments on issue 639174 too.

Trying specifying --disable-features=UseSurfaceLayerForVideo for the WebGL tests in:
https://chromium-review.googlesource.com/1155940

@kbr: am i correct that these tests essentially do this:

1) create video
2) wait to receive both a "playing" event and a "timeupdate" with the current time > 0 (https://cs.chromium.org/chromium/src/third_party/webgl/src/sdk/tests/js/webgl-test-utils.js?rcl=21dbf06b5aa6c7dc8cf56314d4a3f96f57956c53&l=2925)
3) pause the video, texImage2D() the current frame (https://cs.chromium.org/chromium/src/third_party/webgl/src/sdk/tests/conformance/textures/misc/tex-video-using-tex-unit-non-zero.html?rcl=21dbf06b5aa6c7dc8cf56314d4a3f96f57956c53&l=143)
4) do some js-math to decide if the resulting texture has the right stuff in it

i.e., at no time does it actually read back from the compositor, right?

@kbr: just talked to dale.  he asked if you can kick off a test with disable hw acceleration, to see if this stuff is related to frames backed by textures.

from what i now understand from that conversation, the correct sequence of events is:

1) VideoRendererImpl => PaintSingleFrame => causes VideoFrameCompositor to have a frame (so we can now capture it via "copy to platform texture".
2) "have enough" => "playing" => js tries to capture frame,

VideoFrameCompositor::PaintSingleFrame cares that it's run on the proper task runner, else it posts the call.  "proper task runner" is different for with and without UseSurfaceLayerForVideo.  an extra post might introduce a race where there wasn't before.

unfortunately, that doesn't quite explain it.  "without" makes the proper task runner use the compositor thread.  "with" makes it use the media thread. (media_factory.cc).  seems like PaintSingleFrame would post in the "without" case, since VideoRendererImpl always lives on the media thread.

i'll verify that locally.

liberato@: re: #25: essentially yes, except that the video frame is drawn to a WebGL texture and glReadPixels is done on the WebGL back buffer to get the pixels' data. The video is actually uploaded twice to WebGL textures while it's in the paused state. Sometimes the second upload is transparent black; thus 0 being averaged in to the alpha channel in the upper left corner of the image, which is why the values are 13,67,100,127 rather than 13,67,100,255. (The static image being averaged with the video frame is opaque.)

The test cases observed to fail in #22 are the vp8 and vp9 videos on Windows with NVIDIA GPUs. As I understand it these shouldn't be texture-backed?

I'm trying turning off surface layers for videos in https://chromium-review.googlesource.com/1155940 to see if that improves reliability of the test. Given other bugs in this area like  Issue 868008  and  Issue 869277 , the enabling of that feature seems like the likely root cause.

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

commit 8607ff1e36d22460d7c25735085d1dacc4a40849
Author: Kenneth Russell <kbr@chromium.org>
Date: Tue Jul 31 18:10:10 2018

Try disabling surface layers for videos in WebGL tests.

See whether passing --disable-features=UseSurfaceLayerForVideo
improves the reliability of these tests.

Tbr: kainino@chromium.org
Tbr: dalecurtis@chromium.org
Bug:  830901 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Id56d57c331ae416b5492a25609d869ebdba26ec3
Reviewed-on: https://chromium-review.googlesource.com/1155940
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579481}
[modify] https://crrev.com/8607ff1e36d22460d7c25735085d1dacc4a40849/content/test/gpu/gpu_tests/webgl_conformance_integration_test.py

Based on the symptoms of the issue, if it's related to VideoSurfaceLayer, my best guess would be that it's happening because we detect that the video is offscreen, stop submitting frames and send a dummy frame to release resources.

I will see if I can reproduce any of this to confirm.

Thanks Mounir. The test hasn't flaked on:

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Debug%20%28NVIDIA%29?limit=200
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28NVIDIA%29?limit=200

since the disable flag landed, but there haven't been many builds, either. It first landed in:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Debug%20%28NVIDIA%29/1273

See:
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/gpu/gpu_testing.md#Running-the-GPU-Tests-Locally

for details on running the WebGL conformance tests locally. Use --test-filter to run a single test or multiple tests.

So, I figured out the problem and it has actually not much to do with SurfaceLayer. The original cause is https://chromium.googlesource.com/chromium/src/+/2a7c3b2cd5c6ad903ae422d5e6ce45a123ab92ac (+xlai@) which split "ExperimentalCanvasFeatures" to various features and also moved them from "test" to "experimental". Because the WebGL conformance tests run with --experimental-web-platform-features, it meant that they started to run with these features.

Among the new feature, there is ExtraWebGLVideoTextureMetadata which will use metadata to not paint video frames when they are the same. This is actually what broke the test. If you look at the test locally, you will see that the <canvas> contains the image and the video but if you look at it with --experimental-web-platform-features the canvas only contains the image because the video frame is usually the same for the three times it's used and only painted the first time.

The reason why the test flake when surface layer are on is because sometimes two different frames are used for the vp9 video. The frames are the same but because their metadata are different (ie. different frame_id), the test ends up painting the frames for the observered case but not the expected one. I do not know if the frame update is caused by a bug but I would guess that this is exactly the cause of the flake on Android (and timing seems to confirm this).

To repro the test locally outside of the webgl conformance suite, you can run a Chrome build with "--autoplay-policy=no-user-gesture-required", run `python3 -m http.server` in chromium's root directory and open "localhost:$PORT/third_party/webgl/src/sdk/tests/conformance/textures/misc/tex-video-using-tex-unit-non-zero.html". Depending on whether chrome://flags/#enable-experimental-web-platform-features is enabled, you will see the <canvas> showing the video frame or not.

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

commit 92f861e1211607de785a905def43ebe5497bde67
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Oct 06 00:29:55 2018

Remove ExtraWebGLVideoTextureMetadata from experimental features.

This code path de-duplicates video uploads to textures, but something
is wrong with the de-duplication logic and it's causing video frames
to sometimes not be uploaded when they need to be.

The WebGL conformance tests run on the waterfall with
--enable-experimental-web-platform-features in order to exercise
some upcoming features, but this particular one must be disabled for
reliable test execution.

This experiment can be manually enabled with the command line flag
--enable-blink-features=ExtraWebGLVideoTextureMetadata .

Moved the layout test verifying this functionality into its own
virtual test suite.

Bug:  830901 
Change-Id: Ic7bc75cd71f6a8d74ce85ded6153fb9782f73eb6
Reviewed-on: https://chromium-review.googlesource.com/c/1264542
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597379}
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/NeverFixTests
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/VirtualTestSuites
[rename] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/fast/webgl/video-metadata/texImage-video-last-uploaded-metadata-expected.txt
[rename] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/fast/webgl/video-metadata/texImage-video-last-uploaded-metadata.html
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt
[add] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/virtual/webgl-extra-video-texture-metadata/fast/webgl/video-metadata/README.txt
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-dedicated-worker-expected.txt
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-shared-worker-expected.txt
[modify] https://crrev.com/92f861e1211607de785a905def43ebe5497bde67/third_party/blink/renderer/platform/runtime_enabled_features.json5

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

commit 996809f2d961c31c855c7010c3592237f5b1a49d
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Oct 13 03:00:32 2018

Unsuppress tex-video-using-tex-unit-non-zero.html.

conformance/textures/misc/tex-video-using-tex-unit-non-zero.html was flaky
because of the ExtraWebGLVideoTextureMetadata flag. Since that's no longer
being specified for the WebGL tests, this test is expected to be reliable.

Bug:  830901 
Tbr: kainino@chromium.org
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Ie3ae83d67bb47b3bfbe1db898e5fce1745b18e48
Reviewed-on: https://chromium-review.googlesource.com/c/1279430
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599478}
[modify] https://crrev.com/996809f2d961c31c855c7010c3592237f5b1a49d/content/test/gpu/gpu_tests/webgl_conformance_expectations.py

I'm not sure how to view any recent flakes of these tests on https://test-results.appspot.com/dashboards/flakiness_dashboard.html (I have a feeling the dashboard might be stale after the LUCI migration?) but there are no notifications on https://sheriff-o-matic.appspot.com/chromium.gpu.fyi . Calling this fixed.