Modified: branches/safari-610.1.7-branch/Source/WebKit/ChangeLog (259229 => 259230)
--- branches/safari-610.1.7-branch/Source/WebKit/ChangeLog 2020-03-30 20:56:57 UTC (rev 259229)
+++ branches/safari-610.1.7-branch/Source/WebKit/ChangeLog 2020-03-30 20:57:00 UTC (rev 259230)
@@ -1,52 +1,5 @@
-b'2020-03-30 Alan Coon <[email protected]>\n\n Cherry-pick r258821. rdar://problem/60491857\n\n Adopt -[UIWindowScene interfaceOrientation] when determining device orientation\n https://bugs.webkit.org/show_bug.cgi?id=209372\n <rdar://problem/60491857>\n \n Reviewed by Darin Adler.\n \n Currently, for WebKit clients that have adopted the UIScene lifecycle (and also do not set an interface\n orientation override, like MobileSafari does), device orientation APIs will always report that the device is in\n portrait mode, regardless of the actual device orientation. This is because our current mechanism for tracking\n device orientation asks the shared UIApplication for its -statusBarOrientation. This is hard-coded to always\n return UIInterfaceOrientationPortrait for apps that adopt the UIScene lifecycle, and will additionally trigger a\n simulated crash, explaining that it is invalid for any scene-based app to call -
statusBarOrientation.\n \n To fix this, we adjust the `deviceOrientation` helper in WKWebViewIOS.mm to work for scene-based apps. See below\n for more details.\n \n * Platform/spi/ios/UIKitSPI.h:\n * UIProcess/API/ios/WKWebViewIOS.h:\n * UIProcess/API/ios/WKWebViewIOS.mm:\n (-[WKWebView _setupScrollAndContentViews]):\n \n Change call sites of `deviceOrientation()` to be `[self _deviceOrientation]` instead.\n \n (-[WKWebView _deviceOrientation]):\n \n Replace `deviceOrientation()` with a `_deviceOrientation` helper method on `WKWebView`. For non-scene-based\n apps, this new helper method does not change any behavior, and continues to go through UIApplication. However,\n for scene-based apps, we instead ask the web view\'s window\'s `UIWindowScene` for its interface orientation.\n \n Importantly, this means that if a WKWebView is not parented, it doesn\'t have a valid device orientation (i.e.\n the orientation is UIInterfaceOrie
ntationUnknown). As such, a newly created WKWebView that is unparented will\n start out with no orientation; it\'s only upon moving the view into a window that it is able to determine the\n device orientation. To ensure this, we add logic to -didMoveToWindow to recompute device orientation and\n dispatch an update if needed.\n \n To avoid sending unnecessary updates, if a WKWebView is unparented, we wait until it\'s parented again to send\n the new device orientation.\n \n (-[WKWebView didMoveToWindow]):\n (-[WKWebView _windowDidRotate:]):\n (deviceOrientation): Deleted.\n \n See -[WKWebView _deviceOrientation] above.\n \n \n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258821 268f45cc-cd09-0410-ab3c-d52691b4dbfc\n\n 2020-03-22 Wenson Hsieh <[email protected]>\n\n Adopt -[UIWindowScene interfaceOrientation] when determining device orientation\n https://bugs.webkit.org/show_bug.cgi?id=209
372\n <rdar://problem/60491857>\n\n Reviewed by Darin Adler.\n\n Currently, for WebKit clients that have adopted the UIScene lifecycle (and also do not set an interface\n orientation override, like MobileSafari does), device orientation APIs will always report that the device is in\n portrait mode, regardless of the actual device orientation. This is because our current mechanism for tracking\n device orientation asks the shared UIApplication for its -statusBarOrientation. This is hard-coded to always\n return UIInterfaceOrientationPortrait for apps that adopt the UIScene lifecycle, and will additionally trigger a\n simulated crash, explaining that it is invalid for any scene-based app to call -statusBarOrientation.\n\n To fix this, we adjust the `deviceOrientation` helper in WKWebViewIOS.mm to work for scene-based apps. See below\n for more details.\n\n * P
latform/spi/ios/UIKitSPI.h:\n * UIProcess/API/ios/WKWebViewIOS.h:\n * UIProcess/API/ios/WKWebViewIOS.mm:\n (-[WKWebView _setupScrollAndContentViews]):\n\n Change call sites of `deviceOrientation()` to be `[self _deviceOrientation]` instead.\n\n (-[WKWebView _deviceOrientation]):\n\n Replace `deviceOrientation()` with a `_deviceOrientation` helper method on `WKWebView`. For non-scene-based\n apps, this new helper method does not change any behavior, and continues to go through UIApplication. However,\n for scene-based apps, we instead ask the web view\'s window\'s `UIWindowScene` for its interface orientation.\n\n Importantly, this means that if a WKWebView is not parented, it doesn\'t have a valid device orientation (i.e.\n the orientation is UIInterfaceOrientationUnknown). As such, a newly created WKWebView that is unparented will\n start out with no orientation;
it\'s only upon moving the view into a window that it is able to determine the\n device orientation. To ensure this, we add logic to -didMoveToWindow to recompute device orientation and\n dispatch an update if needed.\n\n To avoid sending unnecessary updates, if a WKWebView is unparented, we wait until it\'s parented again to send\n the new device orientation.\n\n (-[WKWebView didMoveToWindow]):\n (-[WKWebView _windowDidRotate:]):\n (deviceOrientation): Deleted.\n\n See -[WKWebView _deviceOrientation] above.\n\n b\'2020-03-30 Alan Coon <[email protected]>\\n\\n Cherry-pick r258804. rdar://problem/60563952\\n\\n [iPadOS] Yahoo! search results are sometimes zoomed in a little\\n https://bugs.webkit.org/show_bug.cgi?id=209356\\n <rdar://problem/60563952>\\n \\n Reviewed by Tim Horton.\\n \\n Source/WebKit:\\n \\n When the web content process uses
`WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport\\n configuration change) on iOS, it\\\'s possible for this new scale to be replaced by a previous scale when\\n dispatching the next visible content rect update. Consider the following scenario:\\n \\n 1. A remote layer tree transaction is sent to the UI process containing scale `a`.\\n 2. `WebPage::scalePage` is called with a scale `b`.\\n 3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.\\n 4. The page scale reverts to `a`.\\n \\n This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport\\n (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after\\n the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after\\n a remote layer tree transaction with the old scale but before the n
ext visible content rect update containing\\n that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This\\n same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale\\n after the viewport configuration change may be overridden by an incoming visible content rect update.\\n \\n To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a\\n viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a\\n visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit\\n identifier when we changed the page scale, don\\\'t set the page scale factor using this incoming scale; instead,\\n wait for the next visible content rect update (which will contain the new scale).\\n \\n Fixes an existing flaky test: fast/vie
wport/ios/device-width-viewport-after-changing-view-scale.html\\n \\n * WebProcess/WebPage/WebPage.cpp:\\n (WebKit::WebPage::close):\\n (WebKit::WebPage::scalePage):\\n (WebKit::WebPage::platformDidScalePage):\\n \\n Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.\\n \\n (WebKit::WebPage::didCommitLoad):\\n (WebKit::WebPage::didFinishDocumentLoad):\\n (WebKit::WebPage::didFinishLoad):\\n \\n Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content\\n timer with a call to `shrinkToFitContent` instead.\\n \\n * WebProcess/WebPage/WebPage.h:\\n \\n Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the\\n page scale via the web process. This is set in `platformDidScalePage` below.\\n \\n * WebProcess/WebPage/ios/WebPageIOS.mm:\\n (WebKit::WebPage::dynamicVi
ewportSizeUpdate):\\n (WebKit::WebPage::shrinkToFitContent):\\n \\n Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport\\n actually changed.\\n \\n (WebKit::WebPage::updateVisibleContentRects):\\n \\n Ignore the incoming page scale when updating visible content rects if it:\\n 1. Is the same as the last page scale we sent via layer tree commit.\\n 2. After sending the above scale, we\\\'ve since adjusted the page scale such that it is no longer the same.\\n \\n (WebKit::WebPage::platformDidScalePage):\\n \\n Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.\\n \\n (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.\\n (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.\\n \\n Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`\\n directly. This was a source of flakiness when trying to
reproduce the bug, and doesn\\\'t seem to serve any\\n purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.\\n \\n (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.\\n \\n LayoutTests:\\n \\n Remove failing expectations for fast/viewport/ios/device-width-viewport-after-changing-view-scale.html.\\n \\n * platform/ios-wk2/TestExpectations:\\n \\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258804 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\n\\n 2020-03-20 Wenson Hsieh <[email protected]>\\n\\n [iPadOS] Yahoo! search results are sometimes zoomed in a little\\n https://bugs.webkit.org/show_bug.cgi?id=209356\\n <rdar://problem/60563952>\\n\\n Reviewed by Tim Horton.\\n\\n When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport\\n con
figuration change) on iOS, it\\\'s possible for this new scale to be replaced by a previous scale when\\n dispatching the next visible content rect update. Consider the following scenario:\\n\\n 1. A remote layer tree transaction is sent to the UI process containing scale `a`.\\n 2. `WebPage::scalePage` is called with a scale `b`.\\n 3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.\\n 4. The page scale reverts to `a`.\\n\\n This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport\\n (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after\\n the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after\\n a remote layer tree transaction with the old scale but before the next visible content
rect update containing\\n that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This\\n same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale\\n after the viewport configuration change may be overridden by an incoming visible content rect update.\\n\\n To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a\\n viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a\\n visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit\\n identifier when we changed the page scale, don\\\'t set the page scale factor using this incoming scale; instead,\\n wait for the next visible content rect update (which will contain the new scale).\\n\\n
Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html\\n\\n * WebProcess/WebPage/WebPage.cpp:\\n (WebKit::WebPage::close):\\n (WebKit::WebPage::scalePage):\\n (WebKit::WebPage::platformDidScalePage):\\n\\n Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.\\n\\n (WebKit::WebPage::didCommitLoad):\\n (WebKit::WebPage::didFinishDocumentLoad):\\n (WebKit::WebPage::didFinishLoad):\\n\\n Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content\\n timer with a call to `shrinkToFitContent` instead.\\n\\n * WebProcess/WebPage/WebPage.h:\\n\\n Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the\\n page scale via the web process. This is
set in `platformDidScalePage` below.\\n\\n * WebProcess/WebPage/ios/WebPageIOS.mm:\\n (WebKit::WebPage::dynamicViewportSizeUpdate):\\n (WebKit::WebPage::shrinkToFitContent):\\n\\n Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport\\n actually changed.\\n\\n (WebKit::WebPage::updateVisibleContentRects):\\n\\n Ignore the incoming page scale when updating visible content rects if it:\\n 1. Is the same as the last page scale we sent via layer tree commit.\\n 2. After sending the above scale, we\\\'ve since adjusted the page scale such that it is no longer the same.\\n\\n (WebKit::WebPage::platformDidScalePage):\\n\\n Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.\\n\\n (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.\\n (WebKit::WebPage::shrinkToFitContentTim
erFired): Deleted.\\n\\n Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`\\n directly. This was a source of flakiness when trying to reproduce the bug, and doesn\\\'t seem to serve any\\n purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.\\n\\n (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.\\n\\n b\\\'2020-03-30 Alan Coon <[email protected]>\\\\n\\\\n Cherry-pick r258659. rdar://problem/60560831\\\\n\\\\n REGRESSION (r257214): Targeted preview animates to the wrong place when dropping in editable content\\\\n https://bugs.webkit.org/show_bug.cgi?id=209218\\\\n <rdar://problem/60560831>\\\\n \\\\n Reviewed by Tim Horton.\\\\n \\\\n Source/WebKit:\\\\n \\\\n In r257214, we split out the context menu hint preview container view into two views: one for drag
and drop, and\\\\n another for the context menu hint. The container view used for both drag and drop previews was removed under\\\\n -cleanUpDragSourceSessionState, which is invoked after both drag and drop sessions have ended; however, in the\\\\n case of a drop in editable content where the drop preview is delayed, the drop animation can end up finishing\\\\n after -cleanUpDragSourceSessionState is invoked. This means we end up prematurely unparenting the preview\\\\n container, which results in a broken drop animation.\\\\n \\\\n To fix this, split the drag and drop container views further, into separate container views for dragging and for\\\\n dropping. The drag preview container will continue to be removed under -cleanUpDragSourceSessionState, and the\\\\n drop preview container will now be removed under the delegate call to -dropInteraction:concludeDrop:, which is\\\\n invoked by UIKit after all drop previews are finished animating.\\\\n \\\\
n Covered by adding additional test assertions while running existing API tests (see Tools/ChangeLog for more\\\\n details).\\\\n \\\\n * UIProcess/ios/WKContentViewInteraction.h:\\\\n * UIProcess/ios/WKContentViewInteraction.mm:\\\\n (-[WKContentView _createPreviewContainerWithLayerName:]):\\\\n \\\\n Pull out common logic for creating and setting up a preview container view into a helper method. This is used by\\\\n the three methods below, which ensure container views for each of the types of previews we create when showing\\\\n the context menu, dragging an element, and dropping.\\\\n \\\\n (-[WKContentView containerForDropPreviews]):\\\\n (-[WKContentView containerForDragPreviews]):\\\\n (-[WKContentView containerForContextMenuHintPreviews]):\\\\n \\\\n Add a third preview container view for drop previews, and factor duplicated code in these three methods into a\\\\n common helper (see above).\\\\n \\\\n (-[WKContentView
_hideTargetedPreviewContainerViews]):\\\\n (-[WKContentView _deliverDelayedDropPreviewIfPossible:]):\\\\n \\\\n Instead of using the container for drag previews, use the container for drop previews.\\\\n \\\\n (-[WKContentView dropInteraction:concludeDrop:]):\\\\n \\\\n Remove the drop preview container after the drop has concluded (i.e. all animations are complete).\\\\n \\\\n Tools:\\\\n \\\\n Augment the drag and drop test harness to verify that for all targeted previews, if they have container views,\\\\n those views must be parented (i.e. they must be connected to a UIWindow).\\\\n \\\\n * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm:\\\\n (-[DragAndDropSimulator _concludeDropAndPerformOperationIfNecessary]):\\\\n (-[DragAndDropSimulator _expectNoDropPreviewsWithUnparentedContainerViews]):\\\\n (-[DragAndDropSimulator _invokeDropAnimationCompletionBlocksAndConcludeDrop]):\\\\n \\\\n \\\\n git-svn-id: https://svn.webkit
.org/repository/webkit/trunk@258659 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\n\\\\n 2020-03-18 Wenson Hsieh <[email protected]>\\\\n\\\\n REGRESSION (r257214): Targeted preview animates to the wrong place when dropping in editable content\\\\n https://bugs.webkit.org/show_bug.cgi?id=209218\\\\n <rdar://problem/60560831>\\\\n\\\\n Reviewed by Tim Horton.\\\\n\\\\n In r257214, we split out the context menu hint preview container view into two views: one for drag and drop, and\\\\n another for the context menu hint. The container view used for both drag and drop previews was removed under\\\\n -cleanUpDragSourceSessionState, which is invoked after both drag and drop sessions have ended; however, in the\\\\n case of a drop in editable content where the drop preview is delayed, the drop animation can end up finishing\\\\n after -cleanUpDragSourceSessionState is invoked.
This means we end up prematurely unparenting the preview\\\\n container, which results in a broken drop animation.\\\\n\\\\n To fix this, split the drag and drop container views further, into separate container views for dragging and for\\\\n dropping. The drag preview container will continue to be removed under -cleanUpDragSourceSessionState, and the\\\\n drop preview container will now be removed under the delegate call to -dropInteraction:concludeDrop:, which is\\\\n invoked by UIKit after all drop previews are finished animating.\\\\n\\\\n Covered by adding additional test assertions while running existing API tests (see Tools/ChangeLog for more\\\\n details).\\\\n\\\\n * UIProcess/ios/WKContentViewInteraction.h:\\\\n * UIProcess/ios/WKContentViewInteraction.mm:\\\\n (-[WKContentView _createPreviewContainerWithLayerName:]):\\\\n\\\\n Pull out common logic for
creating and setting up a preview container view into a helper method. This is used by\\\\n the three methods below, which ensure container views for each of the types of previews we create when showing\\\\n the context menu, dragging an element, and dropping.\\\\n\\\\n (-[WKContentView containerForDropPreviews]):\\\\n (-[WKContentView containerForDragPreviews]):\\\\n (-[WKContentView containerForContextMenuHintPreviews]):\\\\n\\\\n Add a third preview container view for drop previews, and factor duplicated code in these three methods into a\\\\n common helper (see above).\\\\n\\\\n (-[WKContentView _hideTargetedPreviewContainerViews]):\\\\n (-[WKContentView _deliverDelayedDropPreviewIfPossible:]):\\\\n\\\\n Instead of using the container for drag previews, use the container for drop previews.\\\\n\\\\n (-[WKContentView dropInteraction:concludeDrop:]):\\\\n\\\\n
Remove the drop preview container after the drop has concluded (i.e. all animations are complete).\\\\n\\\\n b\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\n\\\\\\\\n Cherry-pick r258530. rdar://problem/60453086\\\\\\\\n\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\n <rdar://problem/60453086>\\\\\\\\n \\\\\\\\n Reviewed by Darin Adler.\\\\\\\\n \\\\\\\\n Alternative fix for Bug 209149 based on comments from Darin.\\\\\\\\n \\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\n (WebKit::WebCookieCache::clearForHost):\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\n \\\\\\\\n \\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258530 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\n\\\\\\\\n 2020-03-16 Chris Dumez <[email protected]>\\\\\\\\n\\\\\\\\n Crash under WebCookieC
ache::clearForHost()\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\n <rdar://problem/60453086>\\\\\\\\n\\\\\\\\n Reviewed by Darin Adler.\\\\\\\\n\\\\\\\\n Alternative fix for Bug 209149 based on comments from Darin.\\\\\\\\n\\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\n (WebKit::WebCookieCache::clearForHost):\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\n\\\\\\\\n b\\\\\\\\\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Cherry-pick r258521. rdar://problem/60453086\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\\\\\\\\\n <rdar://problem/60453086>\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Reviewed by Alex Christensen.\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\
\n \\\\\\\\\\\\\\\\n Make sure WebCookieCache::pruneCacheIfNecessary() keeps alive the host String it is passing\\\\\\\\\\\\\\\\n to WebCookieCache::clearForHost(). Previously, it was merely deferencing a HashSet iterator\\\\\\\\\\\\\\\\n and passing that to clearForHost(). However, clearForHost() would then drop the String from\\\\\\\\\\\\\\\\n the HashSet and the host would no longer be valid.\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Change covered by new API test.\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Tools:\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Add API test coverage.\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n * TestWebKitAPI/Tests/WebKitCocoa/CookiePrivateBrowsing.mm:\\\\\\\\\\\\\\\\n (TEST):\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/tru
nk@258521 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n 2020-03-16 Chris Dumez <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\\\\\\\\\n <rdar://problem/60453086>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Alex Christensen.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Make sure WebCookieCache::pruneCacheIfNecessary() keeps alive the host String it is passing\\\\\\\\\\\\\\\\n to WebCookieCache::clearForHost(). Previously, it was merely deferencing a HashSet iterator\\\\\\\\\\\\\\\\n and passing that to clearForHost(). However, clearForHost() would then drop the String from\\\\\\\\\\\\\\\\n the HashSet and the host would no longer be valid.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Change covered by new API test.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\
n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n b\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258456. rdar://problem/59931477\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Clean up sandbox violations found during testing\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209096\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/59931477>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Geoffrey Garen.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Remove telemetry from some items, and allow access to some IOKit properties\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n needed for media playback on macOS and iOS.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258456 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-13 Brent Fulgham <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Clean up sandbox violations found during testing\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209096\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/59931477>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Geoffrey Garen.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n R
emove telemetry from some items, and allow access to some IOKit properties\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n needed for media playback on macOS and iOS.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n b"2020-03-24 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258476. rdar://problem/60839077\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Add missing checks needed for AppBound Quirk\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209117\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60460097>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by John Wilander.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n The checks for the \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' flag added in r258101 was incomplete.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebCore:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Two additional call sites need to check the state of the flag.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * bindings/js/ScriptController.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebCore::ScriptController::executeScriptInWorld): Add missing check for the quirk.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * loader/FrameLoaderClient.h: Add new API for the \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n debug flag.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * page/Frame.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebCore::Frame::injectUserScriptImmediately): Ditto.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n These changes let the WebFrameLoaderClient report the quirk state to WebCore code.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebFrameLoaderClient::needsInAppBrowserPrivacyQuirks): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebPage.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebPage::needsInAppBrowserPrivacyQuirks const): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258476 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-14 Brent Fulgham <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Add missing checks needed for AppBound Quirk\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209117\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60460097>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by John Wilander.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n The checks for the \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' flag added in r258101 was incomplete.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n These changes let the WebFrameLoaderClient report the quirk state to WebCore code.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebFrameLoaderClient::needsInAppBrowserPrivacyQuirks): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * We
bProcess/WebPage/WebPage.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebPage::needsInAppBrowserPrivacyQuirks const): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n"2020-03-17 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258515. rdar://problem/60551856\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n [Cocoa] Crash under -[WKPreferenceObserver init]\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209145\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Darin Adler.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Handle the case when calling [NSUserDefaults initWithSuiteName:] did not succeed.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\n No new tests, since I have not been able to reproduce.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (-[WKPreferenceObserver init]):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258515 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-16 Per Arne Vollan <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n [Cocoa] Crash under -[WKPreferenceObserver init]\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209145\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Darin Adler.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\n Handle the case when calling [NSUserDefaults initWithSuiteName:] did not succeed.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n No new tests, since I have not been able to reproduce.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (-[WKPreferenceObserver init]):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Cherry-pick r258518. rdar://problem/60517387\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n [macOS] Accessibility sandbox regressions\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209065\\\\\\\\\\\\\\\\n Source/WebCore/PAL:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\n\\
\\\\\\\\\\\\\\n Add Accessibility notification name.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * pal/spi/cocoa/NSAccessibilitySPI.h:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n <rdar://problem/60202450>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n When Accessibility is enabled, the WebContent process needs access to the preference service, since Accessibility\\\\\\\\\\\\\\\\n is relying on some advanced features of the service. Also, when CF prefs direct mode is enabled, the WebContent\\\\\\\\\\\\\\\\n sandbox needs to explicitly allow reading of the various plist files.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Tools:
\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * TestWebKitAPI/Tests/WebKit/EnableAccessibility.mm:\\\\\\\\\\\\\\\\n (TEST):\\\\\\\\\\\\\\\\n * TestWebKitAPI/Tests/WebKit/GrantAccessToPreferencesService.mm:\\\\\\\\\\\\\\\\n (TEST):\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258518 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n 2020-03-16 Per Arne Vollan <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n [macOS] Accessibility sandbox regressions\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209065\\\\\\\\\\\\\\\\n <rdar://problem/60202450>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n When Accessibility is enabled,
the WebContent process needs access to the preference service, since Accessibility\\\\\\\\\\\\\\\\n is relying on some advanced features of the service. Also, when CF prefs direct mode is enabled, the WebContent\\\\\\\\\\\\\\\\n sandbox needs to explicitly allow reading of the various plist files.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\\\\\n\\\\\\\\n Cherry-pick r258359. rdar://problem/60517387\\\\\\\\n\\\\\\\\n [macOS] _AXSApplicationAccessibilityEnabled should not be called\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=208953\\\\\\\\n\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\n\\\\\\\\n Source/WebCo
re:\\\\\\\\n\\\\\\\\n The function _AXSApplicationAccessibilityEnabled and the notification kAXSApplicationAccessibilityEnabledNotification\\\\\\\\n exist on macOS, but they do not have the same behavior as on iOS, and should not be used in the same way. Using this\\\\\\\\n function and notification on macOS was introduced in <https://bugs.webkit.org/show_bug.cgi?id=208690>, and this patch\\\\\\\\n partially reverts this behavior.\\\\\\\\n\\\\\\\\n API test: WebKit.IsRemoteUIAppForAccessibility\\\\\\\\n\\\\\\\\n * testing/Internals.cpp:\\\\\\\\n (WebCore::Internals::isRemoteUIAppForAccessibility):\\\\\\\\n * testing/Internals.h:\\\\\\\\n * testing/Internals.idl:\\\\\\\\n * testing/Internals.mm:\\\\\\\\n (WebCore::Internals::isRemoteUIAppForAccessibility):\\\\\\\\n\\\\\\\\n Source/WebCore/PAL:\\\\\\\\n\\\\\\\\n Declare method to check if the process is a remote UI app for accessibility.\\
\\\\\\n\\\\\\\\n * pal/spi/cocoa/NSAccessibilitySPI.h:\\\\\\\\n\\\\\\\\n Source/WebKit:\\\\\\\\n\\\\\\\\n On macOS, stop using the function _AXSApplicationAccessibilityEnabled and listening to the notification\\\\\\\\n kAXSApplicationAccessibilityEnabledNotification, since they do not have the same behavior as on iOS.\\\\\\\\n\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\n (WebKit::WebProcessPool::platformInitializeWebProcess):\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\n (WebKit::WebProcessPool::unregisterNotificationObservers):\\\\\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\\\\\n (WebKit::WebProcessProxy::unblockAccessibilityServerIfNeeded):\\\\\\\\n * WebProcess/cocoa/WebProcessCocoa.mm:\\\\\\\\n (WebKit::WebProcess::platformInitializeProcess):\\\\\\\\n (WebKit::WebProcess::unblockAccessibilityServer):\\\\\\\\n\\\\\\\\n Tools:\\\\\\\
\n\\\\\\\\n * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:\\\\\\\\n\\\\\\\\n\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258359 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\n\\\\\\\\n 2020-03-12 Per Arne Vollan <[email protected]>\\\\\\\\n\\\\\\\\n [macOS] _AXSApplicationAccessibilityEnabled should not be called\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=208953\\\\\\\\n\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\n\\\\\\\\n On macOS, stop using the function _AXSApplicationAccessibilityEnabled and listening to the notification\\\\\\\\n kAXSApplicationAccessibilityEnabledNotification, since they do not have the same behavior as on iOS.\\\\\\\\n\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\n (WebKit::WebProcessPool::platformInitializeWebProcess):\\\\\\\\n (WebKit::WebProcessPool::registerN
otificationObservers):\\\\\\\\n (WebKit::WebProcessPool::unregisterNotificationObservers):\\\\\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\\\\\n (WebKit::WebProcessProxy::unblockAccessibilityServerIfNeeded):\\\\\\\\n * WebProcess/cocoa/WebProcessCocoa.mm:\\\\\\\\n (WebKit::WebProcess::platformInitializeProcess):\\\\\\\\n (WebKit::WebProcess::unblockAccessibilityServer):\\\\\\\\n\\\\\\\\n\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\n\\\\n Cherry-pick r258557. rdar://problem/60517387\\\\n\\\\n [Cocoa] Disable CF prefs direct mode\\\\n https://bugs.webkit.org/show_bug.cgi?id=209166\\\\n <rdar://problem/60517387>\\\\n\\\\n Reviewed by Brent Fulgham.\\\\n\\\\n Revert <https://trac.webkit.org/changeset/258064> by disabling the CF prefs direct mode feature,\\\\n since it caused performance regressions.\\\\n\\\\n
Source/WebKit:\\\\n\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\\\n (WebKit::XPCServiceMain):\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\n * UIProcess/Cocoa/WebPageProxyCocoa.mm:\\\\n (WebKit::WebPageProxy::grantAccessToPreferenceService):\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\n * UIProcess/WebProcessPool.h:\\\\n * UIProcess/WebProcessProxy.h:\\\\n * WebProcess/WebProcess.h:\\\\n * WebProcess/WebProcess.messages.in:\\\\n\\\\n Source/WTF:\\\\n\\\\n * wtf/PlatformEnable.h:\\\\n\\\\n\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258557 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\n\\\\n 2020-03-17 Per Arne Vollan <[email protected]>\\\\n\\\\n [Cocoa] Disable CF prefs direct mo
de\\\\n https://bugs.webkit.org/show_bug.cgi?id=209166\\\\n <rdar://problem/60517387>\\\\n\\\\n Reviewed by Brent Fulgham.\\\\n\\\\n Revert <https://trac.webkit.org/changeset/258064> by disabling the CF prefs direct mode feature,\\\\n since it caused performance regressions.\\\\n\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\\\n (WebKit::XPCServiceMain):\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\n * UIProcess/Cocoa/WebPageProxyCocoa.mm:\\\\n (WebKit::WebPageProxy::grantAccessToPreferenceService):\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\n * UIProcess/WebProcessPool.h:\\\\n * UIProcess/WebProcess
Proxy.h:\\\\n * WebProcess/WebProcess.h:\\\\n * WebProcess/WebProcess.messages.in:\\\\n\\\\n\\\'2020-03-17 Alan Coon <[email protected]>\\n\\n Cherry-pick r258512. rdar://problem/60517387\\n\\n [Cocoa] Only set CF prefs direct mode for the WebContent process\\n https://bugs.webkit.org/show_bug.cgi?id=209091\\n <rdar://problem/60337842>\\n\\n Reviewed by Brent Fulgham.\\n\\n Currently, we enable CF prefs direct mode in XPCServiceMain. This is incorrect, it should only be enabled\\n for the WebContent process.\\n\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\n (WebKit::XPCServiceMain):\\n\\n\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258512 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\n\\n 2020-03-16 Per Arne Vollan <[email protected]>\\n\\n [Cocoa] Only set CF prefs direct mode for the WebContent proces
s\\n https://bugs.webkit.org/show_bug.cgi?id=209091\\n <rdar://problem/60337842>\\n\\n Reviewed by Brent Fulgham.\\n\\n Currently, we enable CF prefs direct mode in XPCServiceMain. This is incorrect, it should only be enabled\\n for the WebContent process.\\n\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\n (WebKit::XPCServiceMain):\\n\\n\'2020-03-11 Russell Epstein <[email protected]>\n\n Cherry-pick r258304. rdar://problem/60351239\n\n [macOS] Register with accessibility when the WebContent process starts\n https://bugs.webkit.org/show_bug.cgi?id=208960\n\n Reviewed by Brent Fulgham.\n\n When we reenabled CF prefs direct mode in <https://bugs.webkit.org/show_bug.cgi?id=208690>, we started to register\n with accessibility when we received a message to do so from the UI process. This would ty
pically happen when the user\n enabled accessibility. On macOS, this notification does not work the same way as on iOS, and it is assumed that\n accessibility should always be enabled. Therefore we should go back to registering with accessibility on startup of\n the WebContent process on macOS.\n\n * WebProcess/cocoa/WebProcessCocoa.mm:\n (WebKit::WebProcess::platformInitializeProcess):\n (WebKit::WebProcess::unblockAccessibilityServer):\n\n\n\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258304 268f45cc-cd09-0410-ab3c-d52691b4dbfc\n\n 2020-03-11 Per Arne Vollan <[email protected]>\n\n [macOS] Register with accessibility when the WebContent process starts\n https://bugs.webkit.org/show_bug.cgi?id=208960\n\n Reviewed by Brent Fulgham.\n\n When we reenabled CF prefs direct mode in <https://bugs.webkit.org/show_bug.cgi?id=208690>, we started t
o register\n with accessibility when we received a message to do so from the UI process. This would typically happen when the user\n enabled accessibility. On macOS, this notification does not work the same way as on iOS, and it is assumed that\n accessibility should always be enabled. Therefore we should go back to registering with accessibility on startup of\n the WebContent process on macOS.\n\n * WebProcess/cocoa/WebProcessCocoa.mm:\n (WebKit::WebProcess::platformInitializeProcess):\n (WebKit::WebProcess::unblockAccessibilityServer):\n\n'2020-03-11 Alan Coon <[email protected]>
+b'2020-03-30 Alan Coon <[email protected]>\n\n Cherry-pick r258958. rdar://problem/60750956\n\n Ignore in-app browser privacy checks for apps with com.apple.private.applemediaservices entitlement\n https://bugs.webkit.org/show_bug.cgi?id=209509\n <rdar://problem/60750956>\n \n Reviewed by Brent Fulgham.\n \n * UIProcess/WebPageProxy.cpp:\n (WebKit::m_ignoresAppBoundDomains):\n (WebKit::WebPageProxy::setIsNavigatingToAppBoundDomain):\n * UIProcess/WebPageProxy.h:\n \n \n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258958 268f45cc-cd09-0410-ab3c-d52691b4dbfc\n\n 2020-03-24 Kate Cheney <[email protected]>\n\n Ignore in-app browser privacy checks for apps with com.apple.private.applemediaservices entitlement\n https://bugs.webkit.org/show_bug.cgi?id=209509\n <rdar://problem/60750956>\n\n Reviewed by Brent Fulgham.\n\n * U
IProcess/WebPageProxy.cpp:\n (WebKit::m_ignoresAppBoundDomains):\n (WebKit::WebPageProxy::setIsNavigatingToAppBoundDomain):\n * UIProcess/WebPageProxy.h:\n\n b\'2020-03-30 Alan Coon <[email protected]>\\n\\n Cherry-pick r258821. rdar://problem/60491857\\n\\n Adopt -[UIWindowScene interfaceOrientation] when determining device orientation\\n https://bugs.webkit.org/show_bug.cgi?id=209372\\n <rdar://problem/60491857>\\n \\n Reviewed by Darin Adler.\\n \\n Currently, for WebKit clients that have adopted the UIScene lifecycle (and also do not set an interface\\n orientation override, like MobileSafari does), device orientation APIs will always report that the device is in\\n portrait mode, regardless of the actual device orientation. This is because our current mechanism for tracking\\n device orientation asks the shared UIApplication for its -statusBarOrientation. This is hard-coded to always\\n r
eturn UIInterfaceOrientationPortrait for apps that adopt the UIScene lifecycle, and will additionally trigger a\\n simulated crash, explaining that it is invalid for any scene-based app to call -statusBarOrientation.\\n \\n To fix this, we adjust the `deviceOrientation` helper in WKWebViewIOS.mm to work for scene-based apps. See below\\n for more details.\\n \\n * Platform/spi/ios/UIKitSPI.h:\\n * UIProcess/API/ios/WKWebViewIOS.h:\\n * UIProcess/API/ios/WKWebViewIOS.mm:\\n (-[WKWebView _setupScrollAndContentViews]):\\n \\n Change call sites of `deviceOrientation()` to be `[self _deviceOrientation]` instead.\\n \\n (-[WKWebView _deviceOrientation]):\\n \\n Replace `deviceOrientation()` with a `_deviceOrientation` helper method on `WKWebView`. For non-scene-based\\n apps, this new helper method does not change any behavior, and continues to go through UIApplication. However,\\n for scene-based apps, we instead ask the web view\\\'s wi
ndow\\\'s `UIWindowScene` for its interface orientation.\\n \\n Importantly, this means that if a WKWebView is not parented, it doesn\\\'t have a valid device orientation (i.e.\\n the orientation is UIInterfaceOrientationUnknown). As such, a newly created WKWebView that is unparented will\\n start out with no orientation; it\\\'s only upon moving the view into a window that it is able to determine the\\n device orientation. To ensure this, we add logic to -didMoveToWindow to recompute device orientation and\\n dispatch an update if needed.\\n \\n To avoid sending unnecessary updates, if a WKWebView is unparented, we wait until it\\\'s parented again to send\\n the new device orientation.\\n \\n (-[WKWebView didMoveToWindow]):\\n (-[WKWebView _windowDidRotate:]):\\n (deviceOrientation): Deleted.\\n \\n See -[WKWebView _deviceOrientation] above.\\n \\n \\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258821 268f45cc-c
d09-0410-ab3c-d52691b4dbfc\\n\\n 2020-03-22 Wenson Hsieh <[email protected]>\\n\\n Adopt -[UIWindowScene interfaceOrientation] when determining device orientation\\n https://bugs.webkit.org/show_bug.cgi?id=209372\\n <rdar://problem/60491857>\\n\\n Reviewed by Darin Adler.\\n\\n Currently, for WebKit clients that have adopted the UIScene lifecycle (and also do not set an interface\\n orientation override, like MobileSafari does), device orientation APIs will always report that the device is in\\n portrait mode, regardless of the actual device orientation. This is because our current mechanism for tracking\\n device orientation asks the shared UIApplication for its -statusBarOrientation. This is hard-coded to always\\n return UIInterfaceOrientationPortrait for apps that adopt the UIScene lifecycle, and will additionally trigger a\\n simulated crash, expla
ining that it is invalid for any scene-based app to call -statusBarOrientation.\\n\\n To fix this, we adjust the `deviceOrientation` helper in WKWebViewIOS.mm to work for scene-based apps. See below\\n for more details.\\n\\n * Platform/spi/ios/UIKitSPI.h:\\n * UIProcess/API/ios/WKWebViewIOS.h:\\n * UIProcess/API/ios/WKWebViewIOS.mm:\\n (-[WKWebView _setupScrollAndContentViews]):\\n\\n Change call sites of `deviceOrientation()` to be `[self _deviceOrientation]` instead.\\n\\n (-[WKWebView _deviceOrientation]):\\n\\n Replace `deviceOrientation()` with a `_deviceOrientation` helper method on `WKWebView`. For non-scene-based\\n apps, this new helper method does not change any behavior, and continues to go through UIApplication. However,\\n for scene-based apps, we instead ask the web view\\\'s window\\\'s `UIWindowScene` for its interface orientation.\\n\\n
Importantly, this means that if a WKWebView is not parented, it doesn\\\'t have a valid device orientation (i.e.\\n the orientation is UIInterfaceOrientationUnknown). As such, a newly created WKWebView that is unparented will\\n start out with no orientation; it\\\'s only upon moving the view into a window that it is able to determine the\\n device orientation. To ensure this, we add logic to -didMoveToWindow to recompute device orientation and\\n dispatch an update if needed.\\n\\n To avoid sending unnecessary updates, if a WKWebView is unparented, we wait until it\\\'s parented again to send\\n the new device orientation.\\n\\n (-[WKWebView didMoveToWindow]):\\n (-[WKWebView _windowDidRotate:]):\\n (deviceOrientation): Deleted.\\n\\n See -[WKWebView _deviceOrientation] above.\\n\\n b\\\'2020-03-30 Alan Coon <[email protected]>\\\\n\\\\n Cherry-pick r25
8804. rdar://problem/60563952\\\\n\\\\n [iPadOS] Yahoo! search results are sometimes zoomed in a little\\\\n https://bugs.webkit.org/show_bug.cgi?id=209356\\\\n <rdar://problem/60563952>\\\\n \\\\n Reviewed by Tim Horton.\\\\n \\\\n Source/WebKit:\\\\n \\\\n When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport\\\\n configuration change) on iOS, it\\\\\\\'s possible for this new scale to be replaced by a previous scale when\\\\n dispatching the next visible content rect update. Consider the following scenario:\\\\n \\\\n 1. A remote layer tree transaction is sent to the UI process containing scale `a`.\\\\n 2. `WebPage::scalePage` is called with a scale `b`.\\\\n 3. A visible content rect update with scale `a` is scheduled, sent to the web process and dispatched.\\\\n 4. The page scale reverts to `a`.\\\\n \\\\n This bug exercises the above scenario: the Yahoo search re
sults page specifies a responsive viewport\\\\n (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after\\\\n the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after\\\\n a remote layer tree transaction with the old scale but before the next visible content rect update containing\\\\n that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This\\\\n same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale\\\\n after the viewport configuration change may be overridden by an incoming visible content rect update.\\\\n \\\\n To fix this, we add a mechanism to detect when the page scale has been changed by the web process (e.g. after a\\\\n viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a\\\\n vi
sible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit\\\\n identifier when we changed the page scale, don\\\\\\\'t set the page scale factor using this incoming scale; instead,\\\\n wait for the next visible content rect update (which will contain the new scale).\\\\n \\\\n Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html\\\\n \\\\n * WebProcess/WebPage/WebPage.cpp:\\\\n (WebKit::WebPage::close):\\\\n (WebKit::WebPage::scalePage):\\\\n (WebKit::WebPage::platformDidScalePage):\\\\n \\\\n Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS version.\\\\n \\\\n (WebKit::WebPage::didCommitLoad):\\\\n (WebKit::WebPage::didFinishDocumentLoad):\\\\n (WebKit::WebPage::didFinishLoad):\\\\n \\\\n Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to
fit content\\\\n timer with a call to `shrinkToFitContent` instead.\\\\n \\\\n * WebProcess/WebPage/WebPage.h:\\\\n \\\\n Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the\\\\n page scale via the web process. This is set in `platformDidScalePage` below.\\\\n \\\\n * WebProcess/WebPage/ios/WebPageIOS.mm:\\\\n (WebKit::WebPage::dynamicViewportSizeUpdate):\\\\n (WebKit::WebPage::shrinkToFitContent):\\\\n \\\\n Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport\\\\n actually changed.\\\\n \\\\n (WebKit::WebPage::updateVisibleContentRects):\\\\n \\\\n Ignore the incoming page scale when updating visible content rects if it:\\\\n 1. Is the same as the last page scale we sent via layer tree commit.\\\\n 2. After sending the above scale, we\\\\\\\'ve since adjusted the page scale such that it is no longer the same.\\
\\n \\\\n (WebKit::WebPage::platformDidScalePage):\\\\n \\\\n Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.\\\\n \\\\n (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.\\\\n (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.\\\\n \\\\n Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`\\\\n directly. This was a source of flakiness when trying to reproduce the bug, and doesn\\\\\\\'t seem to serve any\\\\n purpose since we shrink-to-fit after dispatching the "DOMContentLoaded" and "load" events anyways.\\\\n \\\\n (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.\\\\n \\\\n LayoutTests:\\\\n \\\\n Remove failing expectations for fast/viewport/ios/device-width-viewport-after-changing-view-scale.html.\\\\n \\\\n * platform/ios-wk2/TestExpectations:\\\\n \\\\n git-svn-id: https://svn.webkit.org/repository/w
ebkit/trunk@258804 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\n\\\\n 2020-03-20 Wenson Hsieh <[email protected]>\\\\n\\\\n [iPadOS] Yahoo! search results are sometimes zoomed in a little\\\\n https://bugs.webkit.org/show_bug.cgi?id=209356\\\\n <rdar://problem/60563952>\\\\n\\\\n Reviewed by Tim Horton.\\\\n\\\\n When the web content process uses `WebPage::scalePage()` to modify the viewport scale (e.g. after a viewport\\\\n configuration change) on iOS, it\\\\\\\'s possible for this new scale to be replaced by a previous scale when\\\\n dispatching the next visible content rect update. Consider the following scenario:\\\\n\\\\n 1. A remote layer tree transaction is sent to the UI process containing scale `a`.\\\\n 2. `WebPage::scalePage` is called with a scale `b`.\\\\n 3. A visible content rect update with scale `a` is scheduled, sent to the web process a
nd dispatched.\\\\n 4. The page scale reverts to `a`.\\\\n\\\\n This bug exercises the above scenario: the Yahoo search results page specifies a responsive viewport\\\\n (device-width and scale=1), but proceeds to lay out outside of the bounds of the device width. As such, after\\\\n the document finishes parsing, we attempt to shrink the page to fit; however, if this shrinking happens after\\\\n a remote layer tree transaction with the old scale but before the next visible content rect update containing\\\\n that old scale, we will end up reverting to this old scale instead of the scale after shrinking to fit. This\\\\n same bug is present when using `setViewScale`, which was exercised by the flaky test below, since the new scale\\\\n after the viewport configuration change may be overridden by an incoming visible content rect update.\\\\n\\\\n To fix this, we add a mechanism to detec
t when the page scale has been changed by the web process (e.g. after a\\\\n viewport change) and remember the last committed layer tree identifier at that moment. Later, if we get a\\\\n visible content rect update with a layer tree commit identifier equal to (or older than) the layer tree commit\\\\n identifier when we changed the page scale, don\\\\\\\'t set the page scale factor using this incoming scale; instead,\\\\n wait for the next visible content rect update (which will contain the new scale).\\\\n\\\\n Fixes an existing flaky test: fast/viewport/ios/device-width-viewport-after-changing-view-scale.html\\\\n\\\\n * WebProcess/WebPage/WebPage.cpp:\\\\n (WebKit::WebPage::close):\\\\n (WebKit::WebPage::scalePage):\\\\n (WebKit::WebPage::platformDidScalePage):\\\\n\\\\n Add a platform hook that is invoked after scaling the page via `scalePage`. See below for the iOS ver
sion.\\\\n\\\\n (WebKit::WebPage::didCommitLoad):\\\\n (WebKit::WebPage::didFinishDocumentLoad):\\\\n (WebKit::WebPage::didFinishLoad):\\\\n\\\\n Drive-by fix: remove an unnecessary `UNUSED_PARAM`. Also, replace calls to schedule the shrink to fit content\\\\n timer with a call to `shrinkToFitContent` instead.\\\\n\\\\n * WebProcess/WebPage/WebPage.h:\\\\n\\\\n Add a member variable to remember the last sent layer tree commit ID and page scale, when we last changed the\\\\n page scale via the web process. This is set in `platformDidScalePage` below.\\\\n\\\\n * WebProcess/WebPage/ios/WebPageIOS.mm:\\\\n (WebKit::WebPage::dynamicViewportSizeUpdate):\\\\n (WebKit::WebPage::shrinkToFitContent):\\\\n\\\\n Refactor this to not return a bool, but instead call `viewportConfigurationChanged` at the end if the viewport\\\\n actually changed.\\\\n\\\\n
(WebKit::WebPage::updateVisibleContentRects):\\\\n\\\\n Ignore the incoming page scale when updating visible content rects if it:\\\\n 1. Is the same as the last page scale we sent via layer tree commit.\\\\n 2. After sending the above scale, we\\\\\\\'ve since adjusted the page scale such that it is no longer the same.\\\\n\\\\n (WebKit::WebPage::platformDidScalePage):\\\\n\\\\n Update `m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage`.\\\\n\\\\n (WebKit::WebPage::scheduleShrinkToFitContent): Deleted.\\\\n (WebKit::WebPage::shrinkToFitContentTimerFired): Deleted.\\\\n\\\\n Remove the zero-delay timer before running the shrink-to-fit heuristic, and just call `shrinkToFitContent`\\\\n directly. This was a source of flakiness when trying to reproduce the bug, and doesn\\\\\\\'t seem to serve any\\\\n purpose since we shrink-to-fit after dispatching the &qu
ot;DOMContentLoaded" and "load" events anyways.\\\\n\\\\n (WebKit::WebPage::immediatelyShrinkToFitContent): Deleted.\\\\n\\\\n b\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\n\\\\\\\\n Cherry-pick r258659. rdar://problem/60560831\\\\\\\\n\\\\\\\\n REGRESSION (r257214): Targeted preview animates to the wrong place when dropping in editable content\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209218\\\\\\\\n <rdar://problem/60560831>\\\\\\\\n \\\\\\\\n Reviewed by Tim Horton.\\\\\\\\n \\\\\\\\n Source/WebKit:\\\\\\\\n \\\\\\\\n In r257214, we split out the context menu hint preview container view into two views: one for drag and drop, and\\\\\\\\n another for the context menu hint. The container view used for both drag and drop previews was removed under\\\\\\\\n -cleanUpDragSourceSessionState, which is invoked after both drag and drop sessions have ended; however, in the\\\\\\\\n case
of a drop in editable content where the drop preview is delayed, the drop animation can end up finishing\\\\\\\\n after -cleanUpDragSourceSessionState is invoked. This means we end up prematurely unparenting the preview\\\\\\\\n container, which results in a broken drop animation.\\\\\\\\n \\\\\\\\n To fix this, split the drag and drop container views further, into separate container views for dragging and for\\\\\\\\n dropping. The drag preview container will continue to be removed under -cleanUpDragSourceSessionState, and the\\\\\\\\n drop preview container will now be removed under the delegate call to -dropInteraction:concludeDrop:, which is\\\\\\\\n invoked by UIKit after all drop previews are finished animating.\\\\\\\\n \\\\\\\\n Covered by adding additional test assertions while running existing API tests (see Tools/ChangeLog for more\\\\\\\\n details).\\\\\\\\n \\\\\\\\n * UIProcess/ios/WKContentViewInteraction.h:\\\\\\\\n * UIProcess
/ios/WKContentViewInteraction.mm:\\\\\\\\n (-[WKContentView _createPreviewContainerWithLayerName:]):\\\\\\\\n \\\\\\\\n Pull out common logic for creating and setting up a preview container view into a helper method. This is used by\\\\\\\\n the three methods below, which ensure container views for each of the types of previews we create when showing\\\\\\\\n the context menu, dragging an element, and dropping.\\\\\\\\n \\\\\\\\n (-[WKContentView containerForDropPreviews]):\\\\\\\\n (-[WKContentView containerForDragPreviews]):\\\\\\\\n (-[WKContentView containerForContextMenuHintPreviews]):\\\\\\\\n \\\\\\\\n Add a third preview container view for drop previews, and factor duplicated code in these three methods into a\\\\\\\\n common helper (see above).\\\\\\\\n \\\\\\\\n (-[WKContentView _hideTargetedPreviewContainerViews]):\\\\\\\\n (-[WKContentView _deliverDelayedDropPreviewIfPossible:]):\\\\\\\\n \\\\\\\\n Instead of using the c
ontainer for drag previews, use the container for drop previews.\\\\\\\\n \\\\\\\\n (-[WKContentView dropInteraction:concludeDrop:]):\\\\\\\\n \\\\\\\\n Remove the drop preview container after the drop has concluded (i.e. all animations are complete).\\\\\\\\n \\\\\\\\n Tools:\\\\\\\\n \\\\\\\\n Augment the drag and drop test harness to verify that for all targeted previews, if they have container views,\\\\\\\\n those views must be parented (i.e. they must be connected to a UIWindow).\\\\\\\\n \\\\\\\\n * TestWebKitAPI/ios/DragAndDropSimulatorIOS.mm:\\\\\\\\n (-[DragAndDropSimulator _concludeDropAndPerformOperationIfNecessary]):\\\\\\\\n (-[DragAndDropSimulator _expectNoDropPreviewsWithUnparentedContainerViews]):\\\\\\\\n (-[DragAndDropSimulator _invokeDropAnimationCompletionBlocksAndConcludeDrop]):\\\\\\\\n \\\\\\\\n \\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258659 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\
\\\\\n\\\\\\\\n 2020-03-18 Wenson Hsieh <[email protected]>\\\\\\\\n\\\\\\\\n REGRESSION (r257214): Targeted preview animates to the wrong place when dropping in editable content\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209218\\\\\\\\n <rdar://problem/60560831>\\\\\\\\n\\\\\\\\n Reviewed by Tim Horton.\\\\\\\\n\\\\\\\\n In r257214, we split out the context menu hint preview container view into two views: one for drag and drop, and\\\\\\\\n another for the context menu hint. The container view used for both drag and drop previews was removed under\\\\\\\\n -cleanUpDragSourceSessionState, which is invoked after both drag and drop sessions have ended; however, in the\\\\\\\\n case of a drop in editable content where the drop preview is delayed, the drop animation can end up finishing\\\\\\\\n after -cleanUpDragSourceSessionState is invoked. This means we end
up prematurely unparenting the preview\\\\\\\\n container, which results in a broken drop animation.\\\\\\\\n\\\\\\\\n To fix this, split the drag and drop container views further, into separate container views for dragging and for\\\\\\\\n dropping. The drag preview container will continue to be removed under -cleanUpDragSourceSessionState, and the\\\\\\\\n drop preview container will now be removed under the delegate call to -dropInteraction:concludeDrop:, which is\\\\\\\\n invoked by UIKit after all drop previews are finished animating.\\\\\\\\n\\\\\\\\n Covered by adding additional test assertions while running existing API tests (see Tools/ChangeLog for more\\\\\\\\n details).\\\\\\\\n\\\\\\\\n * UIProcess/ios/WKContentViewInteraction.h:\\\\\\\\n * UIProcess/ios/WKContentViewInteraction.mm:\\\\\\\\n (-[WKContentView _createPreviewContainerWithLayerName:]):\\\\\\\\n\\\\\
\\\n Pull out common logic for creating and setting up a preview container view into a helper method. This is used by\\\\\\\\n the three methods below, which ensure container views for each of the types of previews we create when showing\\\\\\\\n the context menu, dragging an element, and dropping.\\\\\\\\n\\\\\\\\n (-[WKContentView containerForDropPreviews]):\\\\\\\\n (-[WKContentView containerForDragPreviews]):\\\\\\\\n (-[WKContentView containerForContextMenuHintPreviews]):\\\\\\\\n\\\\\\\\n Add a third preview container view for drop previews, and factor duplicated code in these three methods into a\\\\\\\\n common helper (see above).\\\\\\\\n\\\\\\\\n (-[WKContentView _hideTargetedPreviewContainerViews]):\\\\\\\\n (-[WKContentView _deliverDelayedDropPreviewIfPossible:]):\\\\\\\\n\\\\\\\\n Instead of using the container for drag previews, use the container for
drop previews.\\\\\\\\n\\\\\\\\n (-[WKContentView dropInteraction:concludeDrop:]):\\\\\\\\n\\\\\\\\n Remove the drop preview container after the drop has concluded (i.e. all animations are complete).\\\\\\\\n\\\\\\\\n b\\\\\\\\\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Cherry-pick r258530. rdar://problem/60453086\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\\\\\\\\\n <rdar://problem/60453086>\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Reviewed by Darin Adler.\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n Alternative fix for Bug 209149 based on comments from Darin.\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::clearForHost):\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\\\\\\\\\n \\
\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258530 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n 2020-03-16 Chris Dumez <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\\\\\\\\\n <rdar://problem/60453086>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Darin Adler.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Alternative fix for Bug 209149 based on comments from Darin.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::clearForHost):\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n b\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258521. rdar://problem/60453086\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60453086>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Alex Christensen.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Make sure WebCookieCache::pruneCacheIfNecessary() keeps alive the host String it is passing\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n to WebCookieCache::clearForHost(). Previously, it was merely deferencing a HashSet iterator\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n and passing that to clearForHost(). However, clearForHost() would then drop the String from\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\n the HashSet and the host would no longer be valid.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Change covered by new API test.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Tools:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Add API test coverage.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * TestWebKitAPI/Tests/WebKitCocoa/CookiePrivateBrowsing.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (TEST):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258521 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\n 2020-03-16 Chris Dumez <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Crash under WebCookieCache::clearForHost()\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209149\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60453086>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Alex Christensen.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Make sure WebCookieCache::pruneCacheIfNecessary() keeps alive the host String it is passing\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n to WebCookieCache::clearForHost(). Previously, it was merely deferencing a HashSet iterator\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n and passing that to clearForHost(). However, clearForHost() would then drop the String from\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n the HashSet and the host would no longer be valid.\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Change covered by new API test.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebCookieCache.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebCookieCache::pruneCacheIfNecessary):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n b\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'2020-03-30 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258456. rdar://problem/59931477\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Clean up sandbox violations found during testing\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209096\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/59931477>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Geoffrey Garen.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Remove telemetry from some items, and allow access to some IOKit properties\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n needed for media playback on macOS and iOS.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258456 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-13 Brent Fulgham <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Clean up sandbox violations found during testing\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209096\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/59931477>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Geoffrey Garen.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Remove telemetry from some items, and allow access to some IOKit properties\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n needed for media playback on macOS and iOS.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n b"2020-03-24 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258476. rdar://problem/60839077\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Add missing checks needed for AppBound Quirk\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209117\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60460097>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by John Wilander.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n The checks for the \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' flag added in r258101 was incomplete.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebCore:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Two additional call sites need to check the state of the flag.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * bindings/js/ScriptController.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebCore::ScriptController::executeScriptInWorld): Add missing check for the quirk.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * loader/FrameLoaderClient.h: Add new API for the \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsIn
AppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n debug flag.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * page/Frame.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebCore::Frame::injectUserScriptImmediately): Ditto.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n These changes let the WebFrameLoaderClient report the quirk state to WebCore code.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebFrameLoaderClient::needsInAppBrowserPrivacyQuirks): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebPage.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebPage::needsInAppBrowserPrivacyQuirks const): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258476 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-14 Brent Fulgham <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Add missing checks needed for AppBound Quirk\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209117\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60460097>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by John Wilander.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n The checks for the \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' flag added in r258101 was incomplete.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n These changes let the WebFrameLoaderClient report the quirk state to WebCore code.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebFrameLoaderClient::needsInAppBrowserPrivacyQuirks): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebCoreSupport/WebFrameLoaderClient.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/WebPage/WebPage.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n
(WebKit::WebPage::needsInAppBrowserPrivacyQuirks const): Added.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n"2020-03-17 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258515. rdar://problem/60551856\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n [Cocoa] Crash under -[WKPreferenceObserver init]\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209145\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\n Reviewed by Darin Adler.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Handle the case when calling [NSUserDefaults initWithSuiteName:] did not succeed.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n No new tests, since I have not been able to reproduce.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (-[WKPreferenceObserver init]):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n g
it-svn-id: https://svn.webkit.org/repository/webkit/trunk@258515 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-16 Per Arne Vollan <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n [Cocoa] Crash under -[WKPreferenceObserver init]\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209145\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Darin Adler.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Handle the case when calling [NSUserDefaults initWithSuiteName:] di
d not succeed.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n No new tests, since I have not been able to reproduce.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (-[WKPreferenceObserver init]):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Cherry-pick r258518. rdar://problem/60517387\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n [macOS] Accessibility sandbox regressions\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209065\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebCore/PAL:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Add Accessibility notification name.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * pal/spi/cocoa/NSAccessibilitySPI.h:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60202450>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n When Accessibility is enabled, the WebContent process needs access to the preference service, since Accessibility\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\n is relying on some advanced features of the service. Also, when CF prefs direct mode is enabled, the WebContent\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n sandbox needs to explicitly allow reading of the various plist files.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Tools:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * TestWebKitAPI/Tests/WebKit/EnableAccessibility.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (TEST):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * TestWebKitAPI/Tests/WebKit/GrantA
ccessToPreferencesService.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (TEST):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258518 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n 2020-03-16 Per Arne Vollan <[email protected]>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n [macOS] Accessibility sandbox regressions\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209065\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n <rdar://problem/60202450>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n When Accessibility is enabled, the WebContent process needs ac
cess to the preference service, since Accessibility\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n is relying on some advanced features of the service. Also, when CF prefs direct mode is enabled, the WebContent\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n sandbox needs to explicitly allow reading of the various plist files.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * WebProcess/com.apple.WebProcess.sb.in:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Cherry-pick r258359. rdar://problem/60517387\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n [macOS] _AXSApplicationAccessibilityEnabled should not be called\\\\\\\\
\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=208953\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Source/WebCore:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n The function _AXSApplicationAccessibilityEnabled and the notification kAXSApplicationAccessibilityEnabledNotification\\\\\\\\\\\\\\\\n exist on macOS, but they do not have the same behavior as on iOS, and should not be used in the same way. Using this\\\\\\\\\\\\\\\\n function and notification on macOS was introduced in <https://bugs.webkit.org/show_bug.cgi?id=208690>, and this patch\\\\\\\\\\\\\\\\n partially reverts this behavior.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n API test: WebKit.IsRemoteUIAppForAccessibility\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * testing/Internals.cpp:\\\\\\\\\\\\\\\\n (WebCore::Internals::isRemoteUIAppForAccessibility):\\\\\\\\\\\\\\\\n * testing/Internals.h:\\\\\\\\\\\\\\\\n *
testing/Internals.idl:\\\\\\\\\\\\\\\\n * testing/Internals.mm:\\\\\\\\\\\\\\\\n (WebCore::Internals::isRemoteUIAppForAccessibility):\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Source/WebCore/PAL:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Declare method to check if the process is a remote UI app for accessibility.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * pal/spi/cocoa/NSAccessibilitySPI.h:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Source/WebKit:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n On macOS, stop using the function _AXSApplicationAccessibilityEnabled and listening to the notification\\\\\\\\\\\\\\\\n kAXSApplicationAccessibilityEnabledNotification, since they do not have the same behavior as on iOS.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::platformInitializeWebProcess):\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\\\\\\\\\n
(WebKit::WebProcessPool::unregisterNotificationObservers):\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcessProxy::unblockAccessibilityServerIfNeeded):\\\\\\\\\\\\\\\\n * WebProcess/cocoa/WebProcessCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcess::platformInitializeProcess):\\\\\\\\\\\\\\\\n (WebKit::WebProcess::unblockAccessibilityServer):\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Tools:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258359 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n 2020-03-12 Per Arne Vollan <[email protected]>\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n [macOS] _AXSApplicationAccessibilityEnabled should not be called\\\\\\\\\\\\\\\\n https://bugs.webkit.o
rg/show_bug.cgi?id=208953\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n On macOS, stop using the function _AXSApplicationAccessibilityEnabled and listening to the notification\\\\\\\\\\\\\\\\n kAXSApplicationAccessibilityEnabledNotification, since they do not have the same behavior as on iOS.\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::platformInitializeWebProcess):\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::registerNotificationObservers):\\\\\\\\\\\\\\\\n (WebKit::WebProcessPool::unregisterNotificationObservers):\\\\\\\\\\\\\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\\\\\\\\\\\\\n (WebKit::WebProcessProxy::unblockAccessibilityServerIfNeeded):\\\\\\\\\\\\\\\\n * WebProcess/cocoa/WebProcessCocoa.mm:\\\\\\\\\\
\\\\\\n (WebKit::WebProcess::platformInitializeProcess):\\\\\\\\\\\\\\\\n (WebKit::WebProcess::unblockAccessibilityServer):\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\\\\\n\\\\\\\\n Cherry-pick r258557. rdar://problem/60517387\\\\\\\\n\\\\\\\\n [Cocoa] Disable CF prefs direct mode\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209166\\\\\\\\n <rdar://problem/60517387>\\\\\\\\n\\\\\\\\n Reviewed by Brent Fulgham.\\\\\\\\n\\\\\\\\n Revert <https://trac.webkit.org/changeset/258064> by disabling the CF prefs direct mode feature,\\\\\\\\n since it caused performance regressions.\\\\\\\\n\\\\\\\\n Source/WebKit:\\\\\\\\n\\\\\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\\\\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\\\\\\\n (WebKit::XPCServiceMain):\\\\\\\\n
* UIProcess/Cocoa/PreferenceObserver.mm:\\\\\\\\n * UIProcess/Cocoa/WebPageProxyCocoa.mm:\\\\\\\\n (WebKit::WebPageProxy::grantAccessToPreferenceService):\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\\\\\n * UIProcess/WebProcessPool.h:\\\\\\\\n * UIProcess/WebProcessProxy.h:\\\\\\\\n * WebProcess/WebProcess.h:\\\\\\\\n * WebProcess/WebProcess.messages.in:\\\\\\\\n\\\\\\\\n Source/WTF:\\\\\\\\n\\\\\\\\n * wtf/PlatformEnable.h:\\\\\\\\n\\\\\\\\n\\\\\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258557 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\\\\\n\\\\\\\\n 2020-03-17 Per Arne Vollan <[email protected]>\\\\\\\\n\\\\\\\\n [Cocoa] Disable CF prefs direct mode\\\\\\\\n https://bugs.webkit.org/show_bug.cgi?id=209166\\\\\\\\n <rdar://problem/60517387>\\\\\\\\n\\\\\\
\\n Reviewed by Brent Fulgham.\\\\\\\\n\\\\\\\\n Revert <https://trac.webkit.org/changeset/258064> by disabling the CF prefs direct mode feature,\\\\\\\\n since it caused performance regressions.\\\\\\\\n\\\\\\\\n * Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:\\\\\\\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\\\\\\\n (WebKit::XPCServiceMain):\\\\\\\\n * UIProcess/Cocoa/PreferenceObserver.mm:\\\\\\\\n * UIProcess/Cocoa/WebPageProxyCocoa.mm:\\\\\\\\n (WebKit::WebPageProxy::grantAccessToPreferenceService):\\\\\\\\n * UIProcess/Cocoa/WebProcessPoolCocoa.mm:\\\\\\\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\\\\\\\n * UIProcess/WebProcessPool.h:\\\\\\\\n * UIProcess/WebProcessProxy.h:\\\\\\\\n * WebProcess/WebProcess.h:\\\\\\\\n
* WebProcess/WebProcess.messages.in:\\\\\\\\n\\\\\\\\n\\\\\\\'2020-03-17 Alan Coon <[email protected]>\\\\n\\\\n Cherry-pick r258512. rdar://problem/60517387\\\\n\\\\n [Cocoa] Only set CF prefs direct mode for the WebContent process\\\\n https://bugs.webkit.org/show_bug.cgi?id=209091\\\\n <rdar://problem/60337842>\\\\n\\\\n Reviewed by Brent Fulgham.\\\\n\\\\n Currently, we enable CF prefs direct mode in XPCServiceMain. This is incorrect, it should only be enabled\\\\n for the WebContent process.\\\\n\\\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\\\n (WebKit::XPCServiceMain):\\\\n\\\\n\\\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258512 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\\\n\\\\n 2020-03-16 Per Arne Vollan <[email protected]>\\\\n\\\\n [Cocoa] Only set CF prefs direct mode for the WebContent process\\\\n
https://bugs.webkit.org/show_bug.cgi?id=209091\\\\n <rdar://problem/60337842>\\\\n\\\\n Reviewed by Brent Fulgham.\\\\n\\\\n Currently, we enable CF prefs direct mode in XPCServiceMain. This is incorrect, it should only be enabled\\\\n for the WebContent process.\\\\n\\\\n * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:\\\\n (WebKit::XPCServiceMain):\\\\n\\\\n\\\'2020-03-11 Russell Epstein <[email protected]>\\n\\n Cherry-pick r258304. rdar://problem/60351239\\n\\n [macOS] Register with accessibility when the WebContent process starts\\n https://bugs.webkit.org/show_bug.cgi?id=208960\\n\\n Reviewed by Brent Fulgham.\\n\\n When we reenabled CF prefs direct mode in <https://bugs.webkit.org/show_bug.cgi?id=208690>, we started to register\\n with accessibility when we received a message to do so from the
UI process. This would typically happen when the user\\n enabled accessibility. On macOS, this notification does not work the same way as on iOS, and it is assumed that\\n accessibility should always be enabled. Therefore we should go back to registering with accessibility on startup of\\n the WebContent process on macOS.\\n\\n * WebProcess/cocoa/WebProcessCocoa.mm:\\n (WebKit::WebProcess::platformInitializeProcess):\\n (WebKit::WebProcess::unblockAccessibilityServer):\\n\\n\\n\\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258304 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\n\\n 2020-03-11 Per Arne Vollan <[email protected]>\\n\\n [macOS] Register with accessibility when the WebContent process starts\\n https://bugs.webkit.org/show_bug.cgi?id=208960\\n\\n Reviewed by Brent Fulgham.\\n\\n When we reenabled CF prefs direct mode in <https://bugs.webki
t.org/show_bug.cgi?id=208690>, we started to register\\n with accessibility when we received a message to do so from the UI process. This would typically happen when the user\\n enabled accessibility. On macOS, this notification does not work the same way as on iOS, and it is assumed that\\n accessibility should always be enabled. Therefore we should go back to registering with accessibility on startup of\\n the WebContent process on macOS.\\n\\n * WebProcess/cocoa/WebProcessCocoa.mm:\\n (WebKit::WebProcess::platformInitializeProcess):\\n (WebKit::WebProcess::unblockAccessibilityServer):\\n\\n\'2020-03-11 Alan Coon <[email protected]>\n\n Cherry-pick r258296. rdar://problem/60348995\n\n Add a parameter to allow ignoring app-bound domain categorization\n https://bugs.webkit.org/show_bug.cgi?id=208949\n <rdar://problem/60239187>\n\n
Reviewed by Brent Fulgham.\n\n Introduce a new parameter to ignore app-bound domain categorization\n for specific WebViews.\n\n * UIProcess/API/APIPageConfiguration.h:\n (API::PageConfiguration::ignoresAppBoundDomains const):\n (API::PageConfiguration::setIgnoresAppBoundDomains):\n * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:\n (-[WKWebViewConfiguration _ignoresAppBoundDomains]):\n (-[WKWebViewConfiguration _setIgnoresAppBoundDomains:]):\n * UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:\n * UIProcess/WebPageProxy.cpp:\n (WebKit::WebPageProxy::setIsNavigatingToAppBoundDomain):\n\n\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258296 268f45cc-cd09-0410-ab3c-d52691b4dbfc\n\n 2020-03-11 Kate Cheney <[email protected]>\n\n Add a parameter to allow ignoring app-bound domain categorization\n https://bugs.webkit.org/show_
bug.cgi?id=208949\n <rdar://problem/60239187>\n\n Reviewed by Brent Fulgham.\n\n Introduce a new parameter to ignore app-bound domain categorization\n for specific WebViews.\n\n * UIProcess/API/APIPageConfiguration.h:\n (API::PageConfiguration::ignoresAppBoundDomains const):\n (API::PageConfiguration::setIgnoresAppBoundDomains):\n * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:\n (-[WKWebViewConfiguration _ignoresAppBoundDomains]):\n (-[WKWebViewConfiguration _setIgnoresAppBoundDomains:]):\n * UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:\n * UIProcess/WebPageProxy.cpp:\n (WebKit::WebPageProxy::setIsNavigatingToAppBoundDomain):\n\n'2020-03-11 Alan Coon <[email protected]>
- Cherry-pick r258296. rdar://problem/60348995
-
- Add a parameter to allow ignoring app-bound domain categorization
- https://bugs.webkit.org/show_bug.cgi?id=208949
- <rdar://problem/60239187>
-
- Reviewed by Brent Fulgham.
-
- Introduce a new parameter to ignore app-bound domain categorization
- for specific WebViews.
-
- * UIProcess/API/APIPageConfiguration.h:
- (API::PageConfiguration::ignoresAppBoundDomains const):
- (API::PageConfiguration::setIgnoresAppBoundDomains):
- * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
- (-[WKWebViewConfiguration _ignoresAppBoundDomains]):
- (-[WKWebViewConfiguration _setIgnoresAppBoundDomains:]):
- * UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:
- * UIProcess/WebPageProxy.cpp:
- (WebKit::WebPageProxy::setIsNavigatingToAppBoundDomain):
-
-
- git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258296 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
- 2020-03-11 Kate Cheney <[email protected]>
-
- Add a parameter to allow ignoring app-bound domain categorization
- https://bugs.webkit.org/show_bug.cgi?id=208949
- <rdar://problem/60239187>
-
- Reviewed by Brent Fulgham.
-
- Introduce a new parameter to ignore app-bound domain categorization
- for specific WebViews.
-
- * UIProcess/API/APIPageConfiguration.h:
- (API::PageConfiguration::ignoresAppBoundDomains const):
- (API::PageConfiguration::setIgnoresAppBoundDomains):
- * UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
- (-[WKWebViewConfiguration _ignoresAppBoundDomains]):
- (-[WKWebViewConfiguration _setIgnoresAppBoundDomains:]):
- * UIProcess/API/Cocoa/WKWebViewConfigurationPrivate.h:
- * UIProcess/WebPageProxy.cpp:
- (WebKit::WebPageProxy::setIsNavigatingToAppBoundDomain):
-
-2020-03-11 Alan Coon <[email protected]>
-
Cherry-pick r258289. rdar://problem/60341123
[macOS] Crash under WebKit::WebProcessPool::platformInitialize()
