With the Firefox implementation, trying to send commands during a navigation will often result in an internal exception being thrown (AbortError). This is typically the case when the underlying context is destroyed by the navigation before it could handle whatever the command needed.
I think Chrome has similar errors when the browsing context becomes unavailable while the command is processed.
Could we agree on a standard error when a command needs to be aborted?
It can be useful for polling patterns for instance (used at least by puppeteer).
The Browser Testing and Tools Working Group just discussed Standardize errors thrown when a command needs to be aborted (GitHub issue).
The full IRC log of that discussion
<jgraham_> Topic: Standardize errors thrown when a command needs to be aborted (GitHub issue)
<orkon> jgraham_ (IRC): lets discuss on the PR, it sounds like PR could be landed.
<jgraham_> github: https://github.com/w3c/webdriver-bidi/issues/540
<orkon> whimboo: there are problems with Puppeteer: how should we handle commands that are interrupted? For example, script evaluation can be interruped by a navigation. For those cases we don't have anything in the spec and it would be great to have a specific error
<orkon> whimboo: so that the client can decide on the abort error what to do with the command
<jgraham_> q?
<orkon> whimboo: right not it is not possible for the client to have a correct behaviour
<orkon> q?
<jgraham_> q+
<orkon> jgraham_ (IRC): I agree we need this. From the spec point of view it is a bit tricky. I guess what we need a generic handler in the spec that if unload handler is invoked, then each running command is abort. Except maybe navigation commands because it should not be aborted. To begin with we could put a vague wording.
<gsnedders> q+
<gsnedders> ack
<jgraham_> ack next
<orkon> jgraham_ (IRC): we should have a DocumentNavigated error to know that the command was aborted
<jgraham_> ack gsnedders
<orkon> Sam Sneddon [:gsnedders]: we cannot use the unload handler because the unload handler can be cancelled in some circumtances.
<orkon> jgraham_ (IRC): I was thinking in the spec terms to be after there is no possibility to cancel the unload
<orkon> jgraham_ (IRC): in gecko we get a notification that a context is being destroyed
<orkon> Sam Sneddon [:gsnedders]: I think the complexity will be on how to spec this
With the Firefox implementation, trying to send commands during a navigation will often result in an internal exception being thrown (AbortError). This is typically the case when the underlying context is destroyed by the navigation before it could handle whatever the command needed.
I think Chrome has similar errors when the browsing context becomes unavailable while the command is processed.
Could we agree on a standard error when a command needs to be aborted? It can be useful for polling patterns for instance (used at least by puppeteer).