When the stack is not-empty for a navigation, e.g. because it's caused by navigation.navigate(), we end up with
URL and history update steps
Update the entries
Notify about the committed-to-entry: resolves the committed promise
Fire currententrychange
Run intercept() handlers
Eventually, stack is empty, so the committed promise handlers run
i.e. the result is currententrychange -> intercept() handlers -> committed promise handlers.
When the stack is empty for a navigation, e.g. because it's caused by users clicking on <a>s or it's a traversal (which requires an in-parallel + queue a task round trip), then we have:
URL and history update steps
Update the entries
Notify about the committed-to-entry: resolves the committed promise
Fire currententrychange.
If any event lists are run, then after they run the stack becomes empty, so the committed promise handlers run.
Run intercept() handlers
The stack is now empty again, so if the committed promise handlers weren't run before, then they will be now.
i.e. the result is either currententrychange -> committed promise handlers -> intercept() handlers, or currententrychange -> intercept() handlers -> committed promise handlers, depending on whether or not currententrychange has any listeners.
This is weird and should probably be avoided. We should have the order be either currententrychange -> committed promise handlers -> intercept() handlers consistently, or currententrychange -> intercept() handlers -> committed promise handlers consistently.
When the stack is not-empty for a navigation, e.g. because it's caused by
navigation.navigate(), we end up withcommittedpromisecurrententrychangeintercept()handlerscommittedpromise handlers runi.e. the result is
currententrychange->intercept()handlers ->committedpromise handlers.When the stack is empty for a navigation, e.g. because it's caused by users clicking on
<a>s or it's a traversal (which requires an in-parallel + queue a task round trip), then we have:committedpromisecurrententrychange.committedpromise handlers run.intercept()handlerscommittedpromise handlers weren't run before, then they will be now.i.e. the result is either
currententrychange->committedpromise handlers ->intercept()handlers, orcurrententrychange->intercept()handlers ->committedpromise handlers, depending on whether or notcurrententrychangehas any listeners.This is weird and should probably be avoided. We should have the order be either
currententrychange->committedpromise handlers ->intercept()handlers consistently, orcurrententrychange->intercept()handlers ->committedpromise handlers consistently.