[Webkit-unassigned] [Bug 199027] New: WKBackForwardList's current item is not reset when a back/forward navigation is preempted before a navigation policy decision is received

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199027

            Bug ID: 199027
           Summary: WKBackForwardList's current item is not reset when a
                    back/forward navigation is preempted before a
                    navigation policy decision is received
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ajuma at chromium.org
                CC: achristensen at apple.com, beidson at apple.com,
                    cdumez at apple.com, justincohen at google.com

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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190619/0ce6fbfe/attachment.html>