Bug 205087 – [macOS] Issue load sooner on swipe back/forward navigation

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Chris Dumez]

Issue load sooner on swipe back/forward navigation on macOS. We currently wait until the end of the swipe animation to issue the load but we should be able to start loading as soon as the user lifts the finger and thus commits to navigating. This will improve perceived performance on swipe back/forward navigation.

[Chris Dumez]

Created attachment 385310 [details]
Patch

[Chris Dumez]

<rdar://problem/57809587>

[Tim Horton]

Comment on attachment 385310 [details]
Patch

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

> Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:148
> +    if (m_page.isLayerTreeFrozenDueToSwipeAnimation())
> +        send(Messages::WebPage::FreezeLayerTreeDueToSwipeAnimation());

Should we just stuff this in the creation parameters? Then there's no race.

[Chris Dumez]

Comment on attachment 385310 [details]
Patch

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

>> Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:148
>> +        send(Messages::WebPage::FreezeLayerTreeDueToSwipeAnimation());
> 
> Should we just stuff this in the creation parameters? Then there's no race.

We need a separate IPC for the non-PSON case anyway. I do not think this is racy here because we're process-swapping here and the tree will already be be frozen with ProcessSwap reason until WebPage::didCompletePageTransition() is called. As long as I sent the FreezeLayerTreeDueToSwipeAnimation IPC before the IPC triggering the load, I do not think there is a race.

[WebKit Commit Bot]

Comment on attachment 385310 [details]
Patch

Clearing flags on attachment: 385310

Committed r253360: <https://trac.webkit.org/changeset/253360>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.