Fix miscellaneous build warnings
[WebKit-https.git] / Source / WebCore / ChangeLog
index 6d41d46..d6f7a00 100644 (file)
@@ -1,3 +1,915 @@
+2019-06-04  Michael Catanzaro  <mcatanzaro@igalia.com>
+
+        Fix miscellaneous build warnings
+        https://bugs.webkit.org/show_bug.cgi?id=198544
+
+        Reviewed by Don Olmstead.
+
+        Carefully silence -Wsign-compare warnings.
+
+        * contentextensions/DFABytecodeCompiler.cpp:
+        (WebCore::ContentExtensions::DFABytecodeCompiler::compile):
+        * inspector/InspectorCanvas.cpp:
+        (WebCore::InspectorCanvas::indexForData):
+        * xml/XSLStyleSheetLibxslt.cpp:
+        (WebCore::XSLStyleSheet::parseString):
+
+2019-06-04  Keith Rollin  <krollin@apple.com>
+
+        Fix 64-bit vs 32-bit mismatch in ISOFairPlayStreamingPsshBox.cpp
+        https://bugs.webkit.org/show_bug.cgi?id=198539
+        <rdar://problem/51410358>
+
+        Reviewed by Alex Christensen.
+
+        Both ISOFairPlayStreamingKeyAssetIdBox and
+        ISOFairPlayStreamingKeyContextBox have Vector<> data members. The
+        parse() members of these classes call Vector<>::resize() on these
+        members. In both cases, the type of the parameter passed is a
+        uint64_t. However, resize() takes a size_t. On some platforms, size_t
+        is a 32-bit value, leading to a compile-time type mismatch error. Fix
+        this by changing the type of the value passed to parse() into a
+        size_t.
+
+        No new tests -- no new functionality.
+
+        * platform/graphics/avfoundation/ISOFairPlayStreamingPsshBox.cpp:
+        (WebCore::ISOFairPlayStreamingKeyAssetIdBox::parse):
+        (WebCore::ISOFairPlayStreamingKeyContextBox::parse):
+
+2019-06-04  Keith Rollin  <krollin@apple.com>
+
+        Fix 64-bit vs 32-bit mismatch in TileController.cpp
+        https://bugs.webkit.org/show_bug.cgi?id=198540
+        <rdar://problem/51410851>
+
+        Reviewed by Alex Christensen.
+
+        TileController::blankPixelCountForTiles calculates its result as a
+        uint64_t, but returns it as an unsigned. The former is a 64-bit value,
+        while the latter can be a 32-bit value on some platforms. This
+        mismatch can lead to a compile-time error. Fix this by explicitly
+        casting the 64-bit value to an "unsigned".
+
+        No new tests -- no new functionality.
+
+        * platform/graphics/ca/TileController.cpp:
+        (WebCore::TileController::blankPixelCountForTiles):
+
+2019-06-04  Chris Dumez  <cdumez@apple.com>
+
+        Crash when calling XMLHttpRequest.setRequestHeader() in a worker
+        https://bugs.webkit.org/show_bug.cgi?id=198534
+        <rdar://problem/51393912>
+
+        Reviewed by Alex Christensen.
+
+        Make sure the script execution context is a Document because calling document()
+        to get the settings.
+
+        Test: fast/workers/worker-xhr-setRequestHeader.html
+
+        * xml/XMLHttpRequest.cpp:
+        (WebCore::XMLHttpRequest::setRequestHeader):
+
+2019-06-04  Antti Koivisto  <antti@apple.com>
+
+        Sticky positioning is jumpy in many overflow cases
+        https://bugs.webkit.org/show_bug.cgi?id=198532
+        <rdar://problem/51400532>
+
+        Reviewed by Simon Fraser.
+
+        Tests: scrollingcoordinator/ios/sticky-overflow-no-stacking-context-no-stick-1.html
+               scrollingcoordinator/ios/sticky-overflow-no-stacking-context-no-stick-2.html
+               scrollingcoordinator/ios/sticky-overflow-no-stacking-context-stick-1.html
+               scrollingcoordinator/ios/sticky-overflow-no-stacking-context-stick-2.html
+               scrollingcoordinator/ios/sticky-overflow-stacking-context-no-stick.html
+               scrollingcoordinator/ios/sticky-overflow-stacking-context-stick.html
+
+        * page/scrolling/ScrollingTree.cpp:
+        (WebCore::ScrollingTree::notifyRelatedNodesAfterScrollPositionChange):
+        (WebCore::ScrollingTree::notifyRelatedNodesRecursive):
+
+        Simplify for relatedNodeScrollPositionDidChange removal.
+
+        * page/scrolling/ScrollingTree.h:
+        * page/scrolling/ScrollingTreeNode.cpp:
+        (WebCore::ScrollingTreeNode::relatedNodeScrollPositionDidChange): Deleted.
+        * page/scrolling/ScrollingTreeNode.h:
+        * page/scrolling/cocoa/ScrollingTreeFixedNode.mm:
+        (WebCore::ScrollingTreeFixedNode::applyLayerPositions):
+        * page/scrolling/cocoa/ScrollingTreePositionedNode.h:
+        * page/scrolling/cocoa/ScrollingTreePositionedNode.mm:
+        (WebCore::ScrollingTreePositionedNode::scrollOffsetSinceLastCommit const):
+
+        Factor into a function.
+
+        (WebCore::ScrollingTreePositionedNode::applyLayerPositions):
+        (WebCore::ScrollingTreePositionedNode::relatedNodeScrollPositionDidChange): Deleted.
+
+        We can't bail out based on changed node as that makes us compute different positions based on what the change root is.
+        Since all relatedNodeScrollPositionDidChange functions now always simply call applyLayerPositions we can remove the whole thing.
+
+        * page/scrolling/cocoa/ScrollingTreeStickyNode.mm:
+        (WebCore::ScrollingTreeStickyNode::applyLayerPositions):
+
+        Implement taking into account that the containing scroller may not be our ancestor.
+
+2019-06-04  Takashi Komori  <Takashi.Komori@sony.com>
+
+        [WinCairo] Implement cpu and memory measuring functions.
+        https://bugs.webkit.org/show_bug.cgi?id=198466
+
+        Reviewed by Don Olmstead.
+
+        Tests: inspector/memory/tracking.html
+               inspector/cpu-profiler/tracking.html
+
+        * PlatformWinCairo.cmake:
+        * page/ResourceUsageThread.h:
+        * page/win/ResourceUsageOverlayWin.cpp: Copied from Tools/WebKitTestRunner/InjectedBundle/win/TestRunnerWin.cpp.
+        (WebCore::ResourceUsageOverlay::platformInitialize):
+        (WebCore::ResourceUsageOverlay::platformDestroy):
+        * page/win/ResourceUsageThreadWin.cpp: Added.
+        (WebCore::ResourceUsageThread::platformSaveStateBeforeStarting):
+        (WebCore::fileTimeToUint64):
+        (WebCore::getCurrentCpuTime):
+        (WebCore::cpuUsage):
+        (WebCore::memoryUsage):
+        (WebCore::ResourceUsageThread::platformCollectCPUData):
+        (WebCore::ResourceUsageThread::platformCollectMemoryData):
+
+2019-06-04  Antoine Quint  <graouts@apple.com>
+
+        [Pointer Events] Only allow pointer capture if the pointer is in the active buttons state
+        https://bugs.webkit.org/show_bug.cgi?id=198479
+
+        Reviewed by Dean Jackson.
+
+        The Pointer Events specification says that pointer capture can only be engaged provided the pointer is
+        in the active buttons state, which means that it has dispatched a "pointerdown" event more recently than
+        it has a "pointerup" event.
+
+        This is tested by web-platform-tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html.
+
+        That test showed a few issues that this patch addresses. First, we would update the pointerIsPressed state to
+        "true" only after a "pointerdown" event had been dispatched. This is incorrect since setPointerCapture() can,
+        and is likely to, be called during handling of a "pointerdown" event. So we now call pointerEventWillBeDispatched()
+        prior to dispatching a PointerEvent with a mouse type, which we only did previously for a PointerEvent with a
+        touch or pen type. If the event is "pointerdown", we set "pointerIsPressed" to true on the CapturingData object
+        matching the given pointer, and to false if the event is "pointerup".
+
+        Finally, we must also ensure that "pointerIsPressed" is set to true when creating CapturingData for a PointerEvent
+        with a touch or pen type since these types of pointer events implictly set capture.
+
+        * page/PointerCaptureController.cpp:
+        (WebCore::PointerCaptureController::setPointerCapture):
+        (WebCore::PointerCaptureController::dispatchEvent):
+        (WebCore::PointerCaptureController::pointerEventWillBeDispatched):
+        (WebCore::PointerCaptureController::pointerEventWasDispatched):
+
+2019-06-04  Keith Rollin  <krollin@apple.com>
+
+        Fix 32-bit/64-bit mismatch in PointerCaptureController::elementWasRemoved
+        https://bugs.webkit.org/show_bug.cgi?id=198501
+        <rdar://problem/51370464>
+
+        Reviewed by Chris Dumez.
+
+        keyAndValue.key is assigned to pointerId. KeyAndValue.key is a
+        int64_t, whereas pointerId is a PointerID, aka int32_t. This mismatch
+        is normally just a warning, but breaks builds where warnings are
+        treated as errors.
+
+        This issue is not encountered in most builds because the warning is
+        disabled in the majority of build configurations. But there are some
+        where the warning is not disabled, and so those builds break.
+
+        Address this conversion error/warning by explicitly casting
+        keyAndValue.key to a PointerID (and adding a debug check to make sure
+        the cast is OK).
+
+        No new tests -- no new functionality.
+
+        * page/PointerCaptureController.cpp:
+        (WebCore::PointerCaptureController::elementWasRemoved):
+
+2019-06-02  Antoine Quint  <graouts@apple.com>
+
+        [Pointer Events] Expose navigator.maxTouchPoints
+        https://bugs.webkit.org/show_bug.cgi?id=198468
+        <rdar://problem/51273029>
+
+        Reviewed by Chris Dumez.
+
+        Expose the navigator.maxTouchPoints property when Pointer Events are enabled both at compile-time and run-time.
+        We return a canned value for this on iOS touch-enabled devices that matches the number of simultaneous touches
+        supported by the system, which is 5. In fact, iPad support more simultaneous touches, but it doesn't seem worthy
+        to expose this level of granularity due to fingerprinting practices. In practice, what really matters is returning
+        0, 1 or more than 1 for this value to identify multi-touch support.
+
+        Test: js/dom/navigator-maxtouchpoints.html
+
+        * CMakeLists.txt:
+        * DerivedSources-input.xcfilelist:
+        * DerivedSources-output.xcfilelist:
+        * DerivedSources.make:
+        * Sources.txt:
+        * WebCore.xcodeproj/project.pbxproj:
+        * dom/NavigatorMaxTouchPoints.idl: Added.
+        * page/Navigator.idl:
+        * page/Navigator.h:
+        (WebCore::Navigator::maxTouchPoints const):
+
+2019-06-04  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][IFC] Decouple float placement and line shrinking
+        https://bugs.webkit.org/show_bug.cgi?id=198528
+        <rdar://problem/51397638>
+
+        Reviewed by Antti Koivisto.
+
+        In LineLayout::placeInlineItems() float handling should be only about shrinking the current line, the actual
+        float placement should happen later when we construct the the display boxes/runs. It enables the preferred width
+        computation to call placeInlineItems() to gather line widths without accidentally mutating the layout context. 
+
+        * layout/inlineformatting/InlineFormattingContext.h:
+        * layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
+        (WebCore::Layout::InlineFormattingContext::LineLayout::placeInlineItems const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::layout const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::createDisplayRuns const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::handleFloat const): Deleted.
+        * layout/inlineformatting/InlineItem.h:
+
+2019-06-04  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][IFC] Add hard line break handling to LineBreaker
+        https://bugs.webkit.org/show_bug.cgi?id=198503
+        <rdar://problem/51373482>
+
+        Reviewed by Antti Koivisto.
+
+        LineBreaker should simply return BreakingContext::Keep with the breaking opportunity of yes.
+
+        * layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
+        (WebCore::Layout::InlineFormattingContext::LineLayout::placeInlineItems const):
+        * layout/inlineformatting/InlineLineBreaker.cpp:
+        (WebCore::Layout::LineBreaker::breakingContext):
+        (WebCore::Layout::LineBreaker::wordBreakingBehavior const):
+        (WebCore::Layout::LineBreaker::isAtBreakingOpportunity):
+        * layout/inlineformatting/InlineLineBreaker.h:
+
+2019-06-04  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][IFC] Remove InlineItem::width
+        https://bugs.webkit.org/show_bug.cgi?id=198502
+        <rdar://problem/51371744>
+
+        Reviewed by Antti Koivisto.
+
+        InlineItems are supposd to work across subsequent layouts (and in preferred width computation as well) so they should
+        not hold on to layout information (run width). This would not work with split runs either.
+
+        * layout/inlineformatting/InlineFormattingContext.h:
+        * layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
+        (WebCore::Layout::UncommittedContent::runs):
+        (WebCore::Layout::UncommittedContent::isEmpty const):
+        (WebCore::Layout::UncommittedContent::size const):
+        (WebCore::Layout::UncommittedContent::add):
+        (WebCore::Layout::UncommittedContent::reset):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::placeInlineItems const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::computedIntrinsicWidth const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::createDisplayRuns const):
+        (): Deleted.
+        (WebCore::Layout::InlineFormattingContext::LineLayout::commitInlineItemToLine const): Deleted.
+        * layout/inlineformatting/InlineItem.h:
+        (WebCore::Layout::InlineItem::style const):
+        (): Deleted.
+        (WebCore::Layout::InlineItem::setWidth): Deleted.
+        (WebCore::Layout::InlineItem::width const): Deleted.
+
+2019-06-04  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][IFC] Move run width measuring out of LineBreaker
+        https://bugs.webkit.org/show_bug.cgi?id=198491
+        <rdar://problem/51363554>
+
+        Reviewed by Antti Koivisto.
+
+        LineBreaker should not need to deal with measuring runs.
+        This is also in preparation for removing InlineItem::width().
+
+        * layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
+        (WebCore::Layout::inlineItemWidth):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::placeInlineItems const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::computedIntrinsicWidth const):
+        * layout/inlineformatting/InlineLineBreaker.cpp:
+        (WebCore::Layout::LineBreaker::breakingContext):
+        (WebCore::Layout::LineBreaker::LineBreaker): Deleted.
+        (WebCore::Layout::LineBreaker::runWidth const): Deleted.
+        (WebCore::Layout::LineBreaker::textWidth const): Deleted.
+        * layout/inlineformatting/InlineLineBreaker.h:
+
+2019-06-04  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][IFC] Remove redundant InlineItem::width() calls.
+        https://bugs.webkit.org/show_bug.cgi?id=198489
+        <rdar://problem/51360390>
+
+        Reviewed by Antti Koivisto.
+
+        This is in preparation for removing InlineItem::width().
+
+        * layout/inlineformatting/InlineFormattingContextLineLayout.cpp:
+        (WebCore::Layout::InlineFormattingContext::LineLayout::handleFloat const):
+        (WebCore::Layout::InlineFormattingContext::LineLayout::commitInlineItemToLine const):
+        * layout/inlineformatting/InlineLine.cpp:
+        (WebCore::Layout::Line::appendNonBreakableSpace):
+        (WebCore::Layout::Line::appendInlineContainerStart):
+        (WebCore::Layout::Line::appendInlineContainerEnd):
+        * layout/inlineformatting/InlineLine.h:
+
+2019-06-04  Antoine Quint  <graouts@apple.com>
+
+        The "mouseenter" and "pointerenter" events are fired from the bottom up
+        https://bugs.webkit.org/show_bug.cgi?id=198036
+        <rdar://problem/50940350>
+
+        Reviewed by Darin Adler.
+
+        Ensure "mouseenter" and "pointerenter" events are dispatched from the bottom up to match the UI Events spec
+        at https://w3c.github.io/uievents/#events-mouseevent-event-order. We also fix the issue where "pointerevent"
+        and "pointerleave" events were dispatched as bubbling events on iOS which is not correct and was caught by the
+        new iOS test.
+        Tests: pointerevents/ios/enter-leave-order.html
+               pointerevents/mouse/enter-leave-order.html
+
+        * dom/ios/PointerEventIOS.cpp:
+        (WebCore::typeCanBubble):
+        (WebCore::PointerEvent::PointerEvent):
+        * page/EventHandler.cpp:
+        (WebCore::EventHandler::updateMouseEventTargetNode):
+        * page/PointerCaptureController.cpp:
+        (WebCore::PointerCaptureController::dispatchEventForTouchAtIndex):
+
+2019-06-04  Cathie Chen  <cathiechen@igalia.com>
+
+        JS wrapper of target in ResizeObserverEntry/ResizeObserver shouldn't get collected ahead
+        https://bugs.webkit.org/show_bug.cgi?id=197457
+
+        Reviewed by Ryosuke Niwa.
+
+        Add JSCustomMarkFunction to make sure JS wrappers wouldn't be collected when JSResizeObserverEntry live.
+
+        For ResizeObserver, if targets are removed, it will get fired for the last time. We also need to keep these JS
+        wrappers live. So add these targets to a GCReachableRef list once they're observed.
+
+        Add element-leak.html to test the targets with `entry.target.myEntry = entry` could be released properly.
+
+        Tests: resize-observer/element-leak.html
+               resize-observer/resize-observer-entry-keeps-js-wrapper-of-target-alive.html
+               resize-observer/resize-observer-keeps-js-wrapper-of-target-alive.html
+
+        * Sources.txt:
+        * WebCore.xcodeproj/project.pbxproj:
+        * bindings/js/JSResizeObserverEntryCustom.cpp: Added.
+        (WebCore::JSResizeObserverEntry::visitAdditionalChildren):
+        * page/ResizeObserver.cpp:
+        (WebCore::ResizeObserver::observe):
+        (WebCore::ResizeObserver::removeAllTargets):
+        (WebCore::ResizeObserver::removeObservation):
+        (WebCore::ResizeObserver::stop):
+        * page/ResizeObserver.h:
+        * page/ResizeObserverEntry.idl:
+
+2019-06-03  Andy Estes  <aestes@apple.com>
+
+        [Apple Pay] Disable script injection when canMakePayment APIs are called and return true
+        https://bugs.webkit.org/show_bug.cgi?id=198448
+        <rdar://problem/51323694>
+
+        Reviewed by Alex Christensen.
+
+        Previously, only an active Apple Pay session would disable script injection in restricted
+        WKWebViews. However, this can result in websites rendering non-functional Apple Pay buttons
+        due to the race between the hosting app calling -evaluateJavaScript:completionHandler: and
+        the website calling canMakePayment APIs to determine whether to draw a button.
+
+        This patch makes it so that, if a website calls ApplePaySession's canMakePayments or
+        canMakePaymentsWithActiveCard, or PaymentRequest's canMakePayment, in a web view that has no
+        injected scripts, and those calls return true, future script injections from the hosting app
+        will be blocked.
+
+        Also, this patch removes the restrictions on the openPaymentSetup, supportsVersion, and
+        validatedPaymentNetwork APIs, since those APIs do not reveal transaction information and are
+        not used to determine whether to draw buttons.
+
+        Added new API tests.
+
+        * Modules/applepay/PaymentCoordinator.cpp:
+        (WebCore::PaymentCoordinator::supportsVersion const):
+        (WebCore::PaymentCoordinator::canMakePayments):
+        (WebCore::PaymentCoordinator::canMakePaymentsWithActiveCard):
+        (WebCore::PaymentCoordinator::openPaymentSetup):
+        (WebCore::PaymentCoordinator::beginPaymentSession):
+        (WebCore::PaymentCoordinator::validatedPaymentNetwork const):
+        (WebCore::PaymentCoordinator::setApplePayIsActiveIfAllowed const):
+        (WebCore::PaymentCoordinator::shouldAllowUserAgentScripts const):
+        (WebCore::PaymentCoordinator::shouldAllowApplePay const): Deleted.
+        * Modules/applepay/PaymentCoordinator.h:
+        * dom/Document.cpp:
+        (WebCore::Document::isApplePayActive const):
+        (WebCore::Document::setApplePayIsActive):
+        (WebCore::Document::hasStartedApplePaySession const): Deleted.
+        (WebCore::Document::setHasStartedApplePaySession): Deleted.
+        * dom/Document.h:
+        * testing/Internals.cpp:
+        (WebCore::Internals::setApplePayIsActive):
+        (WebCore::Internals::setHasStartedApplePaySession): Deleted.
+        * testing/Internals.h:
+        * testing/Internals.idl:
+
+2019-06-03  Robin Morisset  <rmorisset@apple.com>
+
+        [WHLSL] Parsing and lexing the standard library is slow
+        https://bugs.webkit.org/show_bug.cgi?id=192890
+        <rdar://problem/50746335>
+
+        Reviewed by Myles Maxfield.
+
+        The main idea is to avoid backtracking by instead peeking at the next token (and occasionally at the one after that).
+        This implies a few things:
+        - We can replace the stack of tokens by a trivial ring buffer of size 2 (holding the next token and the one after, or WTF::nullopt if we are at the end of the file).
+        - We now have "completeFooExpression" functions, to avoid having to reparse the prefix of some expression, if we find half-way through what it is.
+
+        I also fixed the following parser bug:
+        - https://bugs.webkit.org/show_bug.cgi?id=198305 [WHLSL] Multiple variables with initializers in a declaration statement crashes the compiler
+            which was due to a mistake I made in the grammar
+
+        Finally I added two new macros: CONSUME_TYPE and PARSE to eliminate about 500 lines of error propagation boilerplate.
+
+        There are still lots of ways of improving the parser and lexer, such as:
+        - finishing the conversion of tokens in the lexer, not bothering with allocating string views
+        - make two special tokens Invalid and EOF, to remove the overhead of Optional
+        - make peekTypes and consumeTypes use templates to avoid constructing a Vector and calling find on it.
+        - Turn the entire lexer into a proper automata, not going through the same characters again and again (this is certainly the largest win by far)
+        - Remove the last few pieces of backtracking from the parser.
+
+        The current patch is already enough to make parsing the full standard library (something like 85k lines) approximately 260ms.
+        This is still longer than I would like, but nowhere near the bottleneck any longer because of some other parts of the compiler.
+
+        * Modules/webgpu/WHLSL/WHLSLLexer.h:
+        (WebCore::WHLSL::Lexer::Lexer):
+        (WebCore::WHLSL::Lexer::consumeToken):
+        (WebCore::WHLSL::Lexer::peek):
+        (WebCore::WHLSL::Lexer::peekFurther):
+        (WebCore::WHLSL::Lexer::state const):
+        (WebCore::WHLSL::Lexer::setState):
+        (WebCore::WHLSL::Lexer::unconsumeToken): Deleted.
+        * Modules/webgpu/WHLSL/WHLSLParser.cpp:
+        (WebCore::WHLSL::Parser::parse):
+        (WebCore::WHLSL::Parser::peek):
+        (WebCore::WHLSL::Parser::peekTypes):
+        (WebCore::WHLSL::Parser::tryType):
+        (WebCore::WHLSL::Parser::tryTypes):
+        (WebCore::WHLSL::Parser::consumeTypes):
+        (WebCore::WHLSL::Parser::parseConstantExpression):
+        (WebCore::WHLSL::Parser::parseTypeArgument):
+        (WebCore::WHLSL::Parser::parseTypeArguments):
+        (WebCore::WHLSL::Parser::parseTypeSuffixAbbreviated):
+        (WebCore::WHLSL::Parser::parseTypeSuffixNonAbbreviated):
+        (WebCore::WHLSL::Parser::parseType):
+        (WebCore::WHLSL::Parser::parseTypeDefinition):
+        (WebCore::WHLSL::Parser::parseResourceSemantic):
+        (WebCore::WHLSL::Parser::parseSpecializationConstantSemantic):
+        (WebCore::WHLSL::Parser::parseStageInOutSemantic):
+        (WebCore::WHLSL::Parser::parseSemantic):
+        (WebCore::WHLSL::Parser::parseQualifiers):
+        (WebCore::WHLSL::Parser::parseStructureElement):
+        (WebCore::WHLSL::Parser::parseStructureDefinition):
+        (WebCore::WHLSL::Parser::parseEnumerationDefinition):
+        (WebCore::WHLSL::Parser::parseEnumerationMember):
+        (WebCore::WHLSL::Parser::parseNativeTypeDeclaration):
+        (WebCore::WHLSL::Parser::parseNumThreadsFunctionAttribute):
+        (WebCore::WHLSL::Parser::parseAttributeBlock):
+        (WebCore::WHLSL::Parser::parseParameter):
+        (WebCore::WHLSL::Parser::parseParameters):
+        (WebCore::WHLSL::Parser::parseFunctionDefinition):
+        (WebCore::WHLSL::Parser::parseComputeFunctionDeclaration):
+        (WebCore::WHLSL::Parser::parseVertexFragmentFunctionDeclaration):
+        (WebCore::WHLSL::Parser::parseRegularFunctionDeclaration):
+        (WebCore::WHLSL::Parser::parseOperatorFunctionDeclaration):
+        (WebCore::WHLSL::Parser::parseFunctionDeclaration):
+        (WebCore::WHLSL::Parser::parseNativeFunctionDeclaration):
+        (WebCore::WHLSL::Parser::parseBlock):
+        (WebCore::WHLSL::Parser::parseBlockBody):
+        (WebCore::WHLSL::Parser::parseIfStatement):
+        (WebCore::WHLSL::Parser::parseSwitchStatement):
+        (WebCore::WHLSL::Parser::parseSwitchCase):
+        (WebCore::WHLSL::Parser::parseForLoop):
+        (WebCore::WHLSL::Parser::parseWhileLoop):
+        (WebCore::WHLSL::Parser::parseDoWhileLoop):
+        (WebCore::WHLSL::Parser::parseVariableDeclaration):
+        (WebCore::WHLSL::Parser::parseVariableDeclarations):
+        (WebCore::WHLSL::Parser::parseStatement):
+        (WebCore::WHLSL::Parser::parseEffectfulExpression):
+        (WebCore::WHLSL::Parser::parseEffectfulAssignment):
+        (WebCore::WHLSL::Parser::parseExpression):
+        (WebCore::WHLSL::Parser::parseTernaryConditional):
+        (WebCore::WHLSL::Parser::completeTernaryConditional):
+        (WebCore::WHLSL::Parser::parseAssignment):
+        (WebCore::WHLSL::Parser::completeAssignment):
+        (WebCore::WHLSL::Parser::parsePossibleTernaryConditional):
+        (WebCore::WHLSL::Parser::parsePossibleLogicalBinaryOperation):
+        (WebCore::WHLSL::Parser::completePossibleLogicalBinaryOperation):
+        (WebCore::WHLSL::Parser::parsePossibleRelationalBinaryOperation):
+        (WebCore::WHLSL::Parser::completePossibleRelationalBinaryOperation):
+        (WebCore::WHLSL::Parser::parsePossibleShift):
+        (WebCore::WHLSL::Parser::completePossibleShift):
+        (WebCore::WHLSL::Parser::parsePossibleAdd):
+        (WebCore::WHLSL::Parser::completePossibleAdd):
+        (WebCore::WHLSL::Parser::parsePossibleMultiply):
+        (WebCore::WHLSL::Parser::completePossibleMultiply):
+        (WebCore::WHLSL::Parser::parsePossiblePrefix):
+        (WebCore::WHLSL::Parser::parsePossibleSuffix):
+        (WebCore::WHLSL::Parser::parseCallExpression):
+        (WebCore::WHLSL::Parser::parseTerm):
+        (WebCore::WHLSL::Parser::parseAddressSpaceType): Deleted.
+        (WebCore::WHLSL::Parser::parseNonAddressSpaceType): Deleted.
+        (WebCore::WHLSL::Parser::parseEntryPointFunctionDeclaration): Deleted.
+        (WebCore::WHLSL::Parser::parseEffectfulPrefix): Deleted.
+        (WebCore::WHLSL::Parser::parseEffectfulSuffix): Deleted.
+        * Modules/webgpu/WHLSL/WHLSLParser.h:
+        (WebCore::WHLSL::Parser::Error::dump const):
+
+2019-06-03  Youenn Fablet  <youenn@apple.com>
+
+        Allow resizing of camera video feeds to very small resolutions
+        https://bugs.webkit.org/show_bug.cgi?id=198421
+
+        Reviewed by Alex Christensen.
+
+        Before the patch, the minimum capture resolution was set to 120.
+        Since this is a bit arbitrary and there are some use cases for lower resolution,
+        We now allow down to 1x1 resolution.
+
+        Test: fast/mediastream/getUserMedia-video-rescaling.html
+
+        * platform/mediastream/RealtimeVideoSource.cpp:
+        (WebCore::RealtimeVideoSource::updateCapabilities):
+        Allow 1x1 when computing min/max resolutions.
+        (WebCore::RealtimeVideoSource::bestSupportedSizeAndFrameRate):
+        In case width and height are provided, we pick the closest preset that matches and resize accordingly.
+        If width or height is provided, we pick the closest preset tat matches and applies its aspect ratio.
+
+2019-06-03  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        Implement an internal switch to turn idempotent text autosizing and viewport rules off
+        https://bugs.webkit.org/show_bug.cgi?id=198460
+        <rdar://problem/51324526>
+
+        Reviewed by Tim Horton.
+
+        Add a new WebCore setting for viewport shrink-to-fit-content heuristics; additionally, tweak the existing
+        idempotent text autosizing setting to default to false (this is overridden by preferences at the WebKit layer).
+
+        * page/Settings.yaml:
+
+2019-06-03  Rob Buis  <rbuis@igalia.com>
+
+        Implement imagesrcset and imagesizes attributes on link rel=preload
+        https://bugs.webkit.org/show_bug.cgi?id=192950
+
+        Reviewed by Youenn Fablet.
+
+        Implement imagesrcset and imagesizes attributes for both Link header
+        and link element.
+
+        Tests: imported/w3c/web-platform-tests/preload/dynamic-adding-preload-imagesrcset.html
+               imported/w3c/web-platform-tests/preload/link-header-preload-imagesrcset.html
+               imported/w3c/web-platform-tests/preload/link-header-preload-nonce.html
+               imported/w3c/web-platform-tests/preload/link-header-preload.html
+               imported/w3c/web-platform-tests/preload/onload-event.html
+               imported/w3c/web-platform-tests/preload/preload-with-type.html
+
+        * html/HTMLAttributeNames.in:
+        * html/HTMLLinkElement.cpp:
+        (WebCore::HTMLLinkElement::process):
+        * html/HTMLLinkElement.idl:
+        * loader/LinkHeader.cpp:
+        (WebCore::paramterNameFromString):
+        (WebCore::LinkHeader::setValue):
+        (WebCore::LinkHeader::LinkHeader):
+        * loader/LinkHeader.h:
+        (WebCore::LinkHeader::imageSrcSet const):
+        (WebCore::LinkHeader::imageSizes const):
+        (WebCore::LinkHeader::isViewportDependent const):
+        * loader/LinkLoader.cpp:
+        (WebCore::LinkLoader::loadLinksFromHeader):
+        (WebCore::LinkLoader::preloadIfNeeded):
+        (WebCore::LinkLoader::loadLink):
+        * loader/LinkLoader.h:
+        * page/RuntimeEnabledFeatures.h:
+        (WebCore::RuntimeEnabledFeatures::linkPreloadResponsiveImagesEnabled const):
+        (WebCore::RuntimeEnabledFeatures::setLinkPreloadResponsiveImagesEnabled):
+
+2019-06-02  Andy Estes  <aestes@apple.com>
+
+        Memory-cached main resources continue to load after the client decides a content policy of PolicyAction::Download
+        https://bugs.webkit.org/show_bug.cgi?id=198469
+        <rdar://problem/50512713>
+
+        Reviewed by Youenn Fablet.
+
+        When a document is loaded from the memory cache it does not have a main resource loader, but
+        DocumentLoader::continueAfterContentPolicy relies on being able to call
+        ResourceLoader::didFail on the main resource loader to cancel the provisional navigation
+        when the client decides a content policy of PolicyAction::Download.
+
+        This means that memory-cached main resources continue to load even after WebKit has started
+        to download the main resource. The expected behavior is for the provisional navigation to
+        fail once the download starts, like what happens when there is a main resource loader.
+
+        This patch teaches DocumentLoader::continueAfterContentPolicy to call
+        stopLoadingForPolicyChange() in the case of a null main resource loader. This will dispatch
+        didFailProvisionalNavigation and remove the DocumentLoader as a client of its
+        CachedRawResource to prevent it from delivering any cached data.
+
+        Added a new API test.
+
+        * loader/DocumentLoader.cpp:
+        (WebCore::DocumentLoader::continueAfterContentPolicy):
+
+2019-06-03  Timothy Hatcher  <timothy@apple.com>
+
+        Tweak the text and underline color for data detected text.
+        https://bugs.webkit.org/show_bug.cgi?id=198487
+        rdar://problem/50667125
+
+        Reviewed by Devin Rousso.
+
+        Tests: Color.RGBToHSL API tests
+
+        * editing/cocoa/DataDetection.mm:
+        (WebCore::DataDetection::detectContentInRange): Use currentcolor so semantic text colors work.
+        Force the lightness of the underline color to the middle, and multiply the alpha by 38%,
+        so the color will appear on light and dark backgrounds, since only one color can be specified.
+        * platform/graphics/Color.cpp:
+        (WebCore::Color::getHSL const): Return hue in [0...6) range to easily round-trip with makeRGBAFromHSLA().
+
+2019-06-03  Don Olmstead  <don.olmstead@sony.com>
+
+        [CMake] Add WebKit::JavaScriptCore target
+        https://bugs.webkit.org/show_bug.cgi?id=198403
+
+        Reviewed by Konstantin Tokarev.
+
+        Use the WebKit::JavaScriptCore target.
+
+        * CMakeLists.txt:
+
+2019-06-03  Zan Dobersek  <zdobersek@igalia.com>
+
+        [Nicosia] Disable async scrolling until implemented
+        https://bugs.webkit.org/show_bug.cgi?id=198476
+        <rdar://problem/51351478>
+
+        Unreviewed follow-up to r246033.
+
+        * page/scrolling/ScrollingCoordinator.cpp:
+        Expand the PLATFORM(IOS) guard to IOS_FAMILY.
+
+2019-06-03  Darin Adler  <darin@apple.com>
+
+        Finish cleanup of String::number for floating point
+        https://bugs.webkit.org/show_bug.cgi?id=198471
+
+        Reviewed by Yusuke Suzuki.
+
+        * css/CSSCursorImageValue.cpp:
+        (WebCore::CSSCursorImageValue::customCSSText const): Use makeString instead
+        of StringBuilder since it is more terse and possibly more efficient as well.
+        * css/DOMMatrixReadOnly.cpp:
+        (WebCore::DOMMatrixReadOnly::toString const): Ditto.
+        * css/WebKitCSSMatrix.cpp:
+        (WebCore::WebKitCSSMatrix::toString const): Ditto.
+
+        * html/parser/HTMLParserIdioms.cpp:
+        (WebCore::serializeForNumberType): Use String::number instead of
+        String::numberToStringECMAScript since that is now the default.
+        * html/shadow/MediaControlElementTypes.cpp:
+        (WebCore::MediaControlVolumeSliderElement::setVolume): Ditto.
+        * html/shadow/MediaControlElements.cpp:
+        (WebCore::MediaControlTimelineElement::setPosition): Ditto.
+        * platform/Decimal.cpp:
+        (WebCore::Decimal::fromDouble): Ditto.
+
+        * rendering/RenderListMarker.cpp:
+        (WebCore::toRoman): Return a String instead of taking a StringBuilder argument.
+        Use LetterCase enum instead of bool for the uppercase vs. lowercase argument, to
+        be less mysterious at call sites. Use unsigned for string lengths since that's
+        what WTF::String uses.
+        (WebCore::toAlphabeticOrNumeric): Ditto. Also updated since SequenceType is now
+        an enum class.
+        (WebCore::toSymbolic): Use String::createUninitialized instead of StringBuilder.
+        Return a String instead of taking a StringBuilder argument. Straighten out the
+        algorithm so it's easier to understand.
+        (WebCore::toAlphabetic): Updated since SequenceType is now an enum class.
+        (WebCore::toNumeric): Ditto.
+        (WebCore::toHebrew): Return a String instead of taking a StringBuilder argument.
+        Use unsigned for string lengths since that's what WTF::String uses.
+        (WebCore::toArmenianUnder10000): Use unsigned and the LetterCase enum class.
+        (WebCore::toArmenian): Return a String instead of taking a StringBuilder argument.
+        Also use unsigned for string lengths since that's what WTF::String uses.
+        (WebCore::toGeorgian): Ditto.
+        (WebCore::toCJKIdeographic): Ditto.
+        (WebCore::listMarkerSuffix): Tweaked a comment.
+        (WebCore::listMarkerText): Use String return values instead of StringBuilder.
+        (WebCore::RenderListMarker::paint): Use String::createUninitialized instead of
+        StringBuilder since it's a bit more efficient. Use makeString instead of turning
+        single characters into strings since that's more efficient.
+
+        * svg/SVGPathUtilities.cpp:
+        (WebCore::buildStringFromPath): Use appendNumber instead of appendShortestFormNumber
+        since that is now the default.
+
+2019-06-03  Zan Dobersek  <zdobersek@igalia.com>
+
+        [Nicosia] Disable async scrolling until implemented
+        https://bugs.webkit.org/show_bug.cgi?id=198476
+
+        Reviewed by Antti Koivisto.
+
+        Build ScrollingCoordinator::create() method on iOS or whenever
+        ASYNC_SCROLLING is not enabled.
+
+        Additionally, the USE(COORDINATED_GRAPHICS) build guards are removed
+        throughout the async scrolling classes as they aren't required now
+        and shouldn't be in the future.
+
+        * page/scrolling/ScrollingCoordinator.cpp:
+        * page/scrolling/ScrollingStateFixedNode.cpp:
+        * page/scrolling/ScrollingStateFixedNode.h:
+        * page/scrolling/ScrollingStateFrameHostingNode.cpp:
+        * page/scrolling/ScrollingStateFrameHostingNode.h:
+        * page/scrolling/ScrollingStateFrameScrollingNode.cpp:
+        * page/scrolling/ScrollingStateFrameScrollingNode.h:
+        * page/scrolling/ScrollingStateNode.cpp:
+        * page/scrolling/ScrollingStateNode.h:
+        * page/scrolling/ScrollingStateOverflowScrollingNode.cpp:
+        * page/scrolling/ScrollingStateOverflowScrollingNode.h:
+        * page/scrolling/ScrollingStatePositionedNode.cpp:
+        * page/scrolling/ScrollingStatePositionedNode.h:
+        * page/scrolling/ScrollingStateScrollingNode.cpp:
+        * page/scrolling/ScrollingStateScrollingNode.h:
+        * page/scrolling/ScrollingStateStickyNode.cpp:
+        * page/scrolling/ScrollingStateStickyNode.h:
+        * page/scrolling/ScrollingStateTree.cpp:
+        * page/scrolling/ScrollingStateTree.h:
+
+2019-06-03  Antoine Quint  <graouts@apple.com>
+
+        [Pointer Events] Check that capturing data managed by the PointerCaptureController gets cleared upon navigation
+        https://bugs.webkit.org/show_bug.cgi?id=198191
+
+        Unreviewed post-commit review feedback suggested by Darin Adler.
+
+        * page/PointerCaptureController.cpp:
+        (WebCore::PointerCaptureController::reset):
+
+2019-06-01  Simon Fraser  <simon.fraser@apple.com>
+
+        [Async overflow scroll] Flashing content when scrolling async overflow with a negative z-index child
+        https://bugs.webkit.org/show_bug.cgi?id=198458
+
+        Reviewed by Dean Jackson.
+
+        Set the GraphicsLayerPaintOverflowContents phase on the foreground layer in a composited overflow scroller,
+        which prevents clipping to the visible region, fixing scrolling flashes.
+
+        Tested by compositing/overflow/stacking-context-composited-scroller-with-foreground-paint-phases.html
+
+        * rendering/RenderLayerBacking.cpp:
+        (WebCore::RenderLayerBacking::updatePaintingPhases):
+
+2019-06-01  Simon Fraser  <simon.fraser@apple.com>
+
+        Async overflow scroll on iOS paints slowly if it has a negative z-index child
+        https://bugs.webkit.org/show_bug.cgi?id=196508
+        rdar://problem/49532709
+
+        Reviewed by Dean Jackson.
+        
+        If a RenderLayerBacking had a foreground layer and a scrolled contents layer, every geometry
+        update would change the size and offsetFromRenderer of the foreground layer between two
+        states, triggering repaint.
+
+        Fix by updating the fore- and background-layers last (nothing elese has dependencies
+        on their geometry), and using GraphicsLayer::DontSetNeedsDisplay as we do for the
+        scrolled contents layer.
+        
+        The test also revealed a bug where the shapeMaskLayer would get incorrect geometry when scrollbars
+        were visible, because it would be squished by setting the wrong bounds, so fix that.
+
+        Test: compositing/repaint/scroller-with-foreground-layer-repaints.html
+
+        * platform/graphics/ca/GraphicsLayerCA.cpp:
+        (WebCore::GraphicsLayerCA::updateClippingStrategy):
+        * rendering/RenderLayerBacking.cpp:
+        (WebCore::RenderLayerBacking::updateGeometry):
+
+2019-06-01  Simon Fraser  <simon.fraser@apple.com>
+
+        Non-composited negative z-order children should not trigger creation of a foreground layer
+        https://bugs.webkit.org/show_bug.cgi?id=198455
+
+        Reviewed by Sam Weinig.
+
+        The existing code triggered creation of a foreground layer on RenderLayerBacking when
+        the negative z-order list was non-empty. This isn't necessary; we can paint the negative
+        z-order children just fine.
+
+        We only need a foreground layer when the negative z-order layers are composited or
+        have composited descendants.
+
+        This will reduce backing store memory use in some cases.
+
+        Test: compositing/layer-creation/composited-negative-z-subtree.html
+
+        * rendering/RenderLayerCompositor.cpp:
+        (WebCore::RenderLayerCompositor::computeCompositingRequirements):
+        (WebCore::RenderLayerCompositor::updateBackingAndHierarchy):
+        (WebCore::RenderLayerCompositor::needsContentsCompositingLayer const):
+
+2019-06-01  Andy Estes  <aestes@apple.com>
+
+        [Apple Pay] Every PaymentCoordinator client should explicitly decide whether they support unrestricted Apple Pay
+        https://bugs.webkit.org/show_bug.cgi?id=198449
+        <rdar://problem/51038583>
+
+        Reviewed by Wenson Hsieh.
+
+        Rather than having a default return value of true for
+        PaymentCoordinatorClient::supportsUnrestrictedApplePay, make it pure virtual to force each
+        subclass to implement an override and explicitly choose an appropriate return value.
+
+        The only two clients that did not explicitly override were the empty client and
+        WebKitLegacy's client, and Apple Pay was never enabled in those clients, so there is no
+        change in behavior.
+
+        * Modules/applepay/PaymentCoordinatorClient.h:
+        (WebCore::PaymentCoordinatorClient::isAlwaysOnLoggingAllowed const):
+        (WebCore::PaymentCoordinatorClient::supportsUnrestrictedApplePay const): Deleted.
+        * loader/EmptyClients.cpp:
+
+2019-05-31  Youenn Fablet  <youenn@apple.com>
+
+        Add an option to mute audio capture automatically when page is not visible
+        https://bugs.webkit.org/show_bug.cgi?id=198307
+
+        Reviewed by Eric Carlson.
+
+        Reuse video capture mechanism for audio capture.
+        In case document gets in the background, interrupt the audio track if the audio factory requires it.
+        CoreAudioCaptureSourceIOS requires the audio source be interrupted if the app has not the right background mode.
+        It also allows interrupting the audio capture based on a runtime flag.
+
+        Add a runtime flag to control this.
+        Internals API is used to set it for test purposes, off by default.
+        For regular cases, the runtime flag is set through web preferences.
+
+        Test: platform/ios/mediastream/audio-muted-in-background-tab.html
+
+        * dom/Document.cpp:
+        (WebCore::Document::notifyMediaCaptureOfVisibilityChanged):
+        * page/RuntimeEnabledFeatures.h:
+        (WebCore::RuntimeEnabledFeatures::interruptAudioOnPageVisibilityChangeEnabled const):
+        (WebCore::RuntimeEnabledFeatures::setInterruptAudioOnPageVisibilityChangeEnabled):
+        * platform/mediastream/RealtimeMediaSourceCenter.cpp:
+        (WebCore::RealtimeMediaSourceCenter::RealtimeMediaSourceCenter):
+        (WebCore::RealtimeMediaSourceCenter::initializeShouldInterruptAudioOnPageVisibilityChange):
+        (WebCore::RealtimeMediaSourceCenter::setCapturePageState):
+        (WebCore::RealtimeMediaSourceCenter::visibilityDidChange):
+        * platform/mediastream/RealtimeMediaSourceCenter.h:
+        (WebCore::RealtimeMediaSourceCenter::shouldInterruptAudioOnPageVisibilityChange):
+        * platform/mediastream/RealtimeMediaSourceFactory.h:
+        (WebCore::AudioCaptureFactory::setAudioCapturePageState):
+        (WebCore::VideoCaptureFactory::setVideoCapturePageState):
+        * platform/mediastream/ios/CoreAudioCaptureSourceIOS.h:
+        * platform/mediastream/ios/CoreAudioCaptureSourceIOS.mm:
+        (WebCore::CoreAudioCaptureSourceFactory::setAudioCapturePageState):
+        (WebCore::CoreAudioCaptureSourceFactoryIOS::shouldInterruptAudioOnPageVisibilityChange):
+        * platform/mediastream/mac/CoreAudioCaptureSource.h:
+        * platform/mediastream/mac/RealtimeMediaSourceCenterMac.cpp:
+        (WebCore::RealtimeMediaSourceCenter::initializeShouldInterruptAudioOnPageVisibilityChange):
+        * testing/Internals.cpp:
+        (WebCore::Internals::resetToConsistentState):
+        (WebCore::Internals::setShouldInterruptAudioOnPageVisibilityChange):
+        * testing/Internals.h:
+        * testing/Internals.idl:
+
 2019-05-31  Geoffrey Garen  <ggaren@apple.com>
 
         Some WeakPtr typedef cleanup