[webkit-changes] [WebKit/WebKit] 075cc1: WKWebView sometimes allows app links to open when ...

[David Quesada]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 075cc18c58a3ebdd1074093a5dae9dc483cf6b91
      https://github.com/WebKit/WebKit/commit/075cc18c58a3ebdd1074093a5dae9dc483cf6b91
  Author: David Quesada <david_quesada at apple.com>
  Date:   2025-02-22 (Sat, 22 Feb 2025)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Tools/TestWebKitAPI/SourcesCocoa.txt
    M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
    A Tools/TestWebKitAPI/Tests/WebKitCocoa/ShouldOpenAppLinks.mm

  Log Message:
  -----------
  WKWebView sometimes allows app links to open when reloading after a web process crash
https://bugs.webkit.org/show_bug.cgi?id=288159
rdar://141515904

Reviewed by Alex Christensen.

In some cases, reloading the web view after a web process crash can result in the
WKWebView opening the current URL as an app link and punching out to the app, which
can be quite annoying for the user. Ordinarily, web view reloads arent't be eligible
for opening app links because doing so requires that the navigation is from one host
to a different one. But when performing a reload after a web process crash, the main
frame's URL has been reset to null after the process termination, and having a null
URL technically satisifies the different-host requirement because the previously
loaded URL's host is *anything except null*.

Prevent these unexpected app launches by adding a requirement that `shouldOpenAppLinks`
can only be true when the main frame's URL is non-null, since opening app links
automatically only makes sense when there is actual content loaded in the web view
that the user might have explicitly interacted with. An exception to this requirement
is made if the web view has never committed any provisional navigations, as is the
case when one web view opens another to a URL that ends up resolving to an app link.

* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::decidePolicyForNavigationAction):
    Implement the aforementioned check.
* Tools/TestWebKitAPI/SourcesCocoa.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ShouldOpenAppLinks.mm: Added.
(-[ShouldOpenAppLinksTestNavigationDelegate init]):
    Set up a navigation delegate for the tests that retains the most recent
    WKNavigationAction and reloads the web view on web process crash. Manually
    performing this reload is necessary because the WebPageProxy doesn't internally
    do this reload itself if the crash was requested by the client.
(shouldOpenAppLinksTestServer):
(TEST(ShouldOpenAppLinks, DisallowAppLinksWhenReloadingAfterWebProcessCrash)):
(TEST(ShouldOpenAppLinks, DisallowAppLinksWhenReloadingAfterWebProcessCrashAfterFollowingLink)):
    Verify that WKNavigationAction._shouldOpenAppLinks (which reflects the same
    underlying effective policy that WebKit internally uses to decide whether to
    try opening URLs as app links) is false when deciding the navigatiom policy
    for a reload being performed after a web process crash. Add a distinct test
    case for the case where the web view has been navigated by the user clicking
    a link. In that case, unlike the first, it appears the user-initiated nature
    of the navigation to a second page attaches a policy of
    ShouldOpenExternalURLsPolicy::ShouldAllow to the HistoryItem being reloaded,
    which was previously allowing `shouldOpenAppLinks` to evaluate to true.

Canonical link: https://commits.webkit.org/290885@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications