Context Navigation

← Previous Period
Next Period →

Timeline

Mar 9, 2019:

11:20 PM Changeset in webkit [242699] by Ross Kirsling

25 edits
2 adds
1 delete in trunk

Invalid flags in a RegExp literal should be an early SyntaxError
https://bugs.webkit.org/show_bug.cgi?id=195514

Reviewed by Darin Adler.

JSTests:

test262/expectations.yaml:

Mark 4 test cases as passing.

stress/regexp-syntax-error-invalid-flags.js:
stress/regress-161995.js: Removed.

Update existing test, merging in an older test for the same behavior.

Source/JavaScriptCore:

Currently we're throwing a *runtime* SyntaxError; this should occur at parse time.

12.2.8.1 Static Semantics: Early Errors

PrimaryExpression : RegularExpressionLiteral

It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points other than "g", "i", "m", "s", "u", or "y", or if it contains the same code point more than once.

In fixing this, let's also move flag handling from runtime/ to yarr/.

yarr/YarrSyntaxChecker.cpp:

(JSC::Yarr::checkSyntax):
Check flags before checking pattern.

CMakeLists.txt:
JavaScriptCore.xcodeproj/project.pbxproj:
Sources.txt:
bytecompiler/NodesCodegen.cpp:

(JSC::RegExpNode::emitBytecode):

inspector/ContentSearchUtilities.cpp:

(Inspector::ContentSearchUtilities::findMagicComment):

runtime/CachedTypes.cpp:
runtime/RegExp.cpp:

(JSC::RegExp::RegExp):
(JSC::RegExp::createWithoutCaching):
(JSC::RegExp::create):
(JSC::regExpFlags): Deleted.

runtime/RegExp.h:
runtime/RegExpCache.cpp:

(JSC::RegExpCache::lookupOrCreate):
(JSC::RegExpCache::ensureEmptyRegExpSlow):

runtime/RegExpCache.h:
runtime/RegExpConstructor.cpp:

(JSC::toFlags):
(JSC::regExpCreate):
(JSC::constructRegExp):

runtime/RegExpKey.h:

(JSC::RegExpKey::RegExpKey):
(WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
(WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
(): Deleted.

runtime/RegExpPrototype.cpp:

(JSC::regExpProtoFuncCompile):

testRegExp.cpp:

(parseRegExpLine):

yarr/RegularExpression.cpp:

(JSC::Yarr::RegularExpression::Private::compile):

yarr/YarrFlags.cpp: Added.

(JSC::Yarr::parseFlags):

yarr/YarrFlags.h: Added.
yarr/YarrInterpreter.h:

(JSC::Yarr::BytecodePattern::ignoreCase const):
(JSC::Yarr::BytecodePattern::multiline const):
(JSC::Yarr::BytecodePattern::sticky const):
(JSC::Yarr::BytecodePattern::unicode const):
(JSC::Yarr::BytecodePattern::dotAll const):

yarr/YarrPattern.cpp:

(JSC::Yarr::YarrPattern::compile):
(JSC::Yarr::YarrPattern::YarrPattern):
(JSC::Yarr::YarrPattern::dumpPattern):

yarr/YarrPattern.h:

(JSC::Yarr::YarrPattern::global const):
(JSC::Yarr::YarrPattern::ignoreCase const):
(JSC::Yarr::YarrPattern::multiline const):
(JSC::Yarr::YarrPattern::sticky const):
(JSC::Yarr::YarrPattern::unicode const):
(JSC::Yarr::YarrPattern::dotAll const):
Move flag handling to Yarr and modernize API.

Source/WebCore:

bindings/js/SerializedScriptValue.cpp:

(WebCore::CloneDeserializer::readTerminal):
Consume YarrFlags.

11:04 PM Changeset in webkit [242698] by commit-queue@webkit.org

23 edits in trunk

Add a WKContentRuleList variant that uses copied memory instead of mmap'd shared memory for class A containerized apps
https://bugs.webkit.org/show_bug.cgi?id=195511
<rdar://problem/44873269>

Patch by Alex Christensen <achristensen@webkit.org> on 2019-03-10
Reviewed by Darin Adler.

Source/WebKit:

NetworkProcess/NetworkContentRuleListManager.cpp:

(WebKit::NetworkContentRuleListManager::addContentRuleLists):

NetworkProcess/NetworkContentRuleListManager.h:
NetworkProcess/cache/NetworkCacheFileSystem.cpp:

(WebKit::NetworkCache::pathRegisteredAsUnsafeToMemoryMapForTesting):
(WebKit::NetworkCache::registerPathAsUnsafeToMemoryMapForTesting):
(WebKit::NetworkCache::isSafeToUseMemoryMapForPath):

NetworkProcess/cache/NetworkCacheFileSystem.h:
Shared/WebCompiledContentRuleList.cpp:

(WebKit::WebCompiledContentRuleList::usesCopiedMemory const):
(WebKit::WebCompiledContentRuleList::conditionsApplyOnlyToDomain const):
(WebKit::WebCompiledContentRuleList::filtersWithoutConditionsBytecode const):
(WebKit::WebCompiledContentRuleList::filtersWithConditionsBytecode const):
(WebKit::WebCompiledContentRuleList::topURLFiltersBytecode const):
(WebKit::WebCompiledContentRuleList::actions const):

Shared/WebCompiledContentRuleList.h:
Shared/WebCompiledContentRuleListData.cpp:

(WebKit::WebCompiledContentRuleListData::size const):
(WebKit::WebCompiledContentRuleListData::dataPointer const):
(WebKit::WebCompiledContentRuleListData::encode const):
(WebKit::WebCompiledContentRuleListData::decode):

Shared/WebCompiledContentRuleListData.h:

(WebKit::WebCompiledContentRuleListData::WebCompiledContentRuleListData):

UIProcess/API/APIContentRuleList.cpp:

(API::ContentRuleList::usesCopiedMemory const):

UIProcess/API/APIContentRuleList.h:
UIProcess/API/APIContentRuleListStore.cpp:

(API::getData):
(API::decodeContentRuleListMetaData):
(API::ContentRuleListStore::readContentsOfFile):
(API::MappedOrCopiedData::dataPointer const):
(API::openAndMapOrCopyContentRuleList):
(API::compiledToFile):
(API::createExtension):
(API::ContentRuleListStore::lookupContentRuleList):
(API::ContentRuleListStore::compileContentRuleList):
(API::ContentRuleListStore::getContentRuleListSource):
(API::openAndMapContentRuleList): Deleted.

UIProcess/API/APIContentRuleListStore.h:
UIProcess/API/Cocoa/APIContentRuleListStoreCocoa.mm:

(API::ContentRuleListStore::readContentsOfFile):

UIProcess/API/Cocoa/WKContentRuleListStore.mm:

(+[WKContentRuleListStore _registerPathAsUnsafeToMemoryMapForTesting:]):

UIProcess/API/Cocoa/WKContentRuleListStorePrivate.h:
UIProcess/API/Cocoa/_WKUserContentFilter.mm:

(-[_WKUserContentFilter usesCopiedMemory]):

UIProcess/API/Cocoa/_WKUserContentFilterPrivate.h:
WebProcess/UserContent/WebUserContentController.cpp:

(WebKit::WebUserContentController::addContentRuleLists):

WebProcess/UserContent/WebUserContentController.h:
WebProcess/WebPage/WebPage.cpp:

(WebKit::m_hostFileDescriptor):

Tools:

TestWebKitAPI/Tests/WebKitCocoa/WKContentExtensionStore.mm:

(-[TestSchemeHandlerSubresourceShouldBeBlocked webView:startURLSchemeTask:]):
(-[TestSchemeHandlerSubresourceShouldBeBlocked webView:stopURLSchemeTask:]):
(TEST_F):

8:41 PM Changeset in webkit [242697] by jiewen_tan@apple.com

10 edits in trunk/Source/WebKit

Optimizing loads when creating new pages
https://bugs.webkit.org/show_bug.cgi?id=195516
<rdar://problem/48738086>

Reviewed by Darin Adler.

This patch adds hooks in WebPageProxy::createNewPage to optimize loads, and moves the creationParameters
of API::NavigationAction from UI clients to WebPageProxy::createNewPage. Also, we now pass the whole
API::NavigationAction to the load optimizer instead of the request within.

UIProcess/API/APINavigationAction.h:
UIProcess/API/APIUIClient.h:

(API::UIClient::createNewPage):

UIProcess/API/C/WKPage.cpp:

(WKPageSetPageUIClient):

UIProcess/API/glib/WebKitUIClient.cpp:
UIProcess/Cocoa/NavigationState.mm:

(WebKit::tryOptimizingLoad):
(WebKit::tryInterceptNavigation):
(WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction):

UIProcess/Cocoa/UIDelegate.h:
UIProcess/Cocoa/UIDelegate.mm:

(WebKit::UIDelegate::UIClient::createNewPage):

UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::decidePolicyForNavigationAction):
(WebKit::tryOptimizingLoad):
(WebKit::WebPageProxy::createNewPage):

UIProcess/WebPageProxy.h:

8:32 PM Changeset in webkit [242696] by timothy_horton@apple.com

24 edits
7 adds in trunk

Add SPI to retrieve the set of text inputs in a given rect, and later focus one
https://bugs.webkit.org/show_bug.cgi?id=195499

Reviewed by Darin Adler.

Source/WebCore:

New API tests: WebKit.RequestTextInputContext and WebKit.FocusTextInputContext

WebCore.xcodeproj/project.pbxproj:
dom/Document.cpp:

(WebCore::Document::identifierForElement):
(WebCore::Document::elementWithIdentifier):
(WebCore::Document::identifiedElementWasRemovedFromDocument):

dom/Document.h:

Add a mechanism where Document will vend an ObjectIdentifier for a given
element, and can (if possible) retrieve that element later.

dom/Element.cpp:

(WebCore::Element::removedFromAncestor):
If an Element has an identifier created for it, inform Document to remove
it from the identifier map when the element is detached.

(WebCore::Element::createElementIdentifier):

dom/Element.h:
dom/ElementIdentifier.h: Added.
dom/ElementRareData.cpp:
dom/ElementRareData.h:

(WebCore::ElementRareData::hasElementIdentifier const):
(WebCore::ElementRareData::setHasElementIdentifier):
(WebCore::ElementRareData::ElementRareData):
Store a bit indicating if the Element has had a identifier created for it,
so that we can avoid a hash lookup on every Element removal.

dom/Node.h:
html/HTMLTextFormControlElement.h:

Source/WebKit:

Scripts/webkit/messages.py:
Shared/TextInputContext.cpp: Added.

(IPC::ArgumentCoder<WebKit::TextInputContext>::encode):
(IPC::ArgumentCoder<WebKit::TextInputContext>::decode):

Shared/TextInputContext.h: Added.

(WebKit::TextInputContext::operator== const):
Add TextInputContext, which represents a minimal set of information
about a text field.

Sources.txt:
SourcesCocoa.txt:
UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView _requestTextInputContextsInRect:completionHandler:]):
(-[WKWebView _focusTextInputContext:completionHandler:]):

UIProcess/API/Cocoa/WKWebViewPrivate.h:

Add SPI that allows clients to asynchronously request text input
contexts for a given rect, and later focus a given context.

UIProcess/API/Cocoa/_WKTextInputContext.h: Added.
UIProcess/API/Cocoa/_WKTextInputContext.mm: Added.

(-[_WKTextInputContext _initWithTextInputContext:]):
(-[_WKTextInputContext boundingRect]):
(-[_WKTextInputContext _textInputContext]):
(-[_WKTextInputContext isEqual:]):
(-[_WKTextInputContext hash]):
(-[_WKTextInputContext copyWithZone:]):

UIProcess/API/Cocoa/_WKTextInputContextInternal.h: Added.

Add an SPI object that exposes a read-only window on a TextInputContext to clients.

UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::textInputContextsInRect):
(WebKit::WebPageProxy::focusTextInputContext):

UIProcess/WebPageProxy.h:

Plumbing from WKWebView<->WebPage.

WebKit.xcodeproj/project.pbxproj:
WebProcess/WebPage/WebPage.cpp:

(WebKit::elementRectInWindowCoordinates):
(WebKit::isEditableTextInputElement):
(WebKit::WebPage::textInputContextsInRect):
Search the DOM for text input contexts: <input type='text'> (or other
form fields that fall back on text field behavior), <textarea>, and
contenteditable roots. Store the WebPage, Document, and Element identifiers
so that we can find the element again later.

(WebKit::WebPage::focusTextInputContext):
Find the element for a given (web page, document, element) triple and focus it,
if it's still available.

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

Tools:

TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm: Added.

(-[WKWebView synchronouslyRequestTextInputContextsInRect:]):
(-[WKWebView synchronouslyFocusTextInputContext:]):
(applyStyle):
(applyIframe):
(TEST):
Add some tests for this SPI.

7:54 PM Changeset in webkit [242695] by timothy_horton@apple.com

4 edits in trunk/Source/WebKit

iOS: Using ⌥ to scroll horizontally is no different than arrow key
https://bugs.webkit.org/show_bug.cgi?id=195268
<rdar://problem/48326682>

Reviewed by Brent Fulgham.

UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView keyboardScrollViewAnimator:distanceForIncrement:inDirection:]):
(-[WKContentView keyboardScrollViewAnimator:distanceForIncrement:]): Deleted.

UIProcess/ios/WKKeyboardScrollingAnimator.h:
UIProcess/ios/WKKeyboardScrollingAnimator.mm:

(-[WKKeyboardScrollingAnimator keyboardScrollForEvent:]):
(-[WKKeyboardScrollViewAnimator setDelegate:]):
(-[WKKeyboardScrollViewAnimator distanceForIncrement:inDirection:]):
(-[WKKeyboardScrollViewAnimator distanceForIncrement:]): Deleted.
Add a direction parameter to -distanceForIncrement:, so the client
can return a different page/document size based on the scrolling axis.
Adopt it both in the default implementation and in WKContentViewInteraction.
Make the option key scroll by page when scrolling horizontally, like it
does when scrolling vertically.

7:36 PM Changeset in webkit [242694] by Fujii Hironori

8 edits in trunk

[WTF] Align assumption in RunLoopWin to the other platform's RunLoop
https://bugs.webkit.org/show_bug.cgi?id=181151

Source/WTF:

Reviewed by Don Olmstead.

This patch fixes RunLoop in Windows to align it to the implementations in the other platforms
to use RunLoop more aggressively.

wtf/RunLoop.h:

(WTF::RunLoop::Timer::Timer):

wtf/win/MainThreadWin.cpp:

(initializeMainThreadPlatform): Call RunLoop::registerRunLoopMessageWindowClass.

wtf/win/RunLoopWin.cpp:

(WTF::RunLoop::wndProc):
(WTF::RunLoop::iterate):
(WTF::RunLoop::stop):
PostQuitMessage is only available in the RunLoop's thread. We should post a message and call
it inside this task.

(WTF::RunLoop::registerRunLoopMessageWindowClass):
Changed the return type from bool to void, and added RELEASE_ASSERT to check the return value of RegisterClass.

(WTF::RunLoop::~RunLoop):
When the RunLoop's thread is freed, its associated window is freed. We do not need to do here.

(WTF::RunLoop::TimerBase::timerFired):
(WTF::RunLoop::TimerBase::TimerBase):
(WTF::RunLoop::TimerBase::start):
(WTF::RunLoop::TimerBase::stop):
(WTF::RunLoop::TimerBase::isActive const):
(WTF::RunLoop::TimerBase::secondsUntilFire const):
(WTF::generateTimerID): Deleted.
We can use TimerBase's pointer as ID since it is uintptr_t.

Tools:

Patch by Yusuke Suzuki <Yusuke Suzuki> on 2019-03-10
Reviewed by Don Olmstead.

TestWebKitAPI/CMakeLists.txt:
TestWebKitAPI/PlatformWin.cmake:

Enable TestWTF RunLoop tests in all platforms.

TestWebKitAPI/Tests/WTF/RunLoop.cpp:

(TestWebKitAPI::DerivedOneShotTimer::DerivedOneShotTimer):
(TestWebKitAPI::DerivedOneShotTimer::fired):
(TestWebKitAPI::TEST):
Only a few platforms support nested RunLoop.

(TestWebKitAPI::DerivedRepeatingTimer::DerivedRepeatingTimer):
(TestWebKitAPI::DerivedRepeatingTimer::fired):

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

(diff)

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

(diff)

5:27 PM Changeset in webkit [242693] by david_quesada@apple.com

4 edits in trunk

ASSERT(m_downloads.isEmpty()) fails in DownloadProxyMap::~DownloadProxyMap()
https://bugs.webkit.org/show_bug.cgi?id=152480

Reviewed by Chris Dumez.

Source/WebKit:

UIProcess/Downloads/DownloadProxyMap.cpp:

(WebKit::DownloadProxyMap::downloadFinished):

If the DownloadProxy is holding the last reference to the process pool, then
invalidating the proxy will cause the process pool, the network process proxy,
and this DownloadProxyMap to deallocate. Ensure that doesn't happen until this
method has done everything it wants to do to clean up.

Tools:

Add a unit test based on Daniel Bates's test case that starts a download, ensures
there are no additional references to the process pool besides the one held by
the download, waits for the download to finish (in the sense that the
DownloadProxyMap is done tracking the DownloadProxy), and doesn't crash. For good
measure, also check that the process pool has been deallocated at the end of the
test. The test wouldn't be meaningful if the process pool were still alive.

TestWebKitAPI/Tests/WebKitCocoa/Download.mm:

(-[WaitUntilDownloadCanceledDelegate _downloadDidStart:]):
(-[WaitUntilDownloadCanceledDelegate _downloadDidCancel:]):

The download will be canceled because the delegate does not implement the
method to decide the download's destination, so this is where we know the
DownloadProxyMap is done with the DownloadProxy.

(TEST):

5:13 PM Changeset in webkit [242692] by bshafiei@apple.com

7 edits in tags/Safari-608.1.8.1/Source

Versioning.

5:11 PM Changeset in webkit [242691] by bshafiei@apple.com

1 copy in tags/Safari-608.1.8.1

New tag.

4:49 PM Changeset in webkit [242690] by Wenson Hsieh

2 edits in trunk/Source/WebKit

Fix some misleading function and variable names in WKContentViewInteraction.mm
https://bugs.webkit.org/show_bug.cgi?id=195536

Reviewed by Tim Horton.

UIProcess/ios/WKContentViewInteraction.mm:

(shouldDeferZoomingToSelectionWhenRevealingFocusedElement):

Rename shouldZoomToRevealSelectionRect to shouldDeferZoomingToSelectionWhenRevealingFocusedElement; this
function is used to determine whether we should zoom to the selection rect when revealing the focused element,
and therefore affects whether we need to defer zooming until we get selection information.

(rectToRevealWhenZoomingToFocusedElement):
(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:changingActivityState:userObject:]):

Rename shouldShowKeyboard to shouldShowInputView; this boolean indicates whether we should show not only the
keyboard, but other UI for user input such as date and select pickers.

(-[WKContentView _didReceiveEditorStateUpdateAfterFocus]):
(shouldZoomToRevealSelectionRect): Deleted.

1:08 PM Changeset in webkit [242689] by Alan Bujtas

8 edits in trunk

[ContentChangeObserver] Fix failing test cases
https://bugs.webkit.org/show_bug.cgi?id=195524
<rdar://problem/48745101>

Reviewed by Simon Fraser.

Source/WebCore:

Do not start DOM timer install observation when we already detected change at touchstart.
hasPendingActivity() should only care about ContentChangeObserver flags.
Do not try to notify the client when we are in the mouseMoved dispatch call (currently it could happen

when a timer gets intalled and removed right away).

page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::adjustObservedState):
(WebCore::ContentChangeObserver::isNotifyContentChangeAllowed const): Deleted.

page/ios/ContentChangeObserver.h:

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

LayoutTests:

They've been failing ever since the 32ms fixed time window was introduced.

fast/events/touch/ios/content-observation/click-instead-of-hover-simple.html:
fast/events/touch/ios/content-observation/stuck-with-hover-state.html:

11:10 AM Changeset in webkit [242688] by Simon Fraser

2 edits in trunk/LayoutTests

Mark two tests as failing after r242624
https://bugs.webkit.org/show_bug.cgi?id=195531

Unreviewed test gardening.

These tests are failing:
accessibility/mac/selection-notification-focus-change.html [ Failure ]
compositing/video/video-clip-change-src.html [ ImageOnlyFailure ]

platform/mac-wk2/TestExpectations:

11:03 AM Changeset in webkit [242687] by Simon Fraser

25 edits in trunk/Source

ScrollingTree should have the final say on where layers go
https://bugs.webkit.org/show_bug.cgi?id=195507

Reviewed by Antti Koivisto.

Source/WebCore:

Main thread layer flushing can race with scrolling tree layer changes on macOS, causing
flashing as layers jump around sometimes. We go to some lengths to avoid this by trying
not to touch properties on layers that are being interacted with (scrollableArea->setIsUserScroll in
updateScrollPositionAfterAsyncScroll()), but that's fragile.

This patch adds ScrollingTree::applyScrollingTreeLayerPositions(), which enters
ScrollingTree::applyLayerPositions() on the main thread/UI process. This traverses
the tree allowing each node to run their layer positioning logic.

For macOS WK2, this is called from TiledCoreAnimationDrawingArea::flushLayers() after flushCompositingStateIncludingSubframes().
For macOS WK2 with UI-side compositing, RemoteLayerTreeDrawingAreaProxy::commitLayerTree()
calls m_webPageProxy.scrollingCoordinatorProxy()->applyScrollingTreeLayerPositions().
iOS WK2 is unchanged, using viewportChangedViaDelegatedScrolling() which does the same thing, allowing
for the dynamic viewport changes that happen when zooming on iOS.

Testing this requires infrastructure that we don't have yet.

page/scrolling/AsyncScrollingCoordinator.cpp:

(WebCore::AsyncScrollingCoordinator::applyScrollingTreeLayerPositions):

page/scrolling/AsyncScrollingCoordinator.h:
page/scrolling/ScrollingCoordinator.h:

(WebCore::ScrollingCoordinator::applyScrollingTreeLayerPositions):

page/scrolling/ScrollingTree.cpp:

(WebCore::ScrollingTree::handleWheelEvent):
(WebCore::ScrollingTree::commitTreeState):
(WebCore::ScrollingTree::applyLayerPositions):
(WebCore::ScrollingTree::applyLayerPositionsRecursive):

page/scrolling/ScrollingTree.h:
page/scrolling/ScrollingTreeFrameHostingNode.cpp:

(WebCore::ScrollingTreeFrameHostingNode::applyLayerPositions):

page/scrolling/ScrollingTreeFrameHostingNode.h:
page/scrolling/ScrollingTreeNode.h:
page/scrolling/ScrollingTreeScrollingNode.cpp:

(WebCore::ScrollingTreeScrollingNode::applyLayerPositions):

page/scrolling/ScrollingTreeScrollingNode.h:
page/scrolling/cocoa/ScrollingTreeFixedNode.h:
page/scrolling/cocoa/ScrollingTreeFixedNode.mm:

(WebCore::ScrollingTreeFixedNode::relatedNodeScrollPositionDidChange):

page/scrolling/cocoa/ScrollingTreeStickyNode.h:
page/scrolling/cocoa/ScrollingTreeStickyNode.mm:

(WebCore::ScrollingTreeStickyNode::applyLayerPositions):
(WebCore::ScrollingTreeStickyNode::relatedNodeScrollPositionDidChange):

page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h:
page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:

(WebCore::ScrollingTreeFrameScrollingNodeMac::applyLayerPositions):

Source/WebKit:

UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:

(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):

UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.cpp:

(WebKit::RemoteScrollingCoordinatorProxy::applyScrollingTreeLayerPositions):

UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:

(WebKit::TiledCoreAnimationDrawingArea::flushLayers):

10:13 AM Changeset in webkit [242686] by Darin Adler

2 edits in trunk/Source/WebKit

[Cocoa] Code signing fails because services are copied into XPCServices after the framework is signed
https://bugs.webkit.org/show_bug.cgi?id=195523

Reviewed by Dan Bernstein.

WebKit.xcodeproj/project.pbxproj: Make symbolic links while building the WebKit

framework instead of copying in the services after the framework is built.

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:

(Web process) sends sync IPC message A to UI process.
(UI process) schedules some main runloop task that will block synchronously on IPC message B.
(UI process) receives sync IPC message A and schedules A on the main runloop.
(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