Branch: refs/heads/webkitglib/2.38 Home: https://github.com/WebKit/WebKit Commit: 28cf4649cc6c1f13200bbe275a77163d05441fa6 https://github.com/WebKit/WebKit/commit/28cf4649cc6c1f13200bbe275a77163d05441fa6 Author: Philippe Normand <ph...@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@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 <mcatanz...@redhat.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebKit/UIProcess/Inspector/WebPageInspectorController.h Log Message: ----------- Cherry-pick 256990@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 <cgar...@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@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 <vit...@igalia.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebCore/accessibility/AXObjectCache.cpp Log Message: ----------- Cherry-pick 257235@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 <ashva...@apple.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebCore/bindings/js/JSEventListener.cpp Log Message: ----------- Cherry-pick 257027@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 <mcatanz...@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@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 <vwaterme...@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@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.la...@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 <mattwood...@apple.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebKit/Platform/IPC/StreamConnectionWorkQueue.cpp Log Message: ----------- Cherry-pick 257092@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 <karl...@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@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 <mattwood...@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@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+git...@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@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+git...@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@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 <karl...@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@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 <karl...@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@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_s...@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@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 <cdu...@apple.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebCore/page/Quirks.cpp Log Message: ----------- Cherry-pick 257302@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 <matts...@gmail.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebKit/UIProcess/gtk/ClipboardGtk4.cpp Log Message: ----------- Cherry-pick 257364@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 <gga...@apple.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp Log Message: ----------- Cherry-pick 257384@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 <ph...@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@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 <gga...@apple.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp Log Message: ----------- Cherry-pick 257433@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 <karl...@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@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.fra...@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@main (df0e5116081b). https://bugs.webkit.org/show_bug.cgi?id=248827 REGRESSION (253865@main): Crashes under RenderLayerCompositor::updateScrollingNodeForViewportConstrainedRole https://bugs.webkit.org/show_bug.cgi?id=248827 rdar://102619100 Reviewed by Alan Baradlay. In 253865@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+git...@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@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 <zdober...@igalia.com> Date: 2023-01-25 (Wed, 25 Jan 2023) Changed paths: M Source/WebKit/WebProcess/Inspector/WebInspectorUI.cpp Log Message: ----------- Cherry-pick 257547@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 _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes