Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.

This test has been failing intermittently for some weeks, on Android and Linux. On June 19, failure frequency increased significantly, on linux64-qr. This increase in qr failures seems to correspond to the landing in bug 1339474. Failures typically look like this: [task 2017-06-22T00:43:15.623404Z] 00:43:15 INFO - TEST-PASS | dom/canvas/test/webgl-mochitest/test_capture.html | vmanual should become red after requestFrame() [task 2017-06-22T00:43:15.624332Z] 00:43:15 INFO - Checking that requestFrame() immediately after a draw call results in the expected frame seen in the stream. [task 2017-06-22T00:43:15.625229Z] 00:43:15 INFO - Waiting for video vmanual to match [255,0,0,255] - red (should still be red) [task 2017-06-22T00:43:15.626544Z] 00:43:15 INFO - Frame: 0 IsPixel ref=255,0,0,255 threshold=0 value=255,0,0,255 [task 2017-06-22T00:43:15.627840Z] 00:43:15 INFO - TEST-PASS | dom/canvas/test/webgl-mochitest/test_capture.html | vmanual should still be red [task 2017-06-22T00:43:15.629472Z] 00:43:15 INFO - WebGL: drawArrays(green) [task 2017-06-22T00:43:15.632822Z] 00:43:15 INFO - Requesting frame from vmanual [task 2017-06-22T00:43:15.634219Z] 00:43:15 INFO - Waiting for video vmanual to match [0,255,0,255] - green (should become green after call order test) [task 2017-06-22T00:43:15.635696Z] 00:43:15 INFO - WebGL: clearColor(red) [task 2017-06-22T00:43:15.636881Z] 00:43:15 INFO - Frame: 0 IsPixel ref=0,255,0,255 threshold=0 value=255,0,0,255 [task 2017-06-22T00:43:15.638387Z] 00:43:15 INFO - Buffered messages finished [task 2017-06-22T00:43:15.639600Z] 00:43:15 INFO - TEST-UNEXPECTED-FAIL | dom/canvas/test/webgl-mochitest/test_capture.html | Test timed out. :kats - Does that make sense to you? Anything you can do?

I can investigate. I'm not familiar with the test and it's not obvious to me what the connection would be. But it's quite possible that turning on APZ might have caused this spike by exacerbating an existing race condition or something.

In some cases it looks like the log is almost completely filled with this output: WARN:webrender::clip_scroll_node: Tried to scroll a non-scroll node. which is probably slowing the test down enough to time it out. At any rate we should fix the source of the warning and see if it helps any. In other cases I see a lot of this in the log: Error: WebGL warning: Exceeded 16 live WebGL contexts for this principal, losing the least recently used one.

The patch in bug 1375843 should reduce the linux64-qr failure rate. I'm not sure if the second warning I noted in comment 69 is relevant but I'll keep this assigned to me and investigate more if the failure rate doesn't go back down to its previous levels.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #71) > The patch in bug 1375843 should reduce the linux64-qr failure rate. I'm not sure of the failure rate yet, but there are still linux64-qr failures after bug 1375843: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-central&job_id=109864407

It's still failing fairly frequently. I'll investigate.

I think I know what's going on, I filed bug 1376449 with details and I'll test my fix over there.

Looks like the fix from bug 1376449 put an end to the linux64-qr failures on this bug. It won't help with the android ones because those are actually on a different test (dom/canvas/test/test_capture.html for android vs. dom/canvas/test/webgl-mochitest/test_capture.html for linux64-qr). So I'll leave this bug open to track the android failures which will probably persist.