[Webkit-unassigned] [Bug 229769] [ BigSur arm64 Debug EWS ] ASSERTION FAILED: m_uncommittedState.state == State::Provisional

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Chris Dumez <cdumez at apple.com> ---
I really wish I was able to reproduce this. Based on the crash trace, we can tell the UIProcess is crashing when committing the load in the new process, after a process-swap. It is impossible to tell if the process-swap was due to PSON or COOP but since this is a recent regression, COOP may be more likely.

The reason we hit the assertion is that the WebPageProxy doesn't think a provisional load is going on when the load gets committed. This could be because:
1. The UIProcess did not receive the DidStartProvisionalLoad IPC before the DidCommitLoad IPC
2. The UIProcess got a DidFailProvisionalLoad IPC before the DidCommitLoad IPC
3. PageLoadState::reset() was called between the DidStartProvisionalLoad IPC and the DidCommitLoad IPC

The expected behavior when doing a COOP process-swap is:
1. Process A sends a DidStartProvisionalLoad IPC to the UIProcess
2. Process A send DecidePolicyForResponse IPC to the UIProcess and we decide to process-swap due to COOP header
3. The UIProcess responds with PolicyAction::Ignore for the DecidePolicyForResponse IPC to Process A. This causes process A to send back a DidFailProvisionalLoad IPC but it gets ignored in WebPageProxy::didFailProvisionalLoadForFrame() (early return).
4. The UIProcess launches a new Process B and creates a ProvisionalPageProxy and starts the load in this new process / page.
5. Process B doesn't send a DidStartProvisionalLoad IPC to the UIProcess because we have a check in WebPageLoadClient::didStartProvisionalLoadForFrame() and we are continuing a load after the response policy.
6. Process B sends a DidCommitLoad IPC to the UIProcess.

At step 6, the UIProcess should be in provisional load state since it got a DidStartProvisionalLoad from process A and nothing should have changed the state in between. This works in general and we have API tests covering this. However, something seems to go wrong in the layout tests in some cases.

-- 
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/20210901/388bcfbb/attachment.htm>