Title: [262448] branches/safari-610.1.15-branch/Source/WebKit
- Revision
- 262448
- Author
- [email protected]
- Date
- 2020-06-02 14:58:17 -0700 (Tue, 02 Jun 2020)
Log Message
Cherry-pick r262427. rdar://problem/63891546
REGRESSION (r258949): Dynamic user accent color changes are not respected by WKWebView
https://bugs.webkit.org/show_bug.cgi?id=212628
<rdar://problem/63436275>
Reviewed by Per Arne Vollan.
Two issues with the "CFPrefs Direct Mode" mechanism caused dynamic changes to the
user accent color preference to not be respected anymore:
- the default change, when synchronized to the Web Content process, was
written into the wrong domain, because of bug 212627.
- AppKit caches the resolved accent color; the cache is invalidated when the
a CoreUI notification is posted. Since we synchronize preferences ourselves,
the ordering of the default change and notification are no longer guaranteed,
so AppKit sometimes reads and re-caches the old accent color.
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::userAccentColorPreferenceKey):
(WebKit::shouldWriteToAppDomainForPreferenceKey):
(WebKit::WebProcess::notifyPreferencesChanged):
To fix the first problem, write the default into the standardUserDefaults.
This is just a workaround, we need a more general solution to this problem
for all global preferences. We know it's OK in this case, because AppKit
happens to read from standardUserDefaults.
(WebKit::dispatchSimulatedNotificationsForPreferenceChange):
To fix the second problem, re-emit the notification once we have synchronized
the preference to the Web Content process.
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262427 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Modified Paths
Diff
Modified: branches/safari-610.1.15-branch/Source/WebKit/ChangeLog (262447 => 262448)
--- branches/safari-610.1.15-branch/Source/WebKit/ChangeLog 2020-06-02 21:58:15 UTC (rev 262447)
+++ branches/safari-610.1.15-branch/Source/WebKit/ChangeLog 2020-06-02 21:58:17 UTC (rev 262448)
@@ -1,5 +1,74 @@
2020-06-02 Alan Coon <[email protected]>
+ Cherry-pick r262427. rdar://problem/63891546
+
+ REGRESSION (r258949): Dynamic user accent color changes are not respected by WKWebView
+ https://bugs.webkit.org/show_bug.cgi?id=212628
+ <rdar://problem/63436275>
+
+ Reviewed by Per Arne Vollan.
+
+ Two issues with the "CFPrefs Direct Mode" mechanism caused dynamic changes to the
+ user accent color preference to not be respected anymore:
+
+ - the default change, when synchronized to the Web Content process, was
+ written into the wrong domain, because of bug 212627.
+
+ - AppKit caches the resolved accent color; the cache is invalidated when the
+ a CoreUI notification is posted. Since we synchronize preferences ourselves,
+ the ordering of the default change and notification are no longer guaranteed,
+ so AppKit sometimes reads and re-caches the old accent color.
+
+ * WebProcess/cocoa/WebProcessCocoa.mm:
+ (WebKit::userAccentColorPreferenceKey):
+ (WebKit::shouldWriteToAppDomainForPreferenceKey):
+ (WebKit::WebProcess::notifyPreferencesChanged):
+ To fix the first problem, write the default into the standardUserDefaults.
+ This is just a workaround, we need a more general solution to this problem
+ for all global preferences. We know it's OK in this case, because AppKit
+ happens to read from standardUserDefaults.
+
+ (WebKit::dispatchSimulatedNotificationsForPreferenceChange):
+ To fix the second problem, re-emit the notification once we have synchronized
+ the preference to the Web Content process.
+
+
+ git-svn-id: https://svn.webkit.org/repository/webkit/trunk@262427 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+ 2020-06-02 Tim Horton <[email protected]>
+
+ REGRESSION (r258949): Dynamic user accent color changes are not respected by WKWebView
+ https://bugs.webkit.org/show_bug.cgi?id=212628
+ <rdar://problem/63436275>
+
+ Reviewed by Per Arne Vollan.
+
+ Two issues with the "CFPrefs Direct Mode" mechanism caused dynamic changes to the
+ user accent color preference to not be respected anymore:
+
+ - the default change, when synchronized to the Web Content process, was
+ written into the wrong domain, because of bug 212627.
+
+ - AppKit caches the resolved accent color; the cache is invalidated when the
+ a CoreUI notification is posted. Since we synchronize preferences ourselves,
+ the ordering of the default change and notification are no longer guaranteed,
+ so AppKit sometimes reads and re-caches the old accent color.
+
+ * WebProcess/cocoa/WebProcessCocoa.mm:
+ (WebKit::userAccentColorPreferenceKey):
+ (WebKit::shouldWriteToAppDomainForPreferenceKey):
+ (WebKit::WebProcess::notifyPreferencesChanged):
+ To fix the first problem, write the default into the standardUserDefaults.
+ This is just a workaround, we need a more general solution to this problem
+ for all global preferences. We know it's OK in this case, because AppKit
+ happens to read from standardUserDefaults.
+
+ (WebKit::dispatchSimulatedNotificationsForPreferenceChange):
+ To fix the second problem, re-emit the notification once we have synchronized
+ the preference to the Web Content process.
+
+2020-06-02 Alan Coon <[email protected]>
+
Cherry-pick r262396. rdar://problem/63891587
Remove unused WebContent process sandbox syscall
Modified: branches/safari-610.1.15-branch/Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm (262447 => 262448)
--- branches/safari-610.1.15-branch/Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm 2020-06-02 21:58:15 UTC (rev 262447)
+++ branches/safari-610.1.15-branch/Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm 2020-06-02 21:58:17 UTC (rev 262448)
@@ -945,11 +945,52 @@
}
#if ENABLE(CFPREFS_DIRECT_MODE)
+
+#if USE(APPKIT)
+static const WTF::String& userAccentColorPreferenceKey()
+{
+ static NeverDestroyed<WTF::String> userAccentColorPreferenceKey(MAKE_STATIC_STRING_IMPL("AppleAccentColor"));
+ return userAccentColorPreferenceKey;
+}
+#endif
+
+static bool shouldWriteToAppDomainForPreferenceKey(const String& key)
+{
+#if USE(APPKIT)
+ return key == userAccentColorPreferenceKey();
+#else
+ return false;
+#endif
+}
+
+static void dispatchSimulatedNotificationsForPreferenceChange(const String& key)
+{
+#if USE(APPKIT)
+ // Ordinarily, other parts of the system ensure that this notification is posted after this default is changed.
+ // However, since we synchronize defaults to the Web Content process using a mechanism not known to the rest
+ // of the system, we must re-post the notification in the Web Content process after updating the default.
+ if (key == userAccentColorPreferenceKey())
+ [[NSNotificationCenter defaultCenter] postNotificationName:@"kCUINotificationAquaColorVariantChanged" object:nil];
+#endif
+}
+
void WebProcess::notifyPreferencesChanged(const String& domain, const String& key, const Optional<String>& encodedValue)
{
- auto defaults = adoptNS([[NSUserDefaults alloc] initWithSuiteName:domain]);
+ // FIXME (212627): In the case of global preference changes, the domain that we are notified in is
+ // not the correct domain to write to; it is an arbitrary domain affected by the global change.
+ // Work around this by writing to the app's domain in cases where we know that is OK
+ // (because the code that uses the default in the Web Content process reads from
+ // -standardUserDefaults, not from a specific domain). PreferenceObserver needs to be fixed
+ // to find the correct domain, but we currently have no mechanism to do so.
+ RetainPtr<NSUserDefaults> defaults;
+ if (shouldWriteToAppDomainForPreferenceKey(key))
+ defaults = [NSUserDefaults standardUserDefaults];
+ else
+ defaults = adoptNS([[NSUserDefaults alloc] initWithSuiteName:domain]);
+
if (!encodedValue.hasValue()) {
[defaults setObject:nil forKey:key];
+ dispatchSimulatedNotificationsForPreferenceChange(key);
return;
}
auto encodedData = adoptNS([[NSData alloc] initWithBase64EncodedString:*encodedValue options:0]);
@@ -962,6 +1003,7 @@
if (err)
return;
[defaults setObject:object forKey:key];
+ dispatchSimulatedNotificationsForPreferenceChange(key);
}
void WebProcess::unblockPreferenceService(SandboxExtension::HandleArray&& handleArray)
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
