Timeline

Mar 9, 2019:

11:20 PM SVG properties edited by Said Abou-Hallawa

(diff)

10:46 PM SVG properties edited by Said Abou-Hallawa

(diff)

9:52 PM Changeset in webkit [242685] by Simon Fraser

• 2 edits in trunk/LayoutTests

[iOS Simulator] LayoutTest/scrollingcoordinator/ios/nested-fixed-layer-positions.html is flaky fail
​https://bugs.webkit.org/show_bug.cgi?id=171628

Unreviewed test gardening.

I can't reproduce flakiness for this test. Let's see if it's fixed.

• platform/ios-wk2/TestExpectations:

9:52 PM Changeset in webkit [242684] by Simon Fraser

• 3 edits in trunk/LayoutTests

[ios-simulator WK2] LayoutTest scrollingcoordinator/ios/non-stable-viewport-scroll.html is a flaky failure
​https://bugs.webkit.org/show_bug.cgi?id=168924

Unreviewed test gardening.

Let's try a new expectation for this test (it's non-flakey for me for 100 iterations).

• platform/ios-wk2/TestExpectations:
• scrollingcoordinator/ios/non-stable-viewport-scroll-expected.txt:

9:52 PM Changeset in webkit [242683] by Simon Fraser

• 2 edits
  2 adds in trunk/LayoutTests

Add a test for scrolling tree adjustment of fixed layers (r242601)
​https://bugs.webkit.org/show_bug.cgi?id=195521

Reviewed by Sam Weinig.

This test sets the "unstable" scrolling state (as if the user is actively scrolling) and scrolls,
then changes style to trigger a scrolling tree commit with a changed offset for a fixed layer.
The test shows the wrong fixed layer position before r242601.

Helpers are added to UIHelper to do the scroll, and to wrap setTimeout in an async function.
Sadly we have to wait about 120ms for the scrollbars to fade out.

• resources/ui-helper.js:

(window.UIHelper.async.delayFor):
(window.UIHelper.async.immediateScrollTo):
(window.UIHelper.async.immediateUnstableScrollTo):

• scrollingcoordinator/ios/ui-scroll-fixed-expected.html: Added.
• scrollingcoordinator/ios/ui-scroll-fixed.html: Added.

9:43 PM Changeset in webkit [242682] by Wenson Hsieh

• 3 edits
  2 adds in trunk

REGRESSION (r242551): Sporadic hangs when tapping to change selection on iOS
​https://bugs.webkit.org/show_bug.cgi?id=195475
<rdar://problem/48721153>

Reviewed by Chris Dumez.

Source/WebKit:

r242551 refactored synchronous autocorrection context requests to send an async IPC message and then use
waitForAndDispatchImmediately, instead of calling sendSync. However, this exposes a couple of existing issues in
the implementation of waitForAndDispatchImmediately that causes sporadic IPC deadlocks when changing selection.

First, passing in InterruptWaitingIfSyncMessageArrives when synchronously waiting for an IPC message currently
does not fulfill its intended behavior of interrupting waiting when a sync message arrives. This is because sync
IPC messages, by default, may be dispatched while the receiver is waiting for a sync reply. This means that the
logic in Connection::SyncMessageState::processIncomingMessage to dispatch an incoming sync message on the main
thread will attempt to handle the incoming message by enqueueing it on the main thread, and then waking up the
client runloop (i.e. signaling m_waitForSyncReplySemaphore). This works in the case of sendSync since the sync
reply semaphore is used to block the main thread, but in the case of waitForAndDispatchImmediately, a different
m_waitForMessageCondition is used instead, so SyncMessageState::processIncomingMessage will only enqueue the
incoming sync message on the main thread, and not actually invoke it.

To fix this first issue, observe that there is pre-existing logic to enqueue the incoming message and signal
m_waitForMessageCondition in Connection::processIncomingMessage. This codepath is currently not taken because we
end up bailing early in the call to SyncMessageState::processIncomingMessage. Instead, we can move this early
return further down in the function, such that if there is an incoming sync message and we're waiting with the
InterruptWaitingIfSyncMessageArrives option, we will correctly enqueue the incoming message, wake the runloop,
and proceed to handle the incoming message.

The second issue is more subtle; consider the scenario in which we send a sync message A from the web process to
the UI process, and simultaneously, in the UI process, we schedule some work to be done on the main thread.
Let's additionally suppose that this scheduled work will send an IPC message B to the web process and
synchronously wait for a reply (in the case of this particular bug, this is the sync autocorrection context
request). What happens upon receiving sync message A is that the IPC thread in the UI process will schedule A on
the main thread; however, before the scheduled response to A is invoked, we will first invoke previously
scheduled work that attempts to block synchronously until a message B is received. In summary:

1. (Web process) sends sync IPC message A to UI process.
2. (UI process) schedules some main runloop task that will block synchronously on IPC message B.
3. (UI process) receives sync IPC message A and schedules A on the main runloop.
4. (UI process) carry out the task scheduled in (2) and block on B.

...and then, the UI process and web process are now deadlocked because the UI process is waiting for B to
arrive, but the web process can't send B because it's waiting for a reply for IPC message A! To fix this second
deadlock, we first make an important observation: when using sendSync, we don't run into this problem because
immediately before sending sync IPC, we will attempt to handle any incoming sync IPC messages that have been
queued up. However, when calling waitForAndDispatchImmediately, we don't have this extra step, so a deadlock may
occur in the manner described above. To fix this, we make waitForAndDispatchImmediately behave more like
sendSync, by handling all incoming sync messages prior to blocking on an IPC response.

Test: editing/selection/ios/change-selection-by-tapping.html

• Platform/IPC/Connection.cpp:

(IPC::Connection::waitForMessage):
(IPC::Connection::processIncomingMessage):

LayoutTests:

Add a new layout test that taps to change selection 20 times in a contenteditable area and additionally
disables IPC timeout, to ensure that any IPC deadlocks will result in the test failing due to timing out.

• editing/selection/ios/change-selection-by-tapping-expected.txt: Added.
• editing/selection/ios/change-selection-by-tapping.html: Added.

9:29 PM Changeset in webkit [242681] by aestes@apple.com

• 16 edits in trunk/Source

[Apple Pay] CanMakePaymentsWithActiveCard and OpenPaymentSetup should be async messages
​https://bugs.webkit.org/show_bug.cgi?id=195526
<rdar://problem/48745636>

Reviewed by Chris Dumez.

Source/WebCore:

• Modules/applepay/PaymentCoordinatorClient.h:
• loader/EmptyClients.cpp:
• testing/MockPaymentCoordinator.cpp:

(WebCore::MockPaymentCoordinator::canMakePaymentsWithActiveCard):
(WebCore::MockPaymentCoordinator::openPaymentSetup):

• testing/MockPaymentCoordinator.h:

Source/WebKit:

• Shared/ApplePay/WebPaymentCoordinatorProxy.cpp:

(WebKit::WebPaymentCoordinatorProxy::canMakePaymentsWithActiveCard):
(WebKit::WebPaymentCoordinatorProxy::openPaymentSetup):

• Shared/ApplePay/WebPaymentCoordinatorProxy.h:
• Shared/ApplePay/WebPaymentCoordinatorProxy.messages.in:
• WebProcess/ApplePay/WebPaymentCoordinator.cpp:

(WebKit::WebPaymentCoordinator::canMakePaymentsWithActiveCard):
(WebKit::WebPaymentCoordinator::openPaymentSetup):
(WebKit::generateCanMakePaymentsWithActiveCardReplyID): Deleted.
(WebKit::generateOpenPaymentSetupReplyID): Deleted.
(WebKit::WebPaymentCoordinator::canMakePaymentsWithActiveCardReply): Deleted.
(WebKit::WebPaymentCoordinator::openPaymentSetupReply): Deleted.

• WebProcess/ApplePay/WebPaymentCoordinator.h:
• WebProcess/ApplePay/WebPaymentCoordinator.messages.in:

Source/WebKitLegacy/mac:

• WebCoreSupport/WebPaymentCoordinatorClient.h:
• WebCoreSupport/WebPaymentCoordinatorClient.mm:

(WebPaymentCoordinatorClient::canMakePaymentsWithActiveCard):
(WebPaymentCoordinatorClient::openPaymentSetup):

9:28 PM Changeset in webkit [242680] by aestes@apple.com

• 3 edits in trunk/Source/WebKit

[iOS] Remove unneeded entitlements and sandbox allowances from the Networking service
​https://bugs.webkit.org/show_bug.cgi?id=195527

Reviewed by Eric Carlson.

• Configurations/Network-iOS.entitlements:
• Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb:

8:48 PM Changeset in webkit [242679] by Alan Bujtas

• 3 edits
  2 adds in trunk

[ContentChangeObserver] Click event fires immediately on hover menu at seriouseats.com
​https://bugs.webkit.org/show_bug.cgi?id=195520
<rdar://problem/48740098>

Reviewed by Simon Fraser.

Source/WebCore:

Unfortunately seriouseats has a 300ms hover intent delay to deal with accidental menupane pop-ups. This page also hides this
non-fixed width menupane using absolute positioning and negative left.

Test: fast/events/touch/ios/content-observation/move-content-from-offscreen.html

• page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::didInstallDOMTimer):
(WebCore::ContentChangeObserver::StyleChangeScope::~StyleChangeScope):
(WebCore::ContentChangeObserver::StyleChangeScope::isConsideredHidden const): Content auhtors tend to use x - 1 values (where x = 10^y)

LayoutTests:

• fast/events/touch/ios/content-observation/move-content-from-offscreen-expected.txt: Added.
• fast/events/touch/ios/content-observation/move-content-from-offscreen.html: Added.

8:34 PM Changeset in webkit [242678] by Chris Dumez

• 7 edits in trunk/Source/WebKit

Use modern async IPC with reply for device orientation permission
​https://bugs.webkit.org/show_bug.cgi?id=195529

Reviewed by Ryosuke Niwa.

• UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::requestDeviceOrientationAndMotionAccess):

• UIProcess/WebPageProxy.h:
• UIProcess/WebPageProxy.messages.in:
• WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::shouldAllowDeviceOrientationAndMotionAccess):
(WebKit::nextDeviceOrientationAndMotionPermissionCallbackID): Deleted.
(WebKit::WebPage::didReceiveDeviceOrientationAndMotionAccessDecision): Deleted.

• WebProcess/WebPage/WebPage.h:
• WebProcess/WebPage/WebPage.messages.in:

7:26 PM Changeset in webkit [242677] by Chris Dumez

• 3 edits in trunk/Source/WebCore

Add assertions to help debug crash under DOMWindowExtension::suspendForPageCache()
​https://bugs.webkit.org/show_bug.cgi?id=195488

Reviewed by Ryosuke Niwa.

Try and figure out how the document can be detached from its frame while we're suspending
DOMWindowExtensions.

• page/DOMWindow.cpp:

(WebCore::DOMWindow::willDetachDocumentFromFrame):
(WebCore::DOMWindow::suspendForPageCache):

• page/DOMWindow.h:

6:25 PM Changeset in webkit [242676] by Chris Dumez

• 26 edits in trunk/Source

Simplify DOMWindowProperty code / handling
​https://bugs.webkit.org/show_bug.cgi?id=195495

Reviewed by Ryosuke Niwa.

DOMWindowProperty code was unnecessarily complex because DOMWindowExtension inherited
from it and DOMWindowExtension needs a lot of information about the global object's
lifetime to communicate to the injected bbundle client. This subclassing is also
very confusing because a DOMWindowExtension is not a *property* on the Window object.

This patch updates DOMWindowExtension to stop subclassing DOMWindowProperty and
moves all the complexity from DOMWindowProperty to DOMWindowExtension.
DOMWindowProperty is now a very simple base class which merely has a WeakPtr to
the window and getters for the window and the frame.

• Modules/indexeddb/DOMWindowIndexedDatabase.cpp:

(WebCore::DOMWindowIndexedDatabase::DOMWindowIndexedDatabase):
(WebCore::DOMWindowIndexedDatabase::indexedDB):

• Modules/indexeddb/DOMWindowIndexedDatabase.h:

There is no reason for DOMWindowIndexedDatabase to move its IDBFactory to a
separate data member which in PageCache. Script do not run while in PageCache.
Also, frames are nulled out while in the PageCache so the indexedDB() getter
would return null anyway while in PageCache.

• css/StyleMedia.idl:
• loader/appcache/ApplicationCacheHost.cpp:

(WebCore::ApplicationCacheHost::setDOMApplicationCache):
Store a WeakPtr to the DOMApplicationCache for safety.

(WebCore::ApplicationCacheHost::dispatchDOMEvent):
Do not fire events on the DOMApplicationCache if it is frameless to maintain
previous behavior. Previously, the DOMApplicationCache would have been nulled
out when detached from its frame so we would not have fired events.

• loader/appcache/ApplicationCacheHost.h:
• loader/appcache/DOMApplicationCache.cpp:
• loader/appcache/DOMApplicationCache.h:

Remove some unnecessary complexity. The ApplicationCacheHost is owned by the
DocumentLoader, which changes on navigation. There is therefore no reason to
null out the DOMApplicationCache on the ApplicationCacheHost when its gets
detached from its frame or enters PageCache.

• page/BarProp.idl:
• page/DOMSelection.idl:
• page/DOMWindow.cpp:

(WebCore::DOMWindow::willDestroyCachedFrame):
(WebCore::DOMWindow::willDestroyDocumentInFrame):
(WebCore::DOMWindow::willDetachDocumentFromFrame):
(WebCore::DOMWindow::registerExtension):
(WebCore::DOMWindow::unregisterExtension):

(WebCore::DOMWindow::resetDOMWindowProperties): Removed.
Stop clearing some of the DOMWindow's properties when the document gets destroyed or when
the Window for the initial empty document gets reused on navigation. I think we used to
need this because DOMWindowProperty used to hold pointers to their frame. However, this
is no longer the case nowadays as DOMWindowProperty objects get their frame from their
Window.

(WebCore::DOMWindow::resetUnlessSuspendedForDocumentSuspension):
(WebCore::DOMWindow::suspendForPageCache):
(WebCore::DOMWindow::resumeFromPageCache):

• page/DOMWindow.h:
• page/DOMWindowExtension.cpp:

(WebCore::DOMWindowExtension::DOMWindowExtension):
(WebCore::DOMWindowExtension::~DOMWindowExtension):
(WebCore::DOMWindowExtension::frame const):
(WebCore::DOMWindowExtension::suspendForPageCache):
(WebCore::DOMWindowExtension::resumeFromPageCache):
(WebCore::DOMWindowExtension::willDestroyGlobalObjectInCachedFrame):
(WebCore::DOMWindowExtension::willDestroyGlobalObjectInFrame):
(WebCore::DOMWindowExtension::willDetachGlobalObjectFromFrame):

• page/DOMWindowExtension.h:
• page/DOMWindowProperty.cpp:

(WebCore::DOMWindowProperty::DOMWindowProperty):

• page/DOMWindowProperty.h:

(WebCore::DOMWindowProperty::window const):

• page/History.idl:
• page/Location.idl:
• page/Navigator.cpp:

(WebCore::Navigator::plugins):
(WebCore::Navigator::mimeTypes):

• page/PerformanceNavigation.idl:
• page/PerformanceTiming.idl:
• page/Screen.idl:
• page/VisualViewport.cpp:

(WebCore::VisualViewport::scriptExecutionContext const):

• plugins/DOMMimeTypeArray.idl:
• plugins/DOMPluginArray.idl:

4:09 PM Changeset in webkit [242675] by Alan Bujtas

• 6 edits
  2 adds in trunk

[ContentChangeObserver] Start observing for content change between touchEnd and mouseMoved start
​https://bugs.webkit.org/show_bug.cgi?id=195510
<rdar://problem/48735695>

Reviewed by Simon Fraser.

Source/WebCore:

This patch covers the observation of async changes triggered by touchStart/touchEnd (animations, timers, style recalcs).

Test: fast/events/touch/ios/content-observation/visibility-change-after-touch-end.html

• page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::didCancelTouchEvent):
(WebCore::ContentChangeObserver::adjustObservedState):

• page/ios/ContentChangeObserver.h:

(WebCore::ContentChangeObserver::setIsInBetweenTouchEndAndMouseMoved):
(WebCore::ContentChangeObserver::isInBetweenTouchEndAndMouseMoved const):
(WebCore::ContentChangeObserver::isObservingContentChanges const):

Source/WebKit:

• WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::cancelPotentialTapInFrame):

LayoutTests:

• fast/events/touch/ios/content-observation/visibility-change-after-touch-end-expected.txt: Added.
• fast/events/touch/ios/content-observation/visibility-change-after-touch-end.html: Added.

9:29 AM Changeset in webkit [242674] by rmorisset@apple.com

• 3 edits in trunk/Source/JavaScriptCore

Compilation can be shrunk by 8 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195500

Reviewed by Mark Lam.

• profiler/ProfilerCompilation.cpp:

(JSC::Profiler::Compilation::Compilation):

• profiler/ProfilerCompilation.h:

9:25 AM Changeset in webkit [242673] by rmorisset@apple.com

• 3 edits in trunk/Source/JavaScriptCore

BinarySwitch can be shrunk by 8 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195493

Reviewed by Mark Lam.

• jit/BinarySwitch.cpp:

(JSC::BinarySwitch::BinarySwitch):

• jit/BinarySwitch.h:

9:24 AM Changeset in webkit [242672] by rmorisset@apple.com

• 2 edits in trunk/Source/JavaScriptCore

AsyncStackTrace can be shrunk by 8 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195491

Reviewed by Mark Lam.

• inspector/AsyncStackTrace.h:

Mar 8, 2019:

10:28 PM Changeset in webkit [242671] by Kocsen Chung

• 7 edits in branches/safari-607.1.40.0-branch/Source

Versioning.

9:43 PM SVG properties edited by Said Abou-Hallawa

(diff)

7:02 PM SVG properties edited by Said Abou-Hallawa

(diff)

6:59 PM SVG properties edited by Said Abou-Hallawa

(diff)

6:35 PM Changeset in webkit [242670] by Simon Fraser

• 5 edits in trunk/Source/WebCore

Make it clearer which data is protected by the two locks in ScrollingTree
​https://bugs.webkit.org/show_bug.cgi?id=195501

Reviewed by Tim Horton.

Gather ScrollingTree member variables into two structs, and name the struct
members and the locks to make it clear which data is protected by each lock.

We only need to protect data read by multiple threads; these are the scrolling
thread, the event handling thread (which runs ThreadedScrollingTree::tryToHandleWheelEvent()),
and the main thread, which pokes various bits of pin/rubber-banding state.
Ideally the main thread would always push data to the scrolling thread via a commit,
but that's not what happens now.

Suspiciously, ScrollingTree::shouldHandleWheelEventSynchronously() uses the root node,
so should probably hold a lock shared with the scrolling thread (webkit.org/b/195502).

• page/scrolling/ScrollingTree.cpp:

(WebCore::ScrollingTree::shouldHandleWheelEventSynchronously):
(WebCore::ScrollingTree::commitTreeState):
(WebCore::ScrollingTree::setAsyncFrameOrOverflowScrollingEnabled):
(WebCore::ScrollingTree::setMainFrameScrollPosition):
(WebCore::ScrollingTree::eventTrackingTypeForPoint):
(WebCore::ScrollingTree::isRubberBandInProgress):
(WebCore::ScrollingTree::setMainFrameIsRubberBanding):
(WebCore::ScrollingTree::isScrollSnapInProgress):
(WebCore::ScrollingTree::setMainFrameIsScrollSnapping):
(WebCore::ScrollingTree::setMainFramePinState):
(WebCore::ScrollingTree::setCanRubberBandState):
(WebCore::ScrollingTree::setScrollPinningBehavior):
(WebCore::ScrollingTree::scrollPinningBehavior):
(WebCore::ScrollingTree::willWheelEventStartSwipeGesture):
(WebCore::ScrollingTree::latchedNode):
(WebCore::ScrollingTree::setLatchedNode):
(WebCore::ScrollingTree::clearLatchedNode):
(WebCore::ScrollingTree::scrollingTreeAsText):
(WebCore::ScrollingTree::touchActionDataAtPoint const):
(WebCore::ScrollingTree::mainFrameScrollPosition): Deleted.
(WebCore::ScrollingTree::mainFrameLayoutViewport): Deleted.
(WebCore::ScrollingTree::rubberBandsAtLeft): Deleted.
(WebCore::ScrollingTree::rubberBandsAtRight): Deleted.
(WebCore::ScrollingTree::rubberBandsAtBottom): Deleted.
(WebCore::ScrollingTree::rubberBandsAtTop): Deleted.

• page/scrolling/ScrollingTree.h:

(WebCore::ScrollingTree::hasLatchedNode const):

• page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm:

(WebCore::ScrollingTreeScrollingNodeDelegateMac::stretchAmount):

• platform/graphics/FloatPoint.h:

(WebCore::FloatPoint::isZero const):

6:35 PM Changeset in webkit [242669] by Simon Fraser

• 5 edits in trunk/Source/WebCore

Share some code that sets CALayer positions
​https://bugs.webkit.org/show_bug.cgi?id=195485

Reviewed by Zalan Bujtas.

Share some code between ScrollingTreeStickyNode and ScrollingTreeFixedNode that sets the position
of a CALayer given the top-left location.

• page/scrolling/cocoa/ScrollingTreeFixedNode.mm:

(WebCore::ScrollingTreeFixedNode::relatedNodeScrollPositionDidChange):
(WebCore::ScrollingTreeFixedNodeInternal::operator*): Deleted.

• page/scrolling/cocoa/ScrollingTreeStickyNode.mm:

(WebCore::ScrollingTreeStickyNode::relatedNodeScrollPositionDidChange):
(WebCore::ScrollingTreeStickyNodeInternal::operator*): Deleted.

• platform/graphics/cocoa/WebCoreCALayerExtras.h:
• platform/graphics/cocoa/WebCoreCALayerExtras.mm:

(-[CALayer _web_setLayerTopLeftPosition:]):

6:14 PM Changeset in webkit [242668] by bshafiei@apple.com

• 1 copy in tags/Safari-607.1.40.0.7

Tag Safari-607.1.40.0.7.

5:10 PM Changeset in webkit [242667] by mark.lam@apple.com

• 3 edits
  1 add in trunk

Stack overflow crash in JSC::JSObject::hasInstance.
​https://bugs.webkit.org/show_bug.cgi?id=195458
<rdar://problem/48710195>

Reviewed by Yusuke Suzuki.

JSTests:

• stress/stack-overflow-in-custom-hasInstance.js: Added.

Source/JavaScriptCore:

• runtime/JSObject.cpp:

(JSC::JSObject::hasInstance):

4:59 PM Changeset in webkit [242666] by Chris Dumez

• 4 edits in trunk/Source/WebKit

Enable ProcessAssertions on iOS Simulator
​https://bugs.webkit.org/show_bug.cgi?id=195479

Reviewed by Alexey Proskuryakov.

Enable ProcessAssertions on iOS Simulator. We have some layout tests timing out in the
iOS Simulator due to the WebContent process suspending. Turning on ProcessAssertions in
the iOS Simulator seems to make those tests pass.

• UIProcess/ProcessAssertion.cpp:
• UIProcess/ProcessAssertion.h:
• UIProcess/ios/ProcessAssertionIOS.mm:

4:53 PM Changeset in webkit [242665] by Ryan Haddad

• 2 edits in trunk/LayoutTests

[ iOS Simulator ] REGRESSION (r237087) Layout Test fast/viewport/ios/*-width-viewport-after-changing-view-scale.html is a flaky failure
​https://bugs.webkit.org/show_bug.cgi?id=195341

Unreviewed test gardening.

• platform/ios-wk2/TestExpectations:

4:30 PM Changeset in webkit [242664] by Chris Dumez

• 57 edits
  20 adds in trunk

Add support for Device Orientation / Motion permission API
​https://bugs.webkit.org/show_bug.cgi?id=195329
<rdar://problem/47645367>

Reviewed by Geoffrey Garen.

Source/WebCore:

Add support for Device Orientation / Motion permission API:

• ​https://github.com/w3c/deviceorientation/issues/57

Pages can add event listeners for 'deviceorientation' / 'devicemotion' events but
such events will not be fired until the page's JavaScript calls
DeviceOrientationEvent.requestPermission() / DeviceMotionEvent.requestPermission()
and the user grants the request.

The feature is currently behind an experimental feature flag, off by default.

Tests: fast/device-orientation/device-motion-request-permission-denied.html

fast/device-orientation/device-motion-request-permission-granted.html
fast/device-orientation/device-motion-request-permission-user-gesture.html
fast/device-orientation/device-orientation-request-permission-denied.html
fast/device-orientation/device-orientation-request-permission-granted.html
fast/device-orientation/device-orientation-request-permission-user-gesture.html

• CMakeLists.txt:
• DerivedSources-input.xcfilelist:
• DerivedSources-output.xcfilelist:
• DerivedSources.make:
• Sources.txt:
• WebCore.xcodeproj/project.pbxproj:
• dom/DeviceMotionEvent.h:
• dom/DeviceMotionEvent.idl:
• dom/DeviceOrientationAndMotionAccessController.cpp: Added.

(WebCore::DeviceOrientationAndMotionAccessController::DeviceOrientationAndMotionAccessController):
(WebCore::DeviceOrientationAndMotionAccessController::shouldAllowAccess):
(WebCore::DeviceOrientationAndMotionAccessController::setAccessState):

• dom/DeviceOrientationAndMotionAccessController.h: Added.

(WebCore::DeviceOrientationAndMotionAccessController::accessState const):

• dom/DeviceOrientationEvent.h:
• dom/DeviceOrientationEvent.idl:
• dom/DeviceOrientationOrMotionEvent.cpp: Added.

(WebCore::DeviceOrientationOrMotionEvent::requestPermission):

• dom/DeviceOrientationOrMotionEvent.h: Added.
• dom/DeviceOrientationOrMotionEvent.idl: Added.
• dom/DeviceOrientationOrMotionPermissionState.h: Added.
• dom/DeviceOrientationOrMotionPermissionState.idl: Added.
• dom/Document.cpp:

(WebCore::Document::deviceOrientationAndMotionAccessController):

• dom/Document.h:
• dom/Event.cpp:
• dom/MessagePort.cpp:
• dom/Microtasks.cpp:
• page/ChromeClient.h:
• page/DOMWindow.cpp:

(WebCore::DOMWindow::addEventListener):
(WebCore::DOMWindow::deviceOrientationController const):
(WebCore::DOMWindow::deviceMotionController const):
(WebCore::DOMWindow::isAllowedToUseDeviceMotionOrientation const):
(WebCore::DOMWindow::isAllowedToAddDeviceMotionOrientationListener const):
(WebCore::DOMWindow::startListeningForDeviceOrientationIfNecessary):
(WebCore::DOMWindow::stopListeningForDeviceOrientationIfNecessary):
(WebCore::DOMWindow::startListeningForDeviceMotionIfNecessary):
(WebCore::DOMWindow::stopListeningForDeviceMotionIfNecessary):
(WebCore::DOMWindow::removeEventListener):
(WebCore::DOMWindow::removeAllEventListeners):

• page/DOMWindow.h:
• page/DeviceController.cpp:

(WebCore::DeviceController::hasDeviceEventListener const):

• page/DeviceController.h:
• page/Settings.yaml:

Source/WebKit:

Add support for Device Orientation / Motion permission API:

• ​https://github.com/w3c/deviceorientation/issues/57

This adds new SPI to WKUIDelegatePrivate, until we can make this API.

• Shared/WebPreferences.yaml:
• UIProcess/API/APIUIClient.h:

(API::UIClient::shouldAllowDeviceOrientationAndMotionAccess):

• UIProcess/API/C/WKPage.cpp:

(WKPageSetPageUIClient):

• UIProcess/API/C/WKPageUIClient.h:
• UIProcess/API/Cocoa/WKUIDelegate.h:
• UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
• UIProcess/Cocoa/UIDelegate.h:
• UIProcess/Cocoa/UIDelegate.mm:

(WebKit::UIDelegate::setDelegate):
(WebKit::UIDelegate::UIClient::shouldAllowDeviceOrientationAndMotionAccess):

• UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::requestDeviceOrientationAndMotionAccess):

• UIProcess/WebPageProxy.h:
• UIProcess/WebPageProxy.messages.in:
• WebProcess/WebCoreSupport/WebChromeClient.cpp:

(WebKit::WebChromeClient::shouldAllowDeviceOrientationAndMotionAccess):

• WebProcess/WebCoreSupport/WebChromeClient.h:
• WebProcess/WebPage/WebPage.cpp:

(WebKit::nextDeviceOrientationAndMotionPermissionCallbackID):
(WebKit::WebPage::shouldAllowDeviceOrientationAndMotionAccess):
(WebKit::WebPage::didReceiveDeviceOrientationAndMotionAccessDecision):

• WebProcess/WebPage/WebPage.h:
• WebProcess/WebPage/WebPage.messages.in:

Tools:

Add test infrastructure to help test the Device Orientation / Motion permission API.

• WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
• WebKitTestRunner/InjectedBundle/TestRunner.cpp:

(WTR::TestRunner::setShouldAllowDeviceOrientationAndMotionAccess):

• WebKitTestRunner/InjectedBundle/TestRunner.h:
• WebKitTestRunner/TestController.cpp:

(WTR::shouldAllowDeviceOrientationAndMotionAccess):
(WTR::TestController::createWebViewWithOptions):
(WTR::TestController::resetStateToConsistentValues):
(WTR::TestController::handleDeviceOrientationAndMotionAccessRequest):

• WebKitTestRunner/TestController.h:

(WTR::TestController::setShouldAllowDeviceOrientationAndMotionAccess):

• WebKitTestRunner/TestInvocation.cpp:

(WTR::TestInvocation::didReceiveMessageFromInjectedBundle):

LayoutTests:

Add layout test coverage.

• TestExpectations:
• fast/device-orientation/device-motion-request-permission-denied-expected.txt: Added.
• fast/device-orientation/device-motion-request-permission-denied.html: Added.
• fast/device-orientation/device-motion-request-permission-granted-expected.txt: Added.
• fast/device-orientation/device-motion-request-permission-granted.html: Added.
• fast/device-orientation/device-motion-request-permission-user-gesture-expected.txt: Added.
• fast/device-orientation/device-motion-request-permission-user-gesture.html: Added.
• fast/device-orientation/device-orientation-request-permission-denied-expected.txt: Added.
• fast/device-orientation/device-orientation-request-permission-denied.html: Added.
• fast/device-orientation/device-orientation-request-permission-granted-expected.txt: Added.
• fast/device-orientation/device-orientation-request-permission-granted.html: Added.
• fast/device-orientation/device-orientation-request-permission-user-gesture-expected.txt: Added.
• fast/device-orientation/device-orientation-request-permission-user-gesture.html: Added.
• http/tests/events/device-orientation-motion-non-secure-context.html:
• http/tests/events/device-orientation-motion-secure-context-expected.txt:
• http/tests/events/device-orientation-motion-secure-context.html:
• platform/ios-wk2/TestExpectations:
• platform/ios/http/tests/events/device-orientation-motion-non-secure-context-expected.txt:
• platform/ios/http/tests/events/device-orientation-motion-secure-context-expected.txt:

4:17 PM Changeset in webkit [242663] by rmorisset@apple.com

• 2 edits in trunk/Source/JavaScriptCore

IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195487

Reviewed by Saam Barati.

• dfg/DFGIntegerCheckCombiningPhase.cpp:

3:58 PM Changeset in webkit [242662] by beidson@apple.com

• 3 edits in trunk/Source/WebKit

Have the UIProcess take the UnboundedNetworking assertion when downloads are in progress.
​https://bugs.webkit.org/show_bug.cgi?id=195468

Reviewed by Andy Estes.

• UIProcess/Downloads/DownloadProxyMap.cpp:

(WebKit::DownloadProxyMap::DownloadProxyMap):
(WebKit::DownloadProxyMap::createDownloadProxy): If this is the first download, and the process has the entitlement,

take the assertion.

(WebKit::DownloadProxyMap::downloadFinished):
(WebKit::DownloadProxyMap::processDidClose):

• UIProcess/Downloads/DownloadProxyMap.h:

3:51 PM Changeset in webkit [242661] by Alan Bujtas

• 4 edits
  2 adds in trunk

[ContentChangeObserver] Expand "isConsideredClickable" to descendants
​https://bugs.webkit.org/show_bug.cgi?id=195478
<rdar://problem/48724935>

Reviewed by Simon Fraser.

Source/WebCore:

In StyleChangeScope we try to figure out whether newly visible content should stick (menu panes etc) by checking if it is clickable.
This works fine as long as all the visible elements are gaining new renderers through this style update processs.
However when an element becomes visible by a change other than display: (not)none, it's not sufficient to just check the element itself,
since it might not respond to click at all, while its descendants do.
A concrete example is a max-height value change on usps.com, where the max-height is on a container (menu pane).
This container itself is not clickable while most of its children are (menu items).

Test: fast/events/touch/ios/content-observation/clickable-content-is-inside-a-container.html

• page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::StyleChangeScope::StyleChangeScope):
(WebCore::ContentChangeObserver::StyleChangeScope::~StyleChangeScope):
(WebCore::ContentChangeObserver::StyleChangeScope::isConsideredHidden const):
(WebCore::ContentChangeObserver::StyleChangeScope::isConsideredClickable const):
(WebCore::isConsideredHidden): Deleted.

• page/ios/ContentChangeObserver.h:

LayoutTests:

• fast/events/touch/ios/content-observation/clickable-content-is-inside-a-container-expected.txt: Added.
• fast/events/touch/ios/content-observation/clickable-content-is-inside-a-container.html: Added.

3:31 PM Changeset in webkit [242660] by rmorisset@apple.com

• 2 edits in trunk/Source/JavaScriptCore

TypeLocation can be shrunk by 8 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195483

Reviewed by Mark Lam.

• bytecode/TypeLocation.h:

(JSC::TypeLocation::TypeLocation):

3:24 PM Changeset in webkit [242659] by rmorisset@apple.com

• 3 edits in trunk/Source/JavaScriptCore

GetByIdStatus can be shrunk by 16 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195480

Reviewed by Saam Barati.

8 bytes from reordering fields
8 more bytes by making the enum State only use 1 byte.

• bytecode/GetByIdStatus.cpp:

(JSC::GetByIdStatus::GetByIdStatus):

• bytecode/GetByIdStatus.h:

3:20 PM Changeset in webkit [242658] by sbarati@apple.com

• 1 edit
  1 add in trunk/Tools

Add a compare-results script to compare benchmark results
​https://bugs.webkit.org/show_bug.cgi?id=195486
<rdar://problem/48723397>

Reviewed by Geoffrey Garen.

This patch adds a script to compare benchmark results using Welch's two-tailed t test.
Initially, this patch only reasons about PLT5/JetStream2/Speedometer2. It will be easy
to extend it to learn about our other benchmarks.

• Scripts/compare-results: Added.

(readJSONFile):
(detectJetStream2):
(JetStream2Results):
(detectSpeedometer2):
(Speedometer2Results):
(detectPLT5):
(PLT5Results):
(detectBenchmark):
(biggerIsBetter):
(ttest):
(getOptions):
(main):

3:19 PM Changeset in webkit [242657] by rmorisset@apple.com

• 2 edits in trunk/Source/JavaScriptCore

PutByIdVariant can be shrunk by 8 bytes
​https://bugs.webkit.org/show_bug.cgi?id=195482

Reviewed by Mark Lam.

• bytecode/PutByIdVariant.h:

(JSC::PutByIdVariant::PutByIdVariant):

2:12 PM Changeset in webkit [242656] by Alan Bujtas

• 3 edits in trunk/Source/WebCore

[ContentChangeObserver] Cleanup adjustObservedState
​https://bugs.webkit.org/show_bug.cgi?id=195470
<rdar://problem/48717823>

Reviewed by Simon Fraser.

This is in preparation for introducing an observation window from touchStart -> mouseMoved.

1. Cancel pending activities (future timers, pending stylesheet recalcs) when visible content change is detected.
2. The fixed time window takes care of notifying the client -timers, style recalcs during the window should not signal themselves.
3. Reset m_isObservingPendingStyleRecalc at StartedStyleRecalc instead of EndedStyleRecalc.

• page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::domTimerExecuteDidFinish):
(WebCore::ContentChangeObserver::styleRecalcDidStart):
(WebCore::ContentChangeObserver::styleRecalcDidFinish):
(WebCore::ContentChangeObserver::adjustObservedState):

• page/ios/ContentChangeObserver.h:

(WebCore::ContentChangeObserver::hasPendingActivity const):
(WebCore::ContentChangeObserver::isObservationTimeWindowActive const):

1:59 PM Changeset in webkit [242655] by ysuzuki@apple.com

• 2 edits in trunk/Source/JavaScriptCore

Unreviewed, follow-up after r242568

Robin pointed that calculation of numberOfChildren and nonEmptyIndex is unnecessary.

• dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

1:11 PM Changeset in webkit [242654] by Alan Bujtas

• 3 edits in trunk/Source/WebCore

[ContentChangeObserver] Add StartedDOMTimerExecution and StartedStyleRecalc
​https://bugs.webkit.org/show_bug.cgi?id=195463
<rdar://problem/48714762>

Reviewed by Simon Fraser.

This is in preparation for introducing m_isObservingContentChanges flag to track observing state across events (touchStart -> mouseMoved).

• page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::domTimerExecuteDidStart):
(WebCore::ContentChangeObserver::styleRecalcDidStart):
(WebCore::ContentChangeObserver::styleRecalcDidFinish):
(WebCore::ContentChangeObserver::setShouldObserveNextStyleRecalc):
(WebCore::ContentChangeObserver::adjustObservedState):

• page/ios/ContentChangeObserver.h:

(WebCore::ContentChangeObserver::isObservingPendingStyleRecalc const):
(WebCore::ContentChangeObserver::isObservingStyleRecalc const): Deleted.

12:52 PM Changeset in webkit [242653] by Stephanie Lewis

• 5 edits in trunk/Tools

Ensure old tab state is cleared between iterations of run-benchmark
​https://bugs.webkit.org/show_bug.cgi?id=195393
<rdar://problem/46885583>

Reviewed by Dewei Zhu.

a) ensure the default to restore state is not set
b) terminate Safari correctly
c) Set the system default to ignore Persistent State in Safari

• Scripts/webkitpy/benchmark_runner/browser_driver/osx_browser_driver.py:

(OSXBrowserDriver): fix terminate processes to call terminate before killing.
(OSXBrowserDriver.prepare_env):
(OSXBrowserDriver.restore_env):
(OSXBrowserDriver.close_browsers):
(OSXBrowserDriver._terminate_processes):

• Scripts/webkitpy/benchmark_runner/browser_driver/osx_chrome_driver.py: add bundle id

(OSXChromeDriver):
(OSXChromeCanaryDriver):

• Scripts/webkitpy/benchmark_runner/browser_driver/osx_firefox_driver.py: ditto

(OSXFirefoxDriver):
(OSXFirefoxNightlyDriver):

• Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py: add preferences to not restore state, bundle id

(OSXSafariDriver):
(OSXSafariDriver.prepare_env):

11:54 AM Changeset in webkit [242652] by Chris Dumez

• 3 edits in trunk/Source/WebKit

Add assertions to help debug a WebProcessCache crash
​https://bugs.webkit.org/show_bug.cgi?id=195469

Reviewed by Brady Eidson.

I suspect the process's registrableDomain in null when evictProcess() gets
called, thus crashing when lookup it up in the HashMap. Confirm this and
how this could happen via assertions.

• UIProcess/WebProcessCache.cpp:

(WebKit::WebProcessCache::evictProcess):

• UIProcess/WebProcessProxy.cpp:

(WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame):

11:51 AM Changeset in webkit [242651] by Chris Fleizach

• 2 edits in trunk/Source/WebCore

AX: AOM accessibleclick does not work on iOS
​https://bugs.webkit.org/show_bug.cgi?id=195423
<rdar://problem/48682110>

Reviewed by Joanmarie Diggs.

Return this value of this method so it can be surfaced to a higher level.

• accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:

(-[WebAccessibilityObjectWrapper _accessibilityActivate]):

11:33 AM Changeset in webkit [242650] by ysuzuki@apple.com

• 52 edits in trunk/Source/JavaScriptCore

[JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
​https://bugs.webkit.org/show_bug.cgi?id=195447

Reviewed by Filip Pizlo.

This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
to use putDirectWithoutTransition instead of putDirect.

• inspector/JSInjectedScriptHostPrototype.cpp:

(Inspector::JSInjectedScriptHostPrototype::finishCreation):

• inspector/JSJavaScriptCallFramePrototype.cpp:

(Inspector::JSJavaScriptCallFramePrototype::finishCreation):

• runtime/ArrayConstructor.cpp:

(JSC::ArrayConstructor::finishCreation):

• runtime/AsyncFunctionConstructor.cpp:

(JSC::AsyncFunctionConstructor::finishCreation):

• runtime/AsyncGeneratorFunctionConstructor.cpp:

(JSC::AsyncGeneratorFunctionConstructor::finishCreation):

• runtime/BigIntConstructor.cpp:

(JSC::BigIntConstructor::finishCreation):

• runtime/BooleanConstructor.cpp:

(JSC::BooleanConstructor::finishCreation):

• runtime/DateConstructor.cpp:

(JSC::DateConstructor::finishCreation):

• runtime/ErrorConstructor.cpp:

(JSC::ErrorConstructor::finishCreation):

• runtime/FunctionConstructor.cpp:

(JSC::FunctionConstructor::finishCreation):

• runtime/FunctionPrototype.cpp:

(JSC::FunctionPrototype::finishCreation):
(JSC::FunctionPrototype::addFunctionProperties):
(JSC::FunctionPrototype::initRestrictedProperties):

• runtime/FunctionPrototype.h:
• runtime/GeneratorFunctionConstructor.cpp:

(JSC::GeneratorFunctionConstructor::finishCreation):

• runtime/InternalFunction.cpp:

(JSC::InternalFunction::finishCreation):

• runtime/InternalFunction.h:
• runtime/IntlCollatorConstructor.cpp:

(JSC::IntlCollatorConstructor::finishCreation):

• runtime/IntlDateTimeFormatConstructor.cpp:

(JSC::IntlDateTimeFormatConstructor::finishCreation):

• runtime/IntlNumberFormatConstructor.cpp:

(JSC::IntlNumberFormatConstructor::finishCreation):

• runtime/IntlPluralRulesConstructor.cpp:

(JSC::IntlPluralRulesConstructor::finishCreation):

• runtime/JSArrayBufferConstructor.cpp:

(JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):

• runtime/JSArrayBufferPrototype.cpp:

(JSC::JSArrayBufferPrototype::finishCreation):

• runtime/JSGenericTypedArrayViewConstructorInlines.h:

(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):

• runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::init):

• runtime/JSObject.cpp:

(JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
(JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):

• runtime/JSObject.h:
• runtime/JSPromiseConstructor.cpp:

(JSC::JSPromiseConstructor::finishCreation):

• runtime/JSTypedArrayViewConstructor.cpp:

(JSC::JSTypedArrayViewConstructor::finishCreation):

• runtime/JSTypedArrayViewPrototype.cpp:

(JSC::JSTypedArrayViewPrototype::finishCreation):

• runtime/MapConstructor.cpp:

(JSC::MapConstructor::finishCreation):

• runtime/MapPrototype.cpp:

(JSC::MapPrototype::finishCreation):

• runtime/NativeErrorConstructor.cpp:

(JSC::NativeErrorConstructorBase::finishCreation):

• runtime/NullGetterFunction.h:
• runtime/NullSetterFunction.h:
• runtime/NumberConstructor.cpp:

(JSC::NumberConstructor::finishCreation):

• runtime/ObjectConstructor.cpp:

(JSC::ObjectConstructor::finishCreation):

• runtime/ProxyConstructor.cpp:

(JSC::ProxyConstructor::finishCreation):

• runtime/RegExpConstructor.cpp:

(JSC::RegExpConstructor::finishCreation):

• runtime/RegExpPrototype.cpp:

(JSC::RegExpPrototype::finishCreation):

• runtime/SetConstructor.cpp:

(JSC::SetConstructor::finishCreation):

• runtime/SetPrototype.cpp:

(JSC::SetPrototype::finishCreation):

• runtime/StringConstructor.cpp:

(JSC::StringConstructor::finishCreation):

• runtime/SymbolConstructor.cpp:

(JSC::SymbolConstructor::finishCreation):

• runtime/WeakMapConstructor.cpp:

(JSC::WeakMapConstructor::finishCreation):

• runtime/WeakSetConstructor.cpp:

(JSC::WeakSetConstructor::finishCreation):

• wasm/js/WebAssemblyCompileErrorConstructor.cpp:

(JSC::WebAssemblyCompileErrorConstructor::finishCreation):

• wasm/js/WebAssemblyInstanceConstructor.cpp:

(JSC::WebAssemblyInstanceConstructor::finishCreation):

• wasm/js/WebAssemblyLinkErrorConstructor.cpp:

(JSC::WebAssemblyLinkErrorConstructor::finishCreation):

• wasm/js/WebAssemblyMemoryConstructor.cpp:

(JSC::WebAssemblyMemoryConstructor::finishCreation):

• wasm/js/WebAssemblyModuleConstructor.cpp:

(JSC::WebAssemblyModuleConstructor::finishCreation):

• wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:

(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):

• wasm/js/WebAssemblyTableConstructor.cpp:

(JSC::WebAssemblyTableConstructor::finishCreation):

11:18 AM Changeset in webkit [242649] by Tadeu Zagallo

• 3 edits
  1 add in trunk

op_check_tdz does not def its argument
​https://bugs.webkit.org/show_bug.cgi?id=192880
<rdar://problem/46221598>

Reviewed by Saam Barati.

JSTests:

• microbenchmarks/let-for-in.js: Added.

(foo):

Source/JavaScriptCore:

This prevented the for-in loop optimization in the bytecode generator, since
the analysis sees a redefinition of the loop variable.

• bytecode/BytecodeUseDef.h:

(JSC::computeDefsForBytecodeOffset):

11:15 AM Changeset in webkit [242648] by Kocsen Chung

• 2 edits in branches/safari-607.1.40.0-branch/Source/WebKit

Cherry-pick r242629. rdar://problem/48716549

Crash under RemoteLayerTreePropertyApplier::applyProperties
​https://bugs.webkit.org/show_bug.cgi?id=195448
<rdar://problem/48588226>

Reviewed by Simon Fraser.

• UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm: (WebKit::RemoteLayerTreeHost::updateLayerTree): Under some currently-unknown circumstances, the UI process is receiving commits referring to layers that it does not know about. One understood case of this was fixed in r241899, but there seem to be cases remaining that are not understood. Also, add a release log so that we can identify any downstream effects.

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@242629 268f45cc-cd09-0410-ab3c-d52691b4dbfc

11:12 AM Changeset in webkit [242647] by Kocsen Chung

• 7 edits in branches/safari-607.1.40.0-branch/Source

Versioning.

11:01 AM Changeset in webkit [242646] by beidson@apple.com

• 5 edits in trunk/Source/WebKit

Rename AssertionState::Download.
​https://bugs.webkit.org/show_bug.cgi?id=195465

Reviewed by Andy Estes.

It's (currently) about uploads and downloads.
Let's call it "UnboundedNetworking"

• NetworkProcess/Downloads/DownloadMap.cpp:

(WebKit::DownloadMap::add):

• UIProcess/ProcessAssertion.h:

• UIProcess/WebProcessProxy.cpp:

(WebKit::WebProcessProxy::didSetAssertionState):

• UIProcess/ios/ProcessAssertionIOS.mm:

(WebKit::flagsForState):
(WebKit::reasonForState):

10:34 AM Changeset in webkit [242645] by Simon Fraser

• 2 edits in trunk/Source/WebKit

[macOS UI-side compositing] Mouse handling can trigger a crash before we have a scrolling tree root
​https://bugs.webkit.org/show_bug.cgi?id=195467

Reviewed by Antti Koivisto.

When launching MiniBrowser with UI-side compositing enabled in a state where the window
appears under the mouse, we can hit RemoteScrollingTree::handleMouseEvent() for a mouseEnter
event before we have a scrolling tree root node, so add a null check.

• UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp:

(WebKit::RemoteScrollingTree::handleMouseEvent):

10:24 AM Changeset in webkit [242644] by Truitt Savell

• 2 edits in trunk/LayoutTests

(r242595) Layout Tests in imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/* are failing
​https://bugs.webkit.org/show_bug.cgi?id=195466

Unreviewed test gardening.

• platform/mac/TestExpectations:

10:13 AM Changeset in webkit [242643] by commit-queue@webkit.org

• 2 edits in trunk/Source/WebKit

REGRESSION(r242624): [GTK] New rAF code path assumes AC mode
​https://bugs.webkit.org/show_bug.cgi?id=195459

Patch by Carlos Garcia Campos <​cgarcia@igalia.com> on 2019-03-08
Reviewed by Žan Doberšek.

• WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:

(WebKit::DrawingAreaCoordinatedGraphics::scheduleCompositingLayerFlush):
The refresh monitor now calls scheduleLayerFlush() but when AC
mode is disabled this method does nothing, so setNeedsDisplay()
needs to be called instead.

9:32 AM Changeset in webkit [242642] by pvollan@apple.com

• 2 edits in trunk/LayoutTests

Layout Test http/tests/referrer-policy-iframe/no-referrer/cross-origin-http-http.html is failing
​https://bugs.webkit.org/show_bug.cgi?id=195461

Unreviewed test gardening.

• platform/win/TestExpectations:

9:02 AM Changeset in webkit [242641] by Chris Dumez

• 3 edits in trunk/Source/WebCore

imported/w3c/web-platform-tests/FileAPI/reading-data-section/filereader_error.html is a flaky crash
​https://bugs.webkit.org/show_bug.cgi?id=195441
<rdar://problem/43437394>

Reviewed by Alexey Proskuryakov.

FileReader is an ActiveDOMObject, which means that FileReader::stop() gets called when
its script execution context is about to get destroyed. FileReader::stop() sets m_state
to DONE. FileReader::abort() would schedule an asynchronous task and then ASSERT that
m_state is not DONE, which would hit if FileReader::stop() had been called in between
the task being scheduled and its execution. To address the issue, have the task abort
early if isContextStopped() returns true.

Also replace calls to setPendingActivity() / unsetPendingActivity() with a
PendingActivity data member as mismatched call to those can lead to leaks.

• fileapi/FileReader.cpp:

(WebCore::FileReader::canSuspendForDocumentSuspension const):
No reason not to suspend if there is no pending read.

(WebCore::FileReader::stop):
(WebCore::FileReader::readInternal):
(WebCore::FileReader::abort):
(WebCore::FileReader::didFinishLoading):
(WebCore::FileReader::didFail):

• fileapi/FileReader.h:

3:57 AM Changeset in webkit [242640] by zandobersek@gmail.com

• 2 edits in trunk/Source/WebCore

GLContextEGL: desired EGL config should search for 8-bit components by default
​https://bugs.webkit.org/show_bug.cgi?id=195413

Reviewed by Carlos Garcia Campos.

The EGL config search in GLContextEGL should by default look for
RGBA8888 configurations while allowing RGB565 as an alternative.
This prevents from accidentally landing on an RGBA1010102
configuration that is available with some graphics stacks, and which is
not expected in e.g. window snapshotting that's done for layout test
output comparison.

• platform/graphics/egl/GLContextEGL.cpp:

(WebCore::GLContextEGL::getEGLConfig): EGL config search should by
default request 8-bit color channels.

3:26 AM Changeset in webkit [242639] by magomez@igalia.com

• 2 edits in trunk/Source/WebCore

Use a thread safe refcounter for FilterOperation.
​https://bugs.webkit.org/show_bug.cgi?id=194149

Reviewed by Carlos Garcia Campos.

Use a thread safe refcounter for FilterOperation.

• platform/graphics/filters/FilterOperation.h:

2:18 AM Changeset in webkit [242638] by Diego Pino Garcia

• 2 edits in trunk/Tools

[GTK] Several InputMethodFilter tests are failing
​https://bugs.webkit.org/show_bug.cgi?id=195408

Reviewed by Carlos Garcia Campos.

• TestWebKitAPI/Tests/WebKit/gtk/InputMethodFilter.cpp:

Regressed in r241751.
Hexadecimal values of keycodes are expressed now in upper letters.
Composited characters should be cast to UTF8 strings.

(TestWebKitAPI::TEST):