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