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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=196875

Devin Rousso <drousso at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drousso at apple.com

--- Comment #3 from Devin Rousso <drousso at apple.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190527/5291a588/attachment-0001.html>