Fix miscellaneous build warnings
[WebKit-https.git] / Source / WebCore / ChangeLog
index 4ac2f88..d6f7a00 100644 (file)
@@ -1,3 +1,569 @@
+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