Bug 196875 – REGRESSION (r244182): inspector/canvas/recording-webgl-snapshots.html became flaky on WK1

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Said Abou-Hallawa]

This a followup bug for https://trac.webkit.org/changeset/244182 which caused this test to be flaky on WK1.

[Radar WebKit Bug Importer]

<rdar://problem/49873252>

[Shawn Roberts]

Marked flaky in https://trac.webkit.org/changeset/244263/webkit while waiting for a fix.

[Devin Rousso]

So here's how all of the inspector/canvas/recording-<type>.html tests work:

1. create a canvas and get the context for <type>
2. start recording the context
    - note that the started recording can have options, such as a `frameLimit` (controls how many "frames" (e.g. when the <canvas> paints) to record before _automatically_ stopping the recording from the backend)
3. perform some actions
    - depending on the test, the actions can span multiple `setTimeout` or `requestAnimationFrame`
    - based on `frameLimit`, some or all of those actions will be recorded
4. wait for either the inspector backend to _automatically_ stop the recording (from `frameLimit`) OR the test page itself to say "all done" (this is the `LastFrame` event)
5a. if `LastFrame` is dispatched _before_  the recording has ended (e.g. no `frameLimit`), the inspector frontend itself will then stop the recording
5b. if `LastFrame` is dispatched _after_  the recording has ended (e.g. a specified `frameLimit`), the inspector frontend won't attempt to "re-stop" the recording, as that would throw an error ("No active recording for canvas")
6. process the recording data and compare with the expected results

The issue with this test looks like it's in step 5a.  Due to the fact that all messages between the inspector frontend and inspector backend are async, it's possible for the inspector backend to automatically stop the recording and dispatch a message to the inspector frontend, only for it to be received _after_ `LastFrame`, meaning that the inspector frontend doesn't yet know about the fact that the recording had already been stopped.

A solution to this is to just not set a `frameCount` for "shorter" recording tests like this, as the timing is too "close" when running in debug.

This isn't an issue when using Web Inspector "normally" (e.g. not in a test), because the inspector frontend UI will "ignore" these types of errors, not to mention it would be MUCH harder for a person to get the timing just right to even encounter this situation.

[Devin Rousso]

Created attachment 370706 [details]
Patch

[Said Abou-Hallawa]

Comment on attachment 370706 [details]
Patch

Can you please remove the test from LayoutTests/platform/mac/TestExpectations? It was marked flaky r244263.

[Devin Rousso]

Created attachment 370754 [details]
Patch

[EWS Watchlist]

Comment on attachment 370754 [details]
Patch

Attachment 370754 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/12309450

New failing tests:
webgl/2.0.0/conformance/textures/misc/origin-clean-conformance.html

[EWS Watchlist]

Created attachment 370771 [details]
Archive of layout-test-results from ews117 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[WebKit Commit Bot]

Comment on attachment 370754 [details]
Patch

Clearing flags on attachment: 370754

Committed r245821: <https://trac.webkit.org/changeset/245821>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.