[webkit-changes] [WebKit/WebKit] cabee8: Cherry-pick 262240 at main (9f577500830e). https://bu...

[Ahmad Saleem]

  Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: cabee89eb42c69c8f3dd3909a37d901a2d7413b6
      https://github.com/WebKit/WebKit/commit/cabee89eb42c69c8f3dd3909a37d901a2d7413b6
  Author: Arunsundar Kannan <arunsundar_kannan at apple.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.cpp
    M Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.h
    M Source/WebKit/NetworkProcess/NetworkContentRuleListManager.cpp
    M Source/WebKit/NetworkProcess/NetworkContentRuleListManager.h
    M Source/WebKit/NetworkProcess/NetworkProcess.h

  Log Message:
  -----------
  Cherry-pick 262240 at main (9f577500830e). https://bugs.webkit.org/show_bug.cgi?id=254500.

    Remove smart pointer violation in NetworkContentRuleListManager, LegacyCustomProtocolManager.
    https://bugs.webkit.org/show_bug.cgi?id=254500.
    rdar://107255403.

    Reviewed by Chris Dumez.

    m_process is using raw references, this changes uses WTF:: Ref.

    * Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.cpp:
    (WebKit::LegacyCustomProtocolManager::LegacyCustomProtocolManager):
    (WebKit::LegacyCustomProtocolManager::startLoading):
    (WebKit::LegacyCustomProtocolManager::stopLoading):
    * Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.h:
    * Source/WebKit/NetworkProcess/NetworkContentRuleListManager.cpp:
    (WebKit::NetworkContentRuleListManager::contentExtensionsBackend):
    * Source/WebKit/NetworkProcess/NetworkContentRuleListManager.h:

    Canonical link: https://commits.webkit.org/262240@main


  Commit: a42f850c9f9c3c6206520fb7e0ed743656d11f55
      https://github.com/WebKit/WebKit/commit/a42f850c9f9c3c6206520fb7e0ed743656d11f55
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp

  Log Message:
  -----------
  Cherry-pick 262144 at main (9bc4d3cabf88). https://bugs.webkit.org/show_bug.cgi?id=228820

    [MSE][GStreamer] Missing support for aborts not followed by an initialization segment
    https://bugs.webkit.org/show_bug.cgi?id=228820

    This patch performs a flush on the AppendPipeline on SourceBuffer::abort().
    Such action drains the AppendPipeline but leaves the demuxer still configured with
    the context provided by the last init segment. This is in compliance with the spec,
    which mandates that there's no need to append an init segment after an abort,
    because the last one should be reused.

    For this patch to work, the following GStreamer merge requests, scheduled to be
    landed on 1.23.1, must be present:
    https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4101.
    https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4199.

    If the GStreamer version is lower than the required one, the old reset technique,
    consisting of setting the pipeline to READY and then PLAYING, is applied.

    In the current circumstances, the layout tests still don't pass, so this patch
    isn't unskipping them yet. media-mp4-h264-partial-abort.html should be unskipped
    when we start using a GStreamer version that includes the MRs.
    media-webm-opus-partial-abort.html should be unskipped when
    https://github.com/WebKit/WebKit/pull/11807 lands.

    See: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1016

    Reviewed by Alicia Boya Garcia.

    * Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
    (WebCore::AppendPipeline::resetParserState): If supported by GStreamer, perform a flush instead of setting the pipeline state to READY and then again to PLAYING.

    Canonical link: https://commits.webkit.org/262144@main


  Commit: 7f7073d7671af9cb02d1a94db2e441ce3b71b757
      https://github.com/WebKit/WebKit/commit/7f7073d7671af9cb02d1a94db2e441ce3b71b757
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M Source/JavaScriptCore/assembler/MacroAssembler.h

  Log Message:
  -----------
  Cherry-pick 262260 at main (dd5da1dca9b6). https://bugs.webkit.org/show_bug.cgi?id=254634

    Only CPU(X86_64) should do constant blinding.
    https://bugs.webkit.org/show_bug.cgi?id=254634
    <rdar://problem/107345556>

    Reviewed by Justin Michaud and Yusuke Suzuki.

    It is not relevant for CPUs with fixed alignment instruction sets.

    * Source/JavaScriptCore/assembler/MacroAssembler.h:
    (JSC::MacroAssembler::shouldBlind):

    Canonical link: https://commits.webkit.org/262260@main


  Commit: e2996b36dd38fee0c43fe8e8cb752bf31fb133f0
      https://github.com/WebKit/WebKit/commit/e2996b36dd38fee0c43fe8e8cb752bf31fb133f0
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    M Source/WebCore/rendering/RenderBox.cpp
    M Source/WebCore/rendering/RenderBox.h

  Log Message:
  -----------
  Cherry-pick 262274 at main (ea7b758f5d2e). https://bugs.webkit.org/show_bug.cgi?id=254646

    RenderBox::computeInlineDirectionMargins() is causing system malloc heap allocations
    https://bugs.webkit.org/show_bug.cgi?id=254646

    Reviewed by Darin Adler.

    RenderBox::computeInlineDirectionMargins() was causing system malloc heap
    allocations due to its use of std::function:

    Sample Count, Samples %, Normalized CPU %, Symbol
    21, 0.0%, 0.0%, tiny_malloc_should_clear (in libsystem_malloc.dylib)
    20, 0.0%, 0.0%,     szone_malloc_should_clear (in libsystem_malloc.dylib)
    8, 0.0%, 0.0%,         operator new(unsigned long) (in libc++abi.dylib)
    5, 0.0%, 0.0%,             WebCore::RenderBox::computeInlineDirectionMargins(WebCore::RenderBlock const&, WebCore::LayoutUnit, std::__1::optional<WebCore::LayoutUnit>, WebCore::LayoutUnit, WebCore::LayoutUnit&, WebCore::LayoutUnit&) const (in WebCore)
    3, 0.0%, 0.0%,             WebCore::RenderBox::fillAvailableMeasure(WebCore::LayoutUnit, WebCore::LayoutUnit&, WebCore::LayoutUnit&) const (in WebCore)

    * Source/WebCore/rendering/RenderBox.cpp:
    (WebCore::RenderBox::computeLogicalWidthInFragment const):
    (WebCore::RenderBox::fillAvailableMeasure const):
    (WebCore::RenderBox::computeOrTrimInlineMargin const):
    (WebCore::RenderBox::computeInlineDirectionMargins const):
    * Source/WebCore/rendering/RenderBox.h:

    Canonical link: https://commits.webkit.org/262274@main


  Commit: 5ab093369840e0ca98c0d803c6d12cf29dfa3ed1
      https://github.com/WebKit/WebKit/commit/5ab093369840e0ca98c0d803c6d12cf29dfa3ed1
  Author: Tim Nguyen <ntim at apple.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    A LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto-expected.txt
    A LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto.html
    M LayoutTests/platform/mac-wk1/TestExpectations
    M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h
    M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp

  Log Message:
  -----------
  Cherry-pick 262281 at main (b8bf24826066). https://bugs.webkit.org/show_bug.cgi?id=254632

    Exiting fullscreen on ign.com fails to restore scroll position
    https://bugs.webkit.org/show_bug.cgi?id=254632
    rdar://106774841

    Reviewed by Jer Noble.

    The bug is caused by a missing layout in some particular situations (overflow: auto + percentage sizes) before restoring the scroll position.
    Adding a call to forceLayout() fixes the issue.

    However, in order for the test to work in WebKit Test runner, the save/restoreScrollPosition methods also need to be called in the InjectedBundle.
    Safari & minibrowser use a different codepath (involving the UIProcess).

    * LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto-expected.txt: Added.
    * LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto.html: Added.
    * LayoutTests/platform/mac-wk1/TestExpectations:
    * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
    (WebKit::WebFullScreenManager::restoreScrollPosition):
    * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h:
    * Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
    (WKBundlePageWillEnterFullScreen):
    (WKBundlePageDidExitFullScreen):

    Canonical link: https://commits.webkit.org/262281@main


  Commit: 411f0f23cb2931f57d1c596499392cfcfd5ac6f4
      https://github.com/WebKit/WebKit/commit/411f0f23cb2931f57d1c596499392cfcfd5ac6f4
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2023-04-27 (Thu, 27 Apr 2023)

  Changed paths:
    A LayoutTests/compositing/visibility/visibility-remove-layer-expected.html
    A LayoutTests/compositing/visibility/visibility-remove-layer.html
    M Source/WebCore/rendering/RenderLayer.cpp

  Log Message:
  -----------
  Cherry-pick 262284 at main (059e2bb75dc3). https://bugs.webkit.org/show_bug.cgi?id=253706

    RenderLayer::hasVisibleContent() incorrect when layer removed

    https://bugs.webkit.org/show_bug.cgi?id=253706
    rdar://problem/106860749

    Reviewed by Simon Fraser.

    This patch is to align WebKit with Blink / Chromium and Gecko / Firefox.

    Merge - https://chromium.googlesource.com/chromium/blink/+/c5587982b1ed1ec62452f5d2c93c0f385a3941a1

    Prior to this change, we were incorrectly dirtying
    RenderLayer::hasVisibleContent() when removing a RenderLayer from the layer
    tree. This caused us to incorrectly believe that the parent layer lacked
    visible content.

    * Source/WebCore/rendering/RenderLayer.cpp:
    (RenderLayer::removeChild):
    * LayoutTests/compositing/visibility/visibility-remove-layer.html: Add Test Case
    * LayoutTests/compositing/visibility/visibility-remove-layer-expected.html: Add Test Case

    Canonical link: https://commits.webkit.org/262284@main


Compare: https://github.com/WebKit/WebKit/compare/6cbd9746ce11...411f0f23cb29