[webkit-changes] [WebKit/WebKit] 546db3: [iOS 17+, Sonoma] REGRESSION (267051 at main): Safari...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 546db343245acbd1394972e65da6c9056fe3b166
      https://github.com/WebKit/WebKit/commit/546db343245acbd1394972e65da6c9056fe3b166
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-08-22 (Tue, 22 Aug 2023)

  Changed paths:
    M Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.h
    M Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.mm

  Log Message:
  -----------
  [iOS 17+, Sonoma] REGRESSION (267051 at main): Safari no longer responds to WebPrivacy list changes
https://bugs.webkit.org/show_bug.cgi?id=260569
rdar://114288616

Reviewed by Aditya Keerthi.

Several API tests in `TestWebKitAPI.AdvancedPrivacyProtections` began to fail after the changes in
267051 at main; in particular, they're failing because I changed the `SOFT_LINK_CONSTANT_FOR_HEADER`
around `WPNotificationUserInfoResourceTypeKey` to `SOFT_LINK_CONSTANT_MAY_FAIL_FOR_HEADER`, the
latter of which never attempts to load will return `nil` unless we call
`PAL::canLoad_WebPrivacy_WPResourceDataChangedNotificationName()` first (the full macro expands to
the following):

```
namespace PAL {

static NSNotificationName constantWebPrivacyWPResourceDataChangedNotificationName;

bool init_WebPrivacy_WPResourceDataChangedNotificationName();
bool init_WebPrivacy_WPResourceDataChangedNotificationName()
{
    void* constant = dlsym(WebPrivacyLibrary(), "WPResourceDataChangedNotificationName");
    if (!constant)
        return false;
    constantWebPrivacyWPResourceDataChangedNotificationName = *static_cast<NSNotificationName const *>(constant);
    return true;
}

PAL_EXPORT bool canLoad_WebPrivacy_WPResourceDataChangedNotificationName();
bool canLoad_WebPrivacy_WPResourceDataChangedNotificationName()
{
    static bool loaded = init_WebPrivacy_WPResourceDataChangedNotificationName();
    return loaded;
}

PAL_EXPORT NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName();
NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName()
{
    return constantWebPrivacyWPResourceDataChangedNotificationName;
}

}
```

...in contrast, the original macro `SOFT_LINK_CONSTANT_FOR_HEADER` expands to:

```
namespace PAL {

PAL_EXPORT NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName();
NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName()
{
    static NSNotificationName constantWebPrivacyWPResourceDataChangedNotificationName;
    static dispatch_once_t once;
    dispatch_once(&once, ^{
        void* constant = dlsym(WebPrivacyLibrary(), "WPResourceDataChangedNotificationName");
        RELEASE_ASSERT_WITH_MESSAGE(constant, "%s", dlerror());
        constantWebPrivacyWPResourceDataChangedNotificationName = *static_cast<NSNotificationName const *>(constant);
    });
    return constantWebPrivacyWPResourceDataChangedNotificationName;
}

}
```

This exposes a real bug caused by 267051 at main, where we no longer listen for the resource data
changed notification from WebPrivacy in WebKit since the soft-linking helper now always returns
`nil`. Fix this by reverting to the original `SOFT_LINK_CONSTANT_FOR_HEADER` for these two symbols,
which should be fine (i.e. not `RELEASE_ASSERT`) as long as we only ever call them from inside a
`canUseWebPrivacyFramework()` check.

* Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.h:
* Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.mm:

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