[webkit-changes] [WebKit/WebKit] 28cf46: Cherry-pick 256944 at main (e3ba18ed2f68). https://bu...

[Žan Doberšek]

  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: 28cf4649cc6c1f13200bbe275a77163d05441fa6
      https://github.com/WebKit/WebKit/commit/28cf4649cc6c1f13200bbe275a77163d05441fa6
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
    M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.h

  Log Message:
  -----------
  Cherry-pick 256944 at main (e3ba18ed2f68). https://bugs.webkit.org/show_bug.cgi?id=248147

    [GStreamer] Allow RegistryScanner call sites to use the selected element factory
    https://bugs.webkit.org/show_bug.cgi?id=248147

    Reviewed by Xabier Rodriguez-Calvar.

    When a candidate GstElementFactory has been selected by the scanner, it can now be used to create a
    GstElement matching the capabilies that were probed. This can be useful in cases where a higher
    level bin such as decodebin or encodebin is not desired and we only need direct access to the
    element.

    * Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
    (WebCore::GStreamerRegistryScanner::ElementFactories::hasElementForMediaType const):
    (WebCore::GStreamerRegistryScanner::fillMimeTypeSetFromCapsMapping):
    (WebCore::GStreamerRegistryScanner::initializeDecoders):
    (WebCore::GStreamerRegistryScanner::initializeEncoders):
    (WebCore::GStreamerRegistryScanner::isCodecSupported const):
    (WebCore::GStreamerRegistryScanner::isAVC1CodecSupported const):
    (WebCore::GStreamerRegistryScanner::isConfigurationSupported const):
    * Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.h:
    (WebCore::GStreamerRegistryScanner::RegistryLookupResult::merge):
    (WebCore::GStreamerRegistryScanner::CodecLookupResult::CodecLookupResult):
    (WebCore::GStreamerRegistryScanner::CodecLookupResult::operator bool const):

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


  Commit: 4c4d0056e363109a4283a2b10cae8b3d110228a8
      https://github.com/WebKit/WebKit/commit/4c4d0056e363109a4283a2b10cae8b3d110228a8
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/Inspector/WebPageInspectorController.h

  Log Message:
  -----------
  Cherry-pick 256990 at main (138c1e2a317b). https://bugs.webkit.org/show_bug.cgi?id=248293

    Uninitialized memory read when opening web inspector
    https://bugs.webkit.org/show_bug.cgi?id=248293

    Reviewed by Yusuke Suzuki.

    WebPageInspectorController::m_enabledBrowserAgent is mistakenly not
    initialized to anything. It's initialized by
    InspectorBrowserAgent::enable and InspectorBrowserAgent::disable, but
    these functions both first check whether it's enabled before they do
    anything. That's undefined behavior. Fix is simple: initialize it.

    * Source/WebKit/UIProcess/Inspector/WebPageInspectorController.h:

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


  Commit: d73d7f48dae83fa78f9d22f9f717481443b83d95
      https://github.com/WebKit/WebKit/commit/d73d7f48dae83fa78f9d22f9f717481443b83d95
  Author: Carlos Garcia Campos <cgarcia at igalia.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/gtk/WebContextMenuProxyGtk.cpp
    M Source/WebKit/UIProcess/gtk/WebContextMenuProxyGtk.h
    M Source/WebKit/WebProcess/InjectedBundle/API/APIInjectedBundlePageContextMenuClient.h
    M Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp
    M Source/WebKit/WebProcess/InjectedBundle/InjectedBundlePageContextMenuClient.cpp
    M Source/WebKit/WebProcess/InjectedBundle/InjectedBundlePageContextMenuClient.h
    M Source/WebKit/WebProcess/WebPage/WebContextMenu.cpp

  Log Message:
  -----------
  Cherry-pick 257023 at main (f4b30ff111b4). https://bugs.webkit.org/show_bug.cgi?id=247089

    [GTK] UI process crash when opening video settings
    https://bugs.webkit.org/show_bug.cgi?id=247089

    Reviewed by Michael Catanzaro.

    Do no emit the context-menus signals for video settings popup menu.

    * Source/WebKit/UIProcess/gtk/WebContextMenuProxyGtk.cpp:
    (WebKit::WebContextMenuProxyGtk::show):
    * Source/WebKit/UIProcess/gtk/WebContextMenuProxyGtk.h:
    * Source/WebKit/WebProcess/InjectedBundle/API/APIInjectedBundlePageContextMenuClient.h:
    (API::InjectedBundle::PageContextMenuClient::getCustomMenuFromDefaultItems):
    * Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp:
    * Source/WebKit/WebProcess/InjectedBundle/InjectedBundlePageContextMenuClient.cpp:
    (WebKit::InjectedBundlePageContextMenuClient::getCustomMenuFromDefaultItems):
    * Source/WebKit/WebProcess/InjectedBundle/InjectedBundlePageContextMenuClient.h:
    * Source/WebKit/WebProcess/WebPage/WebContextMenu.cpp:
    (WebKit::WebContextMenu::menuItemsWithUserData const):

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


  Commit: 92bf4ea2eb819e78e07ccb4c43135c964f69ca67
      https://github.com/WebKit/WebKit/commit/92bf4ea2eb819e78e07ccb4c43135c964f69ca67
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/accessibility/AXObjectCache.cpp

  Log Message:
  -----------
  Cherry-pick 257235 at main (99e0cc3c3dd2). https://bugs.webkit.org/show_bug.cgi?id=246329

    [ATSPI] Modal element containing only StaticText is ignored
    https://bugs.webkit.org/show_bug.cgi?id=246329

    Reviewed by Carlos Garcia Campos.

    A modal element will not be set as the current modal when it has no
    accessible content. But when using AT-SPI, an object with
    AccessibilityRole::StaticText is ignored, since we expect its parent
    to implement org.a11y.atspi.Text interface itself.

    Fixes `accessibility/custom-elements/modal.html` time out.

    * Source/WebCore/accessibility/AXObjectCache.cpp:
    (WebCore::AXObjectCache::modalElementHasAccessibleContent):

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


  Commit: a00aaa6f47ef46b614902411f756cf2fd9125090
      https://github.com/WebKit/WebKit/commit/a00aaa6f47ef46b614902411f756cf2fd9125090
  Author: Alexey Shvayka <ashvayka at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/bindings/js/JSEventListener.cpp

  Log Message:
  -----------
  Cherry-pick 257027 at main (a8c7d4f465b1). https://bugs.webkit.org/show_bug.cgi?id=248328

    [WebIDL] Hoist protectedThis reference in JSEventListener::handleEvent()
    https://bugs.webkit.org/show_bug.cgi?id=248328

    Reviewed by Yusuke Suzuki.

    While this change is non-observable since the only caller of handleEvent(),
    innerInvokeEventListeners(), keeps it as RefPtr, theoretically both getCallData() and
    jsFunction->get() may remove currently running event listener and cause its destruction.

    * Source/WebCore/bindings/js/JSEventListener.cpp:
    (WebCore::JSEventListener::handleEvent):

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


  Commit: e6d12da9bc531a2d2d5cad2c6f1d371311a6f8d8
      https://github.com/WebKit/WebKit/commit/e6d12da9bc531a2d2d5cad2c6f1d371311a6f8d8
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp

  Log Message:
  -----------
  Cherry-pick 257276 at main (fd0db7c03a48). https://bugs.webkit.org/show_bug.cgi?id=247463

    [GTK] gsk_renderer_render_texture: assertion 'GSK_IS_RENDER_NODE (root)' failed in webkitWebViewBaseTakeViewSnapshot
    https://bugs.webkit.org/show_bug.cgi?id=247463

    Reviewed by Carlos Garcia Campos.

    I don't know how to reproduce this crash, but it happens a lot and the
    solution is clear enough. When the snapshot is empty, then the
    GskRenderNode is nullptr, and we should immediately return nullptr
    instead of trying to use it as a valid GskRenderNode. The return value
    here is already nullable, so there's nothing more to worry about.

    I'm not certain why this happens, but I think it might be associated
    with web process hangs. Doesn't matter: the UI process should be robust
    regardless.

    Thanks to Benjamin Otte for helping with my questions regarding this
    issue.

    * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:
    (webkitWebViewBaseTakeViewSnapshot):

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


  Commit: 53c72c74622ef5bd4b004d9cf589ba910812c447
      https://github.com/WebKit/WebKit/commit/53c72c74622ef5bd4b004d9cf589ba910812c447
  Author: Vivienne Watermeier <vwatermeier at igalia.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

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

  Log Message:
  -----------
  Cherry-pick 257066 at main (738525821b03). https://bugs.webkit.org/show_bug.cgi?id=248217

    [GStreamer] Fix readyState calculations
    https://bugs.webkit.org/show_bug.cgi?id=248217

    Reviewed by Philippe Normand.

    On some platforms, the audio sink is acting as a fake sink while the decoder fetches data
    from the pipeline and transfers it to the SoC drivers, even in READY and PAUSED states,
    meaning we cannot rely on buffering messages anymore.

    However, on that platform the audio sinks implements buffering queries, that are currently
    issued to the entire pipeline, which on some platforms may yield misleading results
    if some random element implements buffering queries and receives that query first.

    Thus this patch first queries the audio sink, before trying the video sink and finally
    the pipeline itself.

    Original author: Pawel Lampe <pawel.lampe at gmail.com>
    See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/975

    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::updateStates): Send buffering query to audio/video sinks first

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


  Commit: 884cb9fe7402bc104ca6ae30a68cd2fe88b26fe4
      https://github.com/WebKit/WebKit/commit/884cb9fe7402bc104ca6ae30a68cd2fe88b26fe4
  Author: Matt Woodrow <mattwoodrow at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/Platform/IPC/StreamConnectionWorkQueue.cpp

  Log Message:
  -----------
  Cherry-pick 257092 at main (1f4c8acb5b7c). https://bugs.webkit.org/show_bug.cgi?id=248417

    Don't hold the stream connection work queue lock while running the shutdown callback.
    https://bugs.webkit.org/show_bug.cgi?id=248417

    Reviewed by Kimmo Kinnunen.

    If any code within the shutdown code tries to access the lock (to remove buffer references) then we can deadlock.

    * Source/WebKit/Platform/IPC/StreamConnectionWorkQueue.cpp:
    (IPC::StreamConnectionWorkQueue::startProcessingThread):

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


  Commit: 5723ae983d3ef0d683d468f78a302f1640be8da6
      https://github.com/WebKit/WebKit/commit/5723ae983d3ef0d683d468f78a302f1640be8da6
  Author: Karl Dubost <karlcow at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/html/HTMLVideoElement.cpp
    M Source/WebCore/page/Quirks.cpp
    M Source/WebCore/page/Quirks.h

  Log Message:
  -----------
  Cherry-pick 257107 at main (75437028a4f8). https://bugs.webkit.org/show_bug.cgi?id=248296

    Remove Quirks needsAkamaiMediaPlayerQuirk
    https://bugs.webkit.org/show_bug.cgi?id=248296
    rdar://102636420

    Reviewed by Eric Carlson.

    As mentioned in the bug, this was tested on multiple links
    with site specific hacks disabled on the iOS device and
    the fullscreen is working.

    * Source/WebCore/html/HTMLVideoElement.cpp:
    (WebCore::HTMLVideoElement::webkitDisplayingFullscreen):
    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::needsAkamaiMediaPlayerQuirk const): Deleted.
    * Source/WebCore/page/Quirks.h:

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


  Commit: e1dd982327ebc4c63b07938e31c3096d66ac2de4
      https://github.com/WebKit/WebKit/commit/e1dd982327ebc4c63b07938e31c3096d66ac2de4
  Author: Matt Woodrow <mattwoodrow at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/platform/ThreadGlobalData.cpp
    M Source/WebCore/platform/ThreadGlobalData.h
    M Source/WebCore/platform/graphics/FontCache.h

  Log Message:
  -----------
  Cherry-pick 257160 at main (2d8a9204f770). https://bugs.webkit.org/show_bug.cgi?id=248502

    Manually invalidate the FontCache before clearing ThreadGlobalData.
    https://bugs.webkit.org/show_bug.cgi?id=248502

    Reviewed by Cameron McCormack.

    Destructing the FontCache can recurse back into the ThreadGlobalData getter (to remove cached entries), so
    we want to manually clear the FontCache before clearing the ThreadGlobalData pointer.

    This also moves m_destroyed to earlier in the class, so it's guaranteed to be destructed after m_fontCache.

    * Source/WebCore/platform/ThreadGlobalData.cpp:
    (WebCore::ThreadGlobalData::destroy):
    * Source/WebCore/platform/ThreadGlobalData.h:
    * Source/WebCore/platform/graphics/FontCache.h:

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


  Commit: 779d22920886fedad6e26a6f5af74f8d53726e1b
      https://github.com/WebKit/WebKit/commit/779d22920886fedad6e26a6f5af74f8d53726e1b
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    A LayoutTests/editing/execCommand/delete-non-editable-range-crash-expected.txt
    A LayoutTests/editing/execCommand/delete-non-editable-range-crash.html
    M Source/WebCore/editing/DeleteSelectionCommand.cpp

  Log Message:
  -----------
  Cherry-pick 257203 at main (b83027e6d7d0). https://bugs.webkit.org/show_bug.cgi?id=248486

    Potential crash fix by bailing from DeleteSelectionCommand::doApply when selection isn't editable

    Potential crash fix by bailing from DeleteSelectionCommand::doApply when selection isn't editable
    https://bugs.webkit.org/show_bug.cgi?id=248486

    Reviewed by Ryosuke Niwa.

    Merge - https://src.chromium.org/viewvc/blink?view=revision&revision=190121

    This patch is to harden the function doApply() by bailing early by ensuring the selection to delete is not editable.

    * Source/WebCore/editing/DeleteSelectionCommand.cpp:
    (DeleteSelectionCommand::doApply): Add condition about selection being non-editable
    * LayoutTests/editing/execCommand/delete-non-editable-range-crash.html: Add Test Case
    * LayoutTests/editing/execCommand/delete-non-editable-range-crash-expected.txt: Add Test Case Expectations

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


  Commit: eb8120219931034fe02ca7ca7a0066f8bb9072a9
      https://github.com/WebKit/WebKit/commit/eb8120219931034fe02ca7ca7a0066f8bb9072a9
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    A LayoutTests/fast/css/font-face-attribute-remove-expected.html
    A LayoutTests/fast/css/font-face-attribute-remove.html
    M Source/WebCore/html/HTMLFontElement.cpp

  Log Message:
  -----------
  Cherry-pick 257248 at main (7f50b6d09b38). https://bugs.webkit.org/show_bug.cgi?id=248434

    Potential Crash fix by not propagating empty value for face attribute

    Potential Crash fix by not propagating empty value for face attribute
    https://bugs.webkit.org/show_bug.cgi?id=248434

    Reviewed by Tim Nguyen.

    Merge - https://src.chromium.org/viewvc/blink?view=revision&revision=190788

    This patch is to add check to ensure that "faceAttr" is not null / empty value and such values are not propagated to lead to stability issues (i.e., crashes).

    * Source/WebCore/html/HTMLFontElement.cpp:
    (HTMLFontElement::collectPresentationalHintsForAttribute): Add check for empty / null values
    * LayoutTests/fast/css/font-face-attribute-remove.html: Add Test Case
    * LayoutTests/fast/css/font-face-attribute-remove-expected.html: Add Test Case Expectation

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


  Commit: 49575ce5da00b6d6ae022b395abcdc2ec0401cea
      https://github.com/WebKit/WebKit/commit/49575ce5da00b6d6ae022b395abcdc2ec0401cea
  Author: Karl Dubost <karlcow at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/css/FontFace.cpp
    M Source/WebCore/page/Quirks.cpp
    M Source/WebCore/page/Quirks.h

  Log Message:
  -----------
  Cherry-pick 257268 at main (632e811d0686). https://bugs.webkit.org/show_bug.cgi?id=248332

    [QUIRK] Remove needsshouldStripQuotationMarkInFontFaceSetFamily
    https://bugs.webkit.org/show_bug.cgi?id=248332
    rdar://102656841

    Reviewed by Ryosuke Niwa.

    Google has probably changed the way they handled the font name when
    they have spaces in their names.
    The Quirk doesn't seem to be useful anymore. Tested on on Safari
    Tech Preview 158 with Site Specific Hacks being disabled
    This has been tested on a local build and the font is working.

    * Source/WebCore/css/FontFace.cpp:
    (WebCore::FontFace::setFamily):
    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::shouldStripQuotationMarkInFontFaceSetFamily const): Deleted.
    * Source/WebCore/page/Quirks.h:

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


  Commit: bb3c7d5fd30a790fd1220e44366ffb3c76ce7e47
      https://github.com/WebKit/WebKit/commit/bb3c7d5fd30a790fd1220e44366ffb3c76ce7e47
  Author: Karl Dubost <karlcow at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M LayoutTests/TestExpectations
    M Source/WebCore/css/fullscreen.css
    M Source/WebCore/page/Quirks.cpp
    M Source/WebCore/page/Quirks.h
    M Source/WebCore/rendering/RenderTheme.h
    M Source/WebCore/style/UserAgentStyle.cpp

  Log Message:
  -----------
  Cherry-pick 257271 at main (6525018e7c18). https://bugs.webkit.org/show_bug.cgi?id=248323

    Remove needsBlackFullscreenBackgroundQuirk
    https://bugs.webkit.org/show_bug.cgi?id=248323
    rdar://102653160

    Reviewed by Tim Nguyen.

    This is removing the mlb.com quirk which was needed when
    the background was white. Backdrop will take over.
    A simple change to allow the fake backdrop to take effect.
    SeeAlso https://github.com/WebKit/WebKit/pull/6021/files
    This also aligns WebKit with Gecko for the fullscreen
    background.
    Further fixes will be made in
    https://github.com/WebKit/WebKit/pull/6688
    https://bugs.webkit.org/show_bug.cgi?id=248148

    * LayoutTests/TestExpectations:
    * LayoutTests/compositing/no-compositing-when-fulll-screen-is-present-expected.txt:
    * LayoutTests/platform/gtk/compositing/no-compositing-when-fulll-screen-is-present-expected.txt:
    * Source/WebCore/css/fullscreen.css:
    (:-webkit-full-screen):
    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::needsBlackFullscreenBackgroundQuirk const): Deleted.
    * Source/WebCore/page/Quirks.h:
    * Source/WebCore/rendering/RenderTheme.h:
    (WebCore::RenderTheme::extraFullScreenStyleSheet): Deleted.
    * Source/WebCore/style/UserAgentStyle.cpp:
    (WebCore::Style::UserAgentStyle::ensureDefaultStyleSheetsForElement):

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


  Commit: 906272f07a38f45089855d4421a041300b85c209
      https://github.com/WebKit/WebKit/commit/906272f07a38f45089855d4421a041300b85c209
  Author: Chirag M Shah <chirag_m_shah at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    A LayoutTests/fast/rendering/render-style-null-optgroup-crash-expected.txt
    A LayoutTests/fast/rendering/render-style-null-optgroup-crash.html
    M Source/WebCore/rendering/RenderListBox.cpp

  Log Message:
  -----------
  Cherry-pick 257295 at main (324460324818). https://bugs.webkit.org/show_bug.cgi?id=248575

    Don't crash when RenderStyle is NULL for elements like optgroup when
    rendering
    https://bugs.webkit.org/show_bug.cgi?id=248575

    Reviewed by Simon Fraser.

    * LayoutTests/fast/rendering/render-style-null-optgroup-crash-expected.txt: Added.
    * LayoutTests/fast/rendering/render-style-null-optgroup-crash.html: Added.
    * Source/WebCore/rendering/RenderListBox.cpp:
    (WebCore::RenderListBox::paintItemForeground):
    (WebCore::RenderListBox::paintItemBackground):

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


  Commit: ca42e91688db719381549f5cd401e98aeaecbc65
      https://github.com/WebKit/WebKit/commit/ca42e91688db719381549f5cd401e98aeaecbc65
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/page/Quirks.cpp

  Log Message:
  -----------
  Cherry-pick 257302 at main (1a3a9cb3d50d). https://bugs.webkit.org/show_bug.cgi?id=248629

    Soundcloud.com Login Issue
    https://bugs.webkit.org/show_bug.cgi?id=248629

    Reviewed by Sihui Liu.

    Add Soundcloud.com to the list of sites where we need to turn on the
    showModalDialog quirk to avoid breaking login.

    With the quirk, the showModalDialog property exists but its value is
    undefined. Like for the other sites, this is sufficient to restore
    functionality. Those sites seem to check that the property exists for
    some reason.

    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::shouldExposeShowModalDialog const):

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


  Commit: dc8698700914d0c69d39a6010a11d22a45030a49
      https://github.com/WebKit/WebKit/commit/dc8698700914d0c69d39a6010a11d22a45030a49
  Author: Matt Turner <mattst88 at gmail.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/UIProcess/gtk/ClipboardGtk4.cpp

  Log Message:
  -----------
  Cherry-pick 257364 at main (285ff73b5f6d). https://bugs.gentoo.org/882609

    [GTK] Fix build failure in ClipboardGtk4.cpp
    https://bugs.gentoo.org/882609

    Reviewed by Michael Catanzaro

    * Source/WebKit/UIProcess/gtk/ClipboardGtk4.cpp:

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


  Commit: eb583c060bf47dc00632f148037741f8fc28bf42
      https://github.com/WebKit/WebKit/commit/eb583c060bf47dc00632f148037741f8fc28bf42
  Author: Geoffrey Garen <ggaren at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp

  Log Message:
  -----------
  Cherry-pick 257384 at main (dcbdfca03eb0). https://bugs.webkit.org/show_bug.cgi?id=248782

    Remove an ASSERT from WebFullScreenManager::willExitFullScreen()
    https://bugs.webkit.org/show_bug.cgi?id=248782
    rdar://102997345

    Reviewed by Aditya Keerthi.

    This ASSERT fires when running media/video-fullscreen-reload-crash.html.

    * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
    (WebKit::WebFullScreenManager::willExitFullScreen):

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


  Commit: 9c333ed13152454fe230895939a07ac1aa2b3ca0
      https://github.com/WebKit/WebKit/commit/9c333ed13152454fe230895939a07ac1aa2b3ca0
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
    M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h
    M Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.cpp
    M Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.cpp
    M Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.h

  Log Message:
  -----------
  Cherry-pick 257408 at main (3a57c6e319c3). https://bugs.webkit.org/show_bug.cgi?id=248741

    [GStreamer][MSE] Misc capabilities and EOS handling improvements
    https://bugs.webkit.org/show_bug.cgi?id=248741

    Reviewed by Alicia Boya Garcia.

    When the MediaSource is marked as ended, set the player network state to `loaded`, aligning with the
    spec and AVF backend. The `addSourceBuffer` method now returns `NotSupported` in case the
    AppendPipeline is not able to handle the given contentType.

    * Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
    (WebCore::MediaPlayerPrivateGStreamerMSE::setNetworkState):
    * Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h:
    * Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.cpp:
    (WebCore::MediaSourcePrivateGStreamer::addSourceBuffer):
    (WebCore::MediaSourcePrivateGStreamer::markEndOfStream):
    * Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.cpp:
    (WebCore::SourceBufferPrivateGStreamer::isContentTypeSupported):
    * Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.h:

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


  Commit: 41fa3ea1dbe2475f4bcef7b2286f51b0f3b81d15
      https://github.com/WebKit/WebKit/commit/41fa3ea1dbe2475f4bcef7b2286f51b0f3b81d15
  Author: Geoffrey Garen <ggaren at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp

  Log Message:
  -----------
  Cherry-pick 257433 at main (0dc90f513149). https://bugs.webkit.org/show_bug.cgi?id=248829

    Remove more ASSERTs from WebFullScreenManager::willExitFullScreen()
    https://bugs.webkit.org/show_bug.cgi?id=248829
    <rdar://problem/103033664>

    Reviewed by Ryan Haddad.

    Remove all m_element ASSERTs in the exit path. Some are still firing
    when running media/video-fullscreen-reload-crash.html.

    * Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
    (WebKit::WebFullScreenManager::didExitFullScreen):
    (WebKit::WebFullScreenManager::requestExitFullScreen):

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


  Commit: 7b29c4cbf4e7d4964309800a8bae349d95d9e57e
      https://github.com/WebKit/WebKit/commit/7b29c4cbf4e7d4964309800a8bae349d95d9e57e
  Author: Karl Dubost <karlcow at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M LayoutTests/media/media-usage-state-expected.txt
    M LayoutTests/media/media-usage-state.html
    M Source/WebCore/PAL/pal/cocoa/UsageTrackingSoftLink.h
    M Source/WebCore/PAL/pal/cocoa/UsageTrackingSoftLink.mm
    M Source/WebCore/html/MediaElementSession.cpp
    M Source/WebCore/page/Quirks.cpp
    M Source/WebCore/page/Quirks.h
    M Source/WebCore/platform/graphics/MediaUsageInfo.h
    M Source/WebCore/testing/Internals.cpp
    M Source/WebCore/testing/Internals.h
    M Source/WebCore/testing/Internals.idl
    M Source/WebKit/UIProcess/Media/cocoa/MediaUsageManagerCocoa.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm

  Log Message:
  -----------
  Cherry-pick 257451 at main (a1197f89b028). https://bugs.webkit.org/show_bug.cgi?id=248199

    Remove Quirk for shouldAutoplayForArbitraryUserGesture
    https://bugs.webkit.org/show_bug.cgi?id=248199
    <rdar://102743471>

    Reviewed by Eric Carlson.

    The quirk is not needed anymore. Probably the way the way
    twitter and facebook embed videos has changed. This has been tested
    on Safari 15.5 and Safari Technical Preview 158, with Site Specific
    Hacks disabled.

    * LayoutTests/media/media-usage-state-expected.txt:
    * LayoutTests/media/media-usage-state.html:
    * Source/WebCore/html/MediaElementSession.cpp:
    (WebCore::MediaElementSession::playbackStateChangePermitted const):
    (WebCore::MediaElementSession::updateMediaUsageIfChanged):
    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::shouldAutoplayForArbitraryUserGesture const): Deleted.
    * Source/WebCore/page/Quirks.h:
    * Source/WebCore/PAL/pal/cocoa/UsageTrackingSoftLink.h:
    * Source/WebCore/PAL/pal/cocoa/UsageTrackingSoftLink.mm:
    * Source/WebCore/platform/graphics/MediaUsageInfo.h:
    (WebCore::MediaUsageInfo::operator== const):
    (WebCore::MediaUsageInfo::encode const):
    (WebCore::MediaUsageInfo::decode):
    * Source/WebCore/testing/Internals.cpp:
    (WebCore::Internals::mediaUsageState const):
    * Source/WebCore/testing/Internals.h:
    * Source/WebCore/testing/Internals.idl:
    * Source/WebKit/UIProcess/Media/cocoa/MediaUsageManagerCocoa.mm:
    (WebKit::usageTrackingAvailable):
    (WebKit::MediaUsageManagerCocoa::updateMediaUsage):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm:

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


  Commit: f465cb1696a89380d28e3d94ff4dc65c5c5b13eb
      https://github.com/WebKit/WebKit/commit/f465cb1696a89380d28e3d94ff4dc65c5c5b13eb
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    A LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor-expected.txt
    A LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor.html
    M Source/WebCore/rendering/RenderLayer.cpp
    M Source/WebCore/rendering/RenderLayer.h
    M Source/WebCore/rendering/RenderLayerCompositor.cpp
    M Source/WebCore/rendering/RenderLayerScrollableArea.cpp

  Log Message:
  -----------
  Cherry-pick 257455 at main (df0e5116081b). https://bugs.webkit.org/show_bug.cgi?id=248827

    REGRESSION (253865 at main): Crashes under RenderLayerCompositor::updateScrollingNodeForViewportConstrainedRole
    https://bugs.webkit.org/show_bug.cgi?id=248827
    rdar://102619100

    Reviewed by Alan Baradlay.

    In 253865 at main I introduced `m_viewportAnchorLayer`, which is used by the scrolling tree
    to move fixed and sticky position layers. However, this revealed bugs in the compositing
    dirty state management in the RenderLayer tree, where some types of tree mutations would
    fail to trigger the "configuration" compositing update on a composited layer which is
    responsible for the addition/removal of the `m_viewportAnchorLayer`.

    From the collection of crash reports, I diagnosed two scenarios:

    On google.com, when selecting results in the map view (rdar://102713246), a fixed layer
    gained/lost a transformed ancestor. Transforms act as containing block for fixed, so
    this changes whether the fixed layer is viewport-constrained. Fixed by having
    `RenderLayer::setBehavesAsFixed()` call `setNeedsCompositingConfigurationUpdate()` on
    fixed layers. Normally repaints trigger `setNeedsCompositingConfigurationUpdate()`; I
    was not able to creation a reduction for this (the google page has nested fixed and
    `visibility:hidden`, which may contribute).

    The second scenario involved a sticky position layer which gains/loses an
    async-scrollable ancestor. Fixed by having
    `RenderLayerScrollableArea::computeHasCompositedScrollableOverflow()` call
    `setDescendantsNeedUpdateBackingAndHierarchyTraversal()` on the stacking context
    ancestor. Tested by sticky-gain-composited-scrolling-ancestor.html.

    Also defensively early return in `computeFixedViewportConstraints()` and
    `computeStickyViewportConstraints()` if the anchor layer is null.

    * LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor-expected.txt: Added.
    * LayoutTests/scrollingcoordinator/scrolling-tree/sticky-gain-composited-scrolling-ancestor.html: Added.
    * Source/WebCore/rendering/RenderLayer.cpp:
    (WebCore::RenderLayer::recursiveUpdateLayerPositions):
    (WebCore::RenderLayer::setBehavesAsFixed):
    * Source/WebCore/rendering/RenderLayer.h:
    * Source/WebCore/rendering/RenderLayerCompositor.cpp:
    (WebCore::RenderLayerCompositor::computeFixedViewportConstraints const):
    (WebCore::RenderLayerCompositor::computeStickyViewportConstraints const):
    * Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
    (WebCore::RenderLayerScrollableArea::computeHasCompositedScrollableOverflow):

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


  Commit: 03089020169f34bb0a145560dccfa2a2acd8cebb
      https://github.com/WebKit/WebKit/commit/03089020169f34bb0a145560dccfa2a2acd8cebb
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    A LayoutTests/editing/execCommand/crash-object-cloning-expected.txt
    A LayoutTests/editing/execCommand/crash-object-cloning.html
    M Source/WebCore/editing/CompositeEditCommand.cpp

  Log Message:
  -----------
  Cherry-pick 257465 at main (ef64a1c22827). https://bugs.webkit.org/show_bug.cgi?id=202906

    ASSERT in appendNode() should not fire when OBJECTS are cloned

    ASSERT in appendNode() should not fire when OBJECTS are cloned
    https://bugs.webkit.org/show_bug.cgi?id=202906

    Reviewed by Ryosuke Niwa.

    Merge - https://src.chromium.org/viewvc/blink?view=revision&revision=187132

    The ASSERT may be triggered in CompositeEditCommand::appendNode
    when the fallback content of an OBJECT element is cloned because
    the canHaveChildrenForEditing is not reliable for OBJECTs until
    their render object is created. This issue is fixed by ignoring
    the return value of canHaveChildrenForEditing when an OBJECT is
    created.

    * Source/WebCore/editing/CompositeEditCommand.cpp:
    (CompositeEditCommand::insertNodeAt): Update Assertion and add comment to explain about assertion
    * LayoutTests/editing/execCommand/crash-object-cloning.html: Add Test Case
    * LayoutTests/editing/execCommand/crash-object-cloning-expected.txt: Add Test Case Expectation

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


  Commit: bb02c5c926cde071577c948254cdb39306d4154f
      https://github.com/WebKit/WebKit/commit/bb02c5c926cde071577c948254cdb39306d4154f
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2023-01-25 (Wed, 25 Jan 2023)

  Changed paths:
    M Source/WebKit/WebProcess/Inspector/WebInspectorUI.cpp

  Log Message:
  -----------
  Cherry-pick 257547 at main (65e9b93a95fd). https://bugs.webkit.org/show_bug.cgi?id=248935

    [WPE] Unreviewed unified-builds build fix
    https://bugs.webkit.org/show_bug.cgi?id=248935

    Unreviewed, adding a missing header to the WebInspectorUI implementation file
    to avoid incomplete-class build errors when the unified builds system shuffles
    that file into a different set.

    * Source/WebKit/WebProcess/Inspector/WebInspectorUI.cpp:

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


Compare: https://github.com/WebKit/WebKit/compare/63253483cd07...bb02c5c926cd