Connect to Chrome Remote Interface when launching Chrome and record video

[bahmutov]

• closes Add and control Chrome Debugging Protocol #4608
• partial solution to Support video capture in browsers other than headless electron  #1767 (Headed Chrome browser only)
• connect and return websocket url (we will ignore the HTTP url for now, but in the future it could be used to directly return browser information to Node)
• first connect to about:blank, grab the RDI object, then connect to the real url so we have connection (for future logging and video frames) from the very beginning
• pass the websocket url as a config value to the browser (see note below)
• tests
• if ffmpeg video encoding fails for any reason, for example if the browser has sent no frames and there is zero length file to encode, we silently ignore the error, and the user has no idea why there is no video. We should show a warning on non-exit ffmpeg exit code and show STDERR

decision: do not store the references for this PR, it will be decided later when using them

• do not use domain objects to communicate with remote interface, instead use client.send("command name", ...) format.
• look into using frame timestamps when writing video rather than wallclock timestamps. Looked, could not figure it if possible at all, asked a question on fluent-ffmpeg repo.

More information

If you need to execute a command via this interface, see CRI API

const CRI = require('chrome-remote-interface')
const client = await CRI({
   target: wsUrl,
   local: true,
})
.timeout(2000)
await client.send('Page.navigate', {url: 'https://github.com'})

• to see verbose CDP messages use DEBUG=cy-verbose:server:browsers:cri-client namespace (starts with cy-verbose to avoid flooding DEBUG=cypress* namespace)

[bahmutov]

The order of launching the browser and visiting the site should be (for example for recording video)

1. spawn chrome on about:blank (remove the url argument)
2. connect to the debugger protocol / resolve with wsUrl
3. have node connect to wsUrl and start receiving frames and write them to the ffmpeg stream
4. navigate the browser to the original URL which is the http://localhost:<port>/__/<spec> via the debugger protocol commands

[bahmutov]

Trying locally against cypress-test-tiny using Chrome Canary

DEBUG=cypress:server:protocol npm run dev -- --project ~/git/cypress-test-tiny

or for just a run

DEBUG=cypress:server:protocol,cypress:server:browsers \
npm run dev -- --run-project ~/git/cypress-test-tiny --browser chrome

[bahmutov]

problematic tests (driver integration)

• e2e/focus_blur_spec.js
• issues/1939_1940_2190_spec.js

example build https://circleci.com/gh/cypress-io/cypress/135766

[bahmutov]

Interesting: when launching the Chrome browser with url, the focus stays on the new browser tab and our focus tests pass ('can intercept blur/focus events' in focus_blur_spec.js)

When launching blank page, then directing to url using CRI, the focus goes away from the new tab

[brian-mann]

• I would like to see us use a dynamic port for the --remote-debugging-port CLI flag and not a hard coded constant. This will conflict if any other automation tools are already using it. There are NPM packages out there already (or you can use the built in node http server) to figure out an open port. The easiest way is to spawn an HTTP server without passing port (it will pick an open one by default) - capture that and then close the HTTP server.

Question:

Is there a reason why we're using the abstractions around the Page.* objects? I would prefer we use the lower level client.send('Domain.method', ...) because that maps directly to the actual RDP documentation - and it's much clearer how the implementation is actually working.

If perhaps the abstraction provides a certain level of gain or backwards compatibility that would be compelling but I'd like to understand what it's doing under the hood first before adopting that pattern.

[brian-mann]

• increase _getDelayMsForRetry to 5000ms
• add a test in run_spec.coffee verifying that the right error is thrown when it cannot be connected to
• create a nice error message for the user so they understand what happened and why we threw

[flotwig]

* increase `_getDelayMsForRetry` to 5000ms

* add a test in `run_spec.coffee` verifying that the right error is thrown when it cannot be connected to

* create a nice error message for the user so they understand what happened and why we threw

Added all of this, but instead of adding a test in run_spec, I opted to add an e2e test instead that strips the remote-debugging-port CLI arg to ensure the connection fails. This was simpler than mocking out everything that happens between run.coffee and chrome.coffee and should be easier to maintain since less is stubbed.