FrameLoader::continueLoadAfterNavigationPolicy has logic to reset the current item when we received an IgnoreLoad navigation policy decision for a back/forward navigation (since the current item has already been updated to the destination of the back/forward navigation by that point). However, if a navigation is preempted by another non-back/forward navigation before a navigation policy decision is received (say by JS setting a new document.location), then FrameLoader::loadWithDocumentLoader (for the new navigation) sets the PolicyChecker's load type to something non-back/forward (e.g. FrameLoadType::Standard) before calling PolicyChecker::stopCheck, so FrameLoader::continueLoadAfterNavigationPolicy doesn't reset the current item. This means that until something else updates the current item, it's stuck on the destination of the now-cancelled back/forward navigation. That is, in the following sequence: 1) Trigger a back/forward navigation A 2) Call document.location = ... before a navigation policy decision is received for A After step (2), the current item is still the destination of A until the navigation triggered in (2) commits. Is this the expected behavior? For navigations that fail after navigation policy (but before commit), we intentionally do not reset the current item if there's another provisional navigation in progress (see FrameLoader::checkLoadCompleteForThisFrame).