Repository navigation
Handle the case where a navigation happens during script execution #1708
Description
Let completion be Function.[[Call]](window, parameters) with function as the this value.
During this step a navigation can happen which will prevent the function completing and so prevent the command ever returning. For async scripts the situation is even worse because the navigation can occur any time before the completion callback is called.
We should explicitly state somewhere that if the browsing context becomes inactive during script execution then we respond with a Javascript Error (or maybe No Such Window?)
Activity
css-meeting-bot commentedon Feb 8, 2023
The Browser Testing and Tools Working Group just discussed
Classic: Handle cases where a navigation happens during script execution.The full IRC log of that discussion
<jgraham> Topic: Classic: Handle cases where a navigation happens during script execution<jgraham> Github: https://github.com//issues/1708
<sadym> q+
<jgraham> ack sadym
<orkon> whimboo: we currently have no way to fail gracefully and a navigation happens. In prompts, we raise an error. in navigation, we don't have anything useful. But we don't know what we should do in this case. Is raising a JS good? or some other way to indicate that the script was aborted
<simons> q+
<jgraham> ack simons
<orkon> sadym (IRC): what is the use case for that? so technically the user can handle this use case by themselves. Is there an example where it cannot be handled on the user side?
<patrickangle_> +1 for
<jgraham> q+
<orkon> simons: this case here that the js has not actually executed. And potentially for an async script that might wait indefinitely. There is nothing wrong with the js here but the window is gone. Either solution is good: js error or other error
<jgraham> ack jgraham
<whimboo> q+
<sadym> q+
<orkon> jgraham (IRC): typical example is a buggy case that causes a nav before results are sent back. We need to define how we handle it for correctnes..
<jgraham> ack whimboo
<orkon> s/correctnes../correctness./
<jgraham> I think I prefer JavascriptError, just because I expect clients to handle it somehow, even though technically no such window is providing more information
<orkon> whimboo: which error type to use? for prompts with use a js error. Should we keep using? Or should we have a new failure here? how will clients handle it if smth aborts?
<jgraham> ack sadym
<orkon> sadym (IRC): sending an error with no window sounds good. But when will the exception happen?
<orkon> jgraham (IRC): in classic there is a navigation event and it would be right to handle it as part of the unload handler
<jgraham> q?
<whimboo> q+
<orkon> whimboo: should we also have something similar in bidi?
<orkon> jgraham (IRC): technically the bidi client can handle unresolved promises but perhaps it should be rejected on navigation
<orkon> whimboo: should we file a separate issue for bidi?
<orkon> whimboo: AI: to file an issue
<jgraham> action: whimboo to file a BiDi issue covering this scenario