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
