A track source should be unmuted whenever reenabled after setDirection changes
[WebKit-https.git] / Source / WebCore / ChangeLog
index dad2045..ae955ea 100644 (file)
@@ -1,3 +1,240 @@
+2019-01-18  Youenn Fablet  <youenn@apple.com>
+
+        A track source should be unmuted whenever reenabled after setDirection changes
+        https://bugs.webkit.org/show_bug.cgi?id=193554
+        <rdar://problem/47366196>
+
+        Reviewed by Eric Carlson.
+
+        Ensure that track gets unmuted after being fired as part of track event.
+        Test is triggering some existing issues with MediaPlayerPrivateMediaStreamAVFObjC.
+        Given the enqueuing of samples happens in a different frame than the thread used to update media stream and the active video track,
+        some enqueued samples might not be from the right active video track or there might be no active video track.
+
+        Test: webrtc/video-setDirection.html
+
+        * Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp:
+        (WebCore::LibWebRTCMediaEndpoint::fireTrackEvent):
+        * Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.h:
+        * platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
+        (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::enqueueVideoSample):
+        (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::requestNotificationWhenReadyForVideoData):
+
+2019-01-18  Charlie Turner  <cturner@igalia.com>
+
+        [GStreamer][EME][ClearKey] Request keys from CDMInstance rather than passing via bus messages
+        https://bugs.webkit.org/show_bug.cgi?id=192229
+
+        Reviewed by Xabier Rodriguez-Calvar.
+
+        Covered by existing tests.
+
+        * platform/encryptedmedia/clearkey/CDMClearKey.cpp:
+        (WebCore::parseLicenseFormat): There is a defect in some C++11
+        compiles where they will copy this return value since the type
+        doesn't exactly match. Force a move with WTFMove.
+        * platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:
+        (WebCore::MediaPlayerPrivateGStreamerBase::dispatchDecryptionKey):
+        Deleted. No longer used by anything.
+        * platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h: Ditto.
+        * platform/graphics/gstreamer/eme/WebKitClearKeyDecryptorGStreamer.cpp:
+        Rename these methods to avoid "namespacing names".
+        (webkit_media_clear_key_decrypt_class_init):
+        (finalize):
+        (handleKeyResponse): This is a temporary fix, we need some more
+        reorganisation to be full driven by CDMInstance APIs for decryption.
+        (findAndSetKey):
+        (decrypt):
+        (webKitMediaClearKeyDecryptorFinalize): Deleted.
+        (webKitMediaClearKeyDecryptorHandleKeyResponse): Deleted.
+        (webKitMediaClearKeyDecryptorFindAndSetKey): Deleted.
+        (webKitMediaClearKeyDecryptorDecrypt): Deleted.
+        * platform/graphics/gstreamer/eme/WebKitCommonEncryptionDecryptorGStreamer.cpp: Ditto.
+        (webkit_media_common_encryption_decrypt_class_init):
+        (finalize):
+        (transformCaps):
+        (transformInPlace):
+        (isCDMInstanceAvailable):
+        (sinkEventHandler):
+        (queryHandler):
+        (changeState):
+        (setContext):
+        (webKitMediaCommonEncryptionDecryptorFinalize): Deleted.
+        (webkitMediaCommonEncryptionDecryptTransformCaps): Deleted.
+        (webkitMediaCommonEncryptionDecryptTransformInPlace): Deleted.
+        (webkitMediaCommonEncryptionDecryptIsCDMInstanceAvailable): Deleted.
+        (webkitMediaCommonEncryptionDecryptSinkEventHandler): Deleted.
+        (webkitMediaCommonEncryptionDecryptorQueryHandler): Deleted.
+        (webKitMediaCommonEncryptionDecryptorChangeState): Deleted.
+        (webKitMediaCommonEncryptionDecryptorSetContext): Deleted.
+        * platform/graphics/gstreamer/eme/WebKitCommonEncryptionDecryptorGStreamer.h:
+        * platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
+        (WebCore::MediaPlayerPrivateGStreamerMSE::attemptToDecryptWithLocalInstance):
+        Deleted. No longer passing key information over bus messages.
+        * platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h:
+
+2019-01-18  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][BFC][MarginCollapsing] Collapsing through should not ignore floats.
+        https://bugs.webkit.org/show_bug.cgi?id=193564
+
+        Reviewed by Antti Koivisto.
+
+        Float boxes prevent collapsing through.
+
+        Test: fast/block/float/float-in-descendant-formatting-context.html
+
+        * layout/blockformatting/BlockMarginCollapse.cpp:
+        (WebCore::Layout::BlockFormattingContext::MarginCollapse::marginsCollapseThrough):
+
+2019-01-18  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC] Do not skip float boxes that are not part of the current formatting context when computing bottom.
+        https://bugs.webkit.org/show_bug.cgi?id=193562
+
+        Reviewed by Antti Koivisto.
+
+        The current floating context's (float) boxes could belong to descendant formatting contexts.
+        We need to include them as well when computing height (bottom) (we essentially need to skip ancestor floats only).
+
+        <div id=container style="overflow: hidden"><div>foo<div style="float: left">bar</div></div></div>
+        While computing the height for "container", the float box needs to be taken into account even though
+        it is part of another (descendant) formatting context (the inline formatting context established by its parent div).
+
+        * layout/floats/FloatingState.cpp:
+        (WebCore::Layout::FloatingState::bottom const):
+        * layout/floats/FloatingState.h:
+        (WebCore::Layout::FloatingState::FloatItem::isDescendantOfFormattingRoot const):
+        (WebCore::Layout::FloatingState::FloatItem::inFormattingContext const): Deleted.
+
+2019-01-18  Zalan Bujtas  <zalan@apple.com>
+
+        [LFC][BFC] Check for inflow children while computing height for block formatting context roots.
+        https://bugs.webkit.org/show_bug.cgi?id=193555
+
+        Reviewed by Antti Koivisto.
+
+        This patch also extends areEssentiallyEqual to 0.125px to be able to match (essentially equal) inline runs. 
+
+        * layout/FormattingContextGeometry.cpp:
+        (WebCore::Layout::contentHeightForFormattingContextRoot):
+        * layout/Verification.cpp:
+        (WebCore::Layout::areEssentiallyEqual):
+        * page/FrameViewLayoutContext.cpp:
+        (WebCore::layoutUsingFormattingContext):
+
+2019-01-18  Yacine Bandou  <yacine.bandou@softathome.com>
+
+        [WebAudio] Release the AudioDestination when uninitializing DefaultAudioDestinationNode
+        https://bugs.webkit.org/show_bug.cgi?id=192590
+
+        Reviewed by Philippe Normand.
+
+        When we uninitialize DefaultAudioDestinationNode, the AudioDestination is stopped but not destroyed.
+
+        On some platforms the resources are allocated and released with the AudioDestination, thus when we uninitialize
+        DefaultAudioDestinationNode we don't release resources because the AudioDestination is not destroyed.
+
+        * Modules/webaudio/DefaultAudioDestinationNode.cpp:
+        (WebCore::DefaultAudioDestinationNode::uninitialize):
+
+2019-01-18  Yacine Bandou  <yacine.bandou@softathome.com>
+
+        [WebAudio] Call AudioContext::uninitialize() immediately when the AudioContext is stopped
+        https://bugs.webkit.org/show_bug.cgi?id=192586
+
+        Reviewed by Philippe Normand.
+
+        When WebProcess is killed, AudioContext::uninitialize() is not called immediately in the stop so
+        the AudioDestinationNode is not destroyed.
+
+        In my case, I have a resource device manager, the output audio device is reserved when AudioDestinationNode
+        is instantiated and it is released when AudioDestinationNode is destroyed, thus when the webprocess is killed,
+        the resources leak.
+
+        AudioContext::uninitialize() is not called immediately since r94608.
+        This modification can now be reverted without regression in WebAudio tests.
+
+        Test: webaudio/mediaelementaudiosourcenode-gc.html
+
+        * Modules/webaudio/AudioContext.cpp:
+        (WebCore::AudioContext::stop):
+
+2019-01-18  Simon Fraser  <simon.fraser@apple.com>
+
+        ScrollingCoordinator::scrollableAreaScrollLayerDidChange() can be removed
+        https://bugs.webkit.org/show_bug.cgi?id=193559
+
+        Reviewed by Antti Koivisto.
+
+        ScrollingCoordinator::scrollableAreaScrollLayerDidChange() existed for CoordinatedGraphics,
+        but the code that used it was removed in webkit.org/r229318 so we can remove it and
+        code that calls it.
+
+        * page/scrolling/ScrollingCoordinator.h:
+        (WebCore::ScrollingCoordinator::willDestroyScrollableArea):
+        (WebCore::ScrollingCoordinator::scrollableAreaScrollLayerDidChange): Deleted.
+        * rendering/RenderLayerBacking.cpp:
+        (WebCore::RenderLayerBacking::updateGeometry):
+        * rendering/RenderLayerCompositor.cpp:
+        (WebCore::RenderLayerCompositor::willRemoveScrollingLayerWithBacking):
+        (WebCore::RenderLayerCompositor::didAddScrollingLayer):
+        (WebCore::RenderLayerCompositor::scrollingLayerDidChange): Deleted.
+        * rendering/RenderLayerCompositor.h:
+
+2019-01-17  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        [iOS] Content offset jumps erratically when autoscrolling near scroll view content inset areas
+        https://bugs.webkit.org/show_bug.cgi?id=193494
+        <rdar://problem/46859627>
+
+        Reviewed by Simon Fraser and Tim Horton.
+
+        When computing the content offset to scroll to when revealing a given rect in content coordinates, we currently
+        just use the unobscured content rect. As a result, when scrolling to reveal a rect, we'll clamp the final scroll
+        position such that only content is visible. For example, when asked to reveal the rect `(0, 0, 1, 1)`, we adjust
+        the scroll position to be the origin.
+
+        However, consider the case where a client (e.g. Mail on iOS) has added a content inset to the web view's scroll
+        view. If we're asked to reveal a rect that is outside the content area but within a content inset, we will still
+        end up clamping the scroll position to the unobscured rect. This manifests in a bug where selecting text and
+        autoscrolling in iOS Mail compose while the scroll view is scrolled all the way to the top to reveal the To/Cc/
+        Subject fields causes the content offset to jump to the origin, rather than staying at (0, -topContentInset).
+
+        To fix this, we teach `RenderLayer::scrollRectToVisible` about content insets that are visible. Rather than use
+        the content rects as-is, expand to encompass visible content insets as well. This ensures that revealing a
+        position which is already visible won't cause us to scroll away the content inset area and only show the
+        unobscured rect.
+
+        Tests:  editing/selection/ios/autoscroll-with-top-content-inset.html
+                fast/scrolling/ios/scroll-into-view-with-top-content-inset.html
+
+        * page/FrameView.cpp:
+        (WebCore::FrameView::unobscuredContentRectExpandedByContentInsets const):
+
+        Introduce a helper method that expands the unobscured content rect to include surrounding content insets.
+
+        * page/FrameView.h:
+        * page/Page.h:
+        (WebCore::Page::contentInsets const):
+        (WebCore::Page::setContentInsets):
+        * rendering/RenderLayer.cpp:
+        (WebCore::RenderLayer::scrollRectToVisible):
+        (WebCore::RenderLayer::getRectToExpose const):
+
+2019-01-17  Truitt Savell  <tsavell@apple.com>
+
+        Unreviewed, rolling out r240124.
+
+        This commit broke an internal build.
+
+        Reverted changeset:
+
+        "SDK_VARIANT build destinations should be separate from non-
+        SDK_VARIANT builds"
+        https://bugs.webkit.org/show_bug.cgi?id=189553
+        https://trac.webkit.org/changeset/240124
+
 2019-01-17  Devin Rousso  <drousso@apple.com>
 
         Web Inspector: fix Xcode project file list after r239976