Define behaviour of commands in terms of unexpected navigations, content process crashes etc.

Currently, various implementations have pretty useless behaviour in face of some errors (e.g., both GeckoDriver and ChromeDriver seem to return null for execute script if the content process crashes). We should better define what implementations should do, and probably define something distinguishable from potentially correct behaviour (given null from that and null from return null; are the same!).

There's a few cases here:

• An implementation like ChromeDriver where the WebDriver end point communicates over another IPC channel to the browser itself (over CDP in that case), where there are multiple possible failure modes:

  • the CDP connection being closed (and being unable to reconnect)
  • the browser stopping responding to CDP requests (and being unable to reconnect and remake the request, if it's idempotent!)
  • the browser responding to CDP requests but the content process not responding to the browser ("Aw, snap!")

• An implementation where the browser is itself the end point (I'm not sure anyone does this any more?):

  • the end point stops responding because the browser itself has crashed
  • the content process isn't responding

• An intermediary node losing its connection to the end point.

These are all general connectivity problems where the local end can still communicate with the first remote end, so we should define something here, as we still have a working WebDriver connection.

Start by reviewing the WebDriver specification and the failure modes listed here: closed or unresponsive CDP connections, crashed browsers or content processes, and disconnected intermediary nodes. Done means the specification defines distinguishable behavior for these connectivity failures without conflating it with valid command results.