Modified: branches/safari-610.1.7-branch/LayoutTests/ChangeLog (259227 => 259228)
--- branches/safari-610.1.7-branch/LayoutTests/ChangeLog 2020-03-30 20:56:51 UTC (rev 259227)
+++ branches/safari-610.1.7-branch/LayoutTests/ChangeLog 2020-03-30 20:56:55 UTC (rev 259228)
@@ -1,16 +1,5 @@
-b'2020-03-30 Alan Coon <[email protected]>\n\n Cherry-pick r258282. rdar://problem/58874371\n\n icloud.com Notes text in titles and headings is distorted\n https://bugs.webkit.org/show_bug.cgi?id=208908\n <rdar://problem/58874371>\n \n Reviewed by Zalan Bujtas.\n \n Source/WebCore:\n \n icloud.com Notes determines if a font has finished loading by measuring it repeatedly.\n Depending on the state of the page, we may slice the text differently in different\n circumstances. These slices are all supposed to sum together equivalently, but\n floating point precision may cause the results to be slightly off.\n \n WidthIterator::applyFontTransforms() was summing a large list of numbers, and then\n subtracting the same large list of numbers. A more robust design would be to sum\n it twice, and then subtract the two sums.\n \n Test: fast/text/shaping-width-precision.html\n \n * platform/graphics/Wid
thIterator.cpp:\n (WebCore::WidthIterator::applyFontTransforms):\n \n LayoutTests:\n \n * fast/text/shaping-width-precision-expected.txt: Added.\n * fast/text/shaping-width-precision.html: Added.\n \n \n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258282 268f45cc-cd09-0410-ab3c-d52691b4dbfc\n\n 2020-03-11 Myles C. Maxfield <[email protected]>\n\n icloud.com Notes text in titles and headings is distorted\n https://bugs.webkit.org/show_bug.cgi?id=208908\n <rdar://problem/58874371>\n\n Reviewed by Zalan Bujtas.\n\n * fast/text/shaping-width-precision-expected.txt: Added.\n * fast/text/shaping-width-precision.html: Added.\n\n'2020-03-07 Zalan Bujtas <[email protected]>
+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 sce
nario: 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 visibl
e 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` in
stead.\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_lastLayerTreeTransactionIdAndPageScaleBeforeScalingP
age`.\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 l
ittle\n https://bugs.webkit.org/show_bug.cgi?id=209356\n <rdar://problem/60563952>\n\n Reviewed by Tim Horton.\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 b\'2020-03-30 Alan Coon <[email protected]>\\n\\n Cherry-pick r258282. rdar://problem/58874371\\n\\n icloud.com Notes text in titles and headings is distorted\\n https://bugs.webkit.org/show_bug.cgi?id=208908\\n <rdar://problem/58874371>\\n \\n Reviewed by Zalan Bujtas.\\n \\n Source/WebCore:\\n \\n icloud.com Notes determines if a font has finished loading by measuring it repeatedly.\\n Depending on the state of the page, we may slice the text differently in different\\n circumstances. These slices are all supposed to sum together equivalently, but\\n floating point precision may cause the results to be
slightly off.\\n \\n WidthIterator::applyFontTransforms() was summing a large list of numbers, and then\\n subtracting the same large list of numbers. A more robust design would be to sum\\n it twice, and then subtract the two sums.\\n \\n Test: fast/text/shaping-width-precision.html\\n \\n * platform/graphics/WidthIterator.cpp:\\n (WebCore::WidthIterator::applyFontTransforms):\\n \\n LayoutTests:\\n \\n * fast/text/shaping-width-precision-expected.txt: Added.\\n * fast/text/shaping-width-precision.html: Added.\\n \\n \\n git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258282 268f45cc-cd09-0410-ab3c-d52691b4dbfc\\n\\n 2020-03-11 Myles C. Maxfield <[email protected]>\\n\\n icloud.com Notes text in titles and headings is distorted\\n https://bugs.webkit.org/show_bug.cgi?id=208908\\n <rdar://problem/58874371>\\n\\n Reviewed by Zalan Bujtas.\\n\\n * fa
st/text/shaping-width-precision-expected.txt: Added.\\n * fast/text/shaping-width-precision.html: Added.\\n\\n\'2020-03-07 Zalan Bujtas <[email protected]>\n\n [LFC][Verification] Use the table wrapper box\'s offset when matching out-of-flow tables\n https://bugs.webkit.org/show_bug.cgi?id=208769\n <rdar://problem/60191322>\n\n Reviewed by Antti Koivisto.\n\n * fast/layoutformattingcontext/absolute-positioned-simple-table2-expected.html: Added.\n * fast/layoutformattingcontext/absolute-positioned-simple-table2.html: Added.\n\n'2020-03-07 Simon Fraser <[email protected]>
- [LFC][Verification] Use the table wrapper box's offset when matching out-of-flow tables
- https://bugs.webkit.org/show_bug.cgi?id=208769
- <rdar://problem/60191322>
-
- Reviewed by Antti Koivisto.
-
- * fast/layoutformattingcontext/absolute-positioned-simple-table2-expected.html: Added.
- * fast/layoutformattingcontext/absolute-positioned-simple-table2.html: Added.
-
-2020-03-07 Simon Fraser <[email protected]>
-
Unreviewed test gardening.
Land results with new console log line numbers.
Modified: branches/safari-610.1.7-branch/Source/WebKit/ChangeLog (259227 => 259228)
--- branches/safari-610.1.7-branch/Source/WebKit/ChangeLog 2020-03-30 20:56:51 UTC (rev 259227)
+++ branches/safari-610.1.7-branch/Source/WebKit/ChangeLog 2020-03-30 20:56:55 UTC (rev 259228)
@@ -1,38 +1,5 @@
-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 brok
en 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 c
ontext 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 _deliverDelayedD
ropPreviewIfPossible:]):\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 <cd
[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(). Previous
ly, 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::pru
neCacheIfNecessary() 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 \\\\\\\\\\\\\\\'Need
sInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\'\\\\\\\\\\\\\\\\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 <bfu
[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::needsInAppBrowserPri
vacyQuirks 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 <pvollan@appl
e.com>\\\\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 s
hould 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.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::registerNotificationObservers):\\n (WebKit::WebProcessPool::unregisterNotificationObservers):\\n * UIProcess/Cocoa/WebProcessProxyCocoa.mm:\\n (WebKit::WebPro
cessProxy::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/WebPag
eProxyCocoa.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]>
+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 sce
nario: 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 visibl
e 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` in
stead.\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_lastLayerTreeTransactionIdAndPageScaleBeforeScalingP
age`.\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 l
ittle\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 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 outs
ide 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 `shrinkTo
FitContent` 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::platfo
rmDidScalePage):\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 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/60
560831>\\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 pre
views, 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 _invokeDropAnimati
onCompletionBlocksAndConcludeDrop]):\\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 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'NeedsInAppBrowserPrivacyQuirks\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n debug flag.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n * page/Frame.cpp:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n (WebCore::Frame::injectUserScriptImmediately): Ditto.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n Source/Web
Kit:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\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/PreferenceObs
erver.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/WebCore:\\\\n\\\\n The function _AXSAppli
cationAccessibilityEnabled 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, st
op 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-d52691b4dbf
c\\\\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::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::W
ebPageProxy::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 * Resou
rces/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 Rev
iewed 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::XPC
ServiceMain):\n\n'2020-03-11 Russell Epstein <[email protected]>
- Cherry-pick r258512. rdar://problem/60517387
-
- [Cocoa] Only set CF prefs direct mode for the WebContent process
- https://bugs.webkit.org/show_bug.cgi?id=209091
- <rdar://problem/60337842>
-
- Reviewed by Brent Fulgham.
-
- Currently, we enable CF prefs direct mode in XPCServiceMain. This is incorrect, it should only be enabled
- for the WebContent process.
-
- * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:
- (WebKit::XPCServiceMain):
-
-
- git-svn-id: https://svn.webkit.org/repository/webkit/trunk@258512 268f45cc-cd09-0410-ab3c-d52691b4dbfc
-
- 2020-03-16 Per Arne Vollan <[email protected]>
-
- [Cocoa] Only set CF prefs direct mode for the WebContent process
- https://bugs.webkit.org/show_bug.cgi?id=209091
- <rdar://problem/60337842>
-
- Reviewed by Brent Fulgham.
-
- Currently, we enable CF prefs direct mode in XPCServiceMain. This is incorrect, it should only be enabled
- for the WebContent process.
-
- * Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:
- (WebKit::XPCServiceMain):
-
-2020-03-11 Russell Epstein <[email protected]>
-
Cherry-pick r258304. rdar://problem/60351239
[macOS] Register with accessibility when the WebContent process starts
Modified: branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm (259227 => 259228)
--- branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2020-03-30 20:56:51 UTC (rev 259227)
+++ branches/safari-610.1.7-branch/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2020-03-30 20:56:55 UTC (rev 259228)
@@ -3441,8 +3441,7 @@
m_page->updateRendering();
#if ENABLE(VIEWPORT_RESIZING)
- if (immediatelyShrinkToFitContent())
- viewportConfigurationChanged();
+ shrinkToFitContent();
#endif
m_drawingArea->scheduleRenderingUpdate();
@@ -3527,48 +3526,34 @@
#if ENABLE(VIEWPORT_RESIZING)
-void WebPage::scheduleShrinkToFitContent()
+void WebPage::shrinkToFitContent(ZoomToInitialScale zoomToInitialScale)
{
if (m_isClosed)
return;
- m_shrinkToFitContentTimer.restart();
-}
-
-void WebPage::shrinkToFitContentTimerFired()
-{
- if (immediatelyShrinkToFitContent())
- viewportConfigurationChanged(ZoomToInitialScale::Yes);
-}
-
-bool WebPage::immediatelyShrinkToFitContent()
-{
- if (m_isClosed)
- return false;
-
if (!m_page->settings().allowViewportShrinkToFitContent())
- return false;
+ return;
if (m_useTestingViewportConfiguration)
- return false;
+ return;
if (!shouldIgnoreMetaViewport())
- return false;
+ return;
if (!m_viewportConfiguration.viewportArguments().shrinkToFit)
- return false;
+ return;
if (m_viewportConfiguration.canIgnoreScalingConstraints())
- return false;
+ return;
auto mainFrame = makeRefPtr(m_mainFrame->coreFrame());
if (!mainFrame)
- return false;
+ return;
auto view = makeRefPtr(mainFrame->view());
auto mainDocument = makeRefPtr(mainFrame->document());
if (!view || !mainDocument)
- return false;
+ return;
mainDocument->updateLayout();
@@ -3585,7 +3570,7 @@
int originalLayoutWidth = m_viewportConfiguration.layoutWidth();
int originalHorizontalOverflowAmount = originalContentWidth - originalViewWidth;
if (originalHorizontalOverflowAmount <= toleratedHorizontalScrollingDistance || originalLayoutWidth >= maximumExpandedLayoutWidth || originalContentWidth <= originalViewWidth || originalContentWidth > maximumContentWidthBeforeAvoidingShrinkToFit)
- return false;
+ return;
auto changeMinimumEffectiveDeviceWidth = [this, mainDocument] (int targetLayoutWidth) -> bool {
if (m_viewportConfiguration.setMinimumEffectiveDeviceWidth(targetLayoutWidth)) {
@@ -3605,7 +3590,7 @@
// FIXME (197429): Consider additionally logging an error message to the console if a responsive meta viewport tag was used.
RELEASE_LOG(ViewportSizing, "Shrink-to-fit: content width %d => %d; layout width %d => %d", originalContentWidth, view->contentsWidth(), originalLayoutWidth, m_viewportConfiguration.layoutWidth());
- return true;
+ viewportConfigurationChanged(zoomToInitialScale);
}
#endif // ENABLE(VIEWPORT_RESIZING)
@@ -3816,22 +3801,38 @@
IntPoint scrollPosition = roundedIntPoint(visibleContentRectUpdateInfo.unobscuredContentRect().location());
- bool hasSetPageScale = false;
- if (scaleFromUIProcess) {
- m_scaleWasSetByUIProcess = true;
- m_hasStablePageScaleFactor = m_isInStableState;
+ bool pageHasBeenScaledSinceLastLayerTreeCommitThatChangedPageScale = ([&] {
+ if (!m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage)
+ return false;
- m_dynamicSizeUpdateHistory.clear();
+ if (areEssentiallyEqualAsFloat(scaleToUse, m_page->pageScaleFactor()))
+ return false;
- m_page->setPageScaleFactor(scaleFromUIProcess.value(), scrollPosition, m_isInStableState);
- hasSetPageScale = true;
- send(Messages::WebPageProxy::PageScaleFactorDidChange(scaleFromUIProcess.value()));
+ auto [transactionIdBeforeScalingPage, scaleBeforeScalingPage] = *m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage;
+ if (!areEssentiallyEqualAsFloat(scaleBeforeScalingPage, scaleToUse))
+ return false;
+
+ return transactionIdBeforeScalingPage >= visibleContentRectUpdateInfo.lastLayerTreeTransactionID();
+ })();
+
+ if (!pageHasBeenScaledSinceLastLayerTreeCommitThatChangedPageScale) {
+ bool hasSetPageScale = false;
+ if (scaleFromUIProcess) {
+ m_scaleWasSetByUIProcess = true;
+ m_hasStablePageScaleFactor = m_isInStableState;
+
+ m_dynamicSizeUpdateHistory.clear();
+
+ m_page->setPageScaleFactor(scaleFromUIProcess.value(), scrollPosition, m_isInStableState);
+ hasSetPageScale = true;
+ send(Messages::WebPageProxy::PageScaleFactorDidChange(scaleFromUIProcess.value()));
+ }
+
+ if (!hasSetPageScale && m_isInStableState) {
+ m_page->setPageScaleFactor(scaleToUse, scrollPosition, true);
+ hasSetPageScale = true;
+ }
}
-
- if (!hasSetPageScale && m_isInStableState) {
- m_page->setPageScaleFactor(scaleToUse, scrollPosition, true);
- hasSetPageScale = true;
- }
auto& frame = m_page->mainFrame();
FrameView& frameView = *frame.view();
@@ -4248,6 +4249,12 @@
scheduleFullEditorStateUpdate();
}
+void WebPage::platformDidScalePage()
+{
+ auto transactionID = downcast<RemoteLayerTreeDrawingArea>(*m_drawingArea).lastCommittedTransactionID();
+ m_lastLayerTreeTransactionIdAndPageScaleBeforeScalingPage = {{ transactionID, m_lastTransactionPageScaleFactor }};
+}
+
#if USE(QUICK_LOOK)
void WebPage::didStartLoadForQuickLookDocumentInMainFrame(const String& fileName, const String& uti)
