This a followup bug for https://trac.webkit.org/changeset/244182 which caused this test to be flaky on WK1.
<rdar://problem/49873252>
Marked flaky in https://trac.webkit.org/changeset/244263/webkit while waiting for a fix.
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.
Created attachment 370706 [details] Patch
Comment on attachment 370706 [details] Patch Can you please remove the test from LayoutTests/platform/mac/TestExpectations? It was marked flaky r244263.
Created attachment 370754 [details] Patch
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
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
Comment on attachment 370754 [details] Patch Clearing flags on attachment: 370754 Committed r245821: <https://trac.webkit.org/changeset/245821>
All reviewed patches have been landed. Closing bug.