Bug 237071 – Call WKNavigationDelegate.didFailProvisionalNavigation even after a cross-origin navigation with COOP

• Component: New Bugs
• Status: RESOLVED FIXED

[Alex Christensen]

Call WKNavigationDelegate.didFailProvisionalNavigation even after a cross-origin navigation with COOP

[Alex Christensen]

Created attachment 452928 [details]
Patch

[Chris Dumez]

I will be a little surprised if the ProcessSwap.ResponsePolicyDownloadAfterCOOPProcessSwap API test still passes.

I added this check not long to fix a bug and added that API test to cover the change (see Bug 233798)

[Chris Dumez]

Comment on attachment 452928 [details]
Patch

No API test failures, things must have changed since this check was added.

[EWS]

Committed r290371 (247687@main): <https://commits.webkit.org/247687@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 452928 [details].

[Radar WebKit Bug Importer]

<rdar://problem/89354367>

[Alex Christensen]

Reverted in r290493

[Alex Christensen]

*** Bug 237105 has been marked as a duplicate of this bug. ***

[Chris Dumez]

So here is what's happening:
1. We navigate to https://webkit.org/path1 in Process A
2. We request a navigation to https://example.com/path3.
3. Because the navigation is cross-site, PSON triggers and starts a provisional load in Process B AND tells Process A to stop all loads (no more provisional load going on in Process A).
4. When we receive the response for https://example.com/path3, the COOP header is present is triggers yet another process swap to process C.
5. We start a provisional load in process C and Process B actually goes away because it is associated with a ProvisionalPageProxy and the WebPageProxy can only have one ProvisionalPageProxy at any point, and we are constructing a new ProvisionalPageProxy for process C.
6. So at this point, we only have committed Process A and provisional Process C. There is no longer a provisional load going on in Process A (it was going on in Process B which was canceled before it got committed).
6. Then the client blocks the navigation via DecidePolicyForNavigationResponse which causes the ProvisionalPageProxy to go away. Normally, destroying the ProvisionalPageProxy would stop the provisional load in the committed process and cause a didFailProvisionalLoad to get sent to the client. However, in this case, it is not happening since there is no longer a provisional load going on in Process A (because PSON and the provisional load to process B messed with that).

I am looking into how to best fix this.

[Chris Dumez]

Created attachment 453223 [details]
Patch

[Chris Dumez]

Comment on attachment 453223 [details]
Patch

Looks like I messed up something. Will investigate.

[Chris Dumez]

Created attachment 453252 [details]
Patch

[Darin Adler]

Comment on attachment 453252 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=453252&action=review

> Source/WebKit/WebProcess/WebPage/WebPage.cpp:1839
> +    SetForScope<bool> isStoppingLoadingDueToProcessSwap(m_isStoppingLoadingDueToProcessSwap, true);

Do we still need to write <bool>? If so, maybe we should add deduction guides so we don’t.

[EWS]

Committed r290563 (247841@main): <https://commits.webkit.org/247841@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 453252 [details].

[Chris Dumez]

(In reply to Darin Adler from comment #12)
> Comment on attachment 453252 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=453252&action=review
> 
> > Source/WebKit/WebProcess/WebPage/WebPage.cpp:1839
> > +    SetForScope<bool> isStoppingLoadingDueToProcessSwap(m_isStoppingLoadingDueToProcessSwap, true);
> 
> Do we still need to write <bool>? If so, maybe we should add deduction
> guides so we don’t.

No we don't. Following up in Bug 237258.