Bug 323444 – [WebDriver] Ensure classic commands on a given session are queued during execution

• Status: RESOLVED
• Resolution: FIXED
• Component: WebDriver

[Lauro Moura]

Currently, the code in Source/WebDriver does not explicitly enqueue the incoming WebDriver classic commands for a given session, a behavior required by the spec's processing model[1]: 

> Enqueue a task on remote end's request queue to run the following steps: 
>     (steps for session validation, request parsing, etc)
>     (wait for navigation to complete)
>     (run actual command)
>     (error and reply steps)

As we do not enforce such queue, this opens the door to have effectively concurrent commands running at a given time. For example, this happened in a downstream test suite where a regular heartbeat command arrived while a slow/stuck command was still pending. The slow operation widened the window for such race, but this can happen during normal operation too.

This should be fixed because running commands in parallel can break a number of invariants within the WebDriver classic implementation. For example, current browsing context tracking within Session.cpp, waitForNavigationToComplete callbacks and timers, etc. These lead to failures like indefinite hangs, often requiring to restart both the driver and the browser. In fact, `waitForNavigationToCompleteOnPage` already has `ASSERT(!m_loadTimer.isActive())`

Note that Session-less commands like `/status` and `POST /session` (new session) are free to run unqueued.

[1] https://www.w3.org/TR/webdriver2/#processing-model

[Radar WebKit Bug Importer]

<rdar://problem/187215746>

[Lauro Moura]

Pull request: https://github.com/WebKit/WebKit/pull/75103

[EWS]

Committed 322485@main (87c1e2d36d8e): <https://commits.webkit.org/322485@main>

Reviewed commits have been landed. Closing PR #75103 and removing active labels.