Branch: refs/heads/webkitglib/2.40
Home: https://github.com/WebKit/WebKit
Commit: cabee89eb42c69c8f3dd3909a37d901a2d7413b6
https://github.com/WebKit/WebKit/commit/cabee89eb42c69c8f3dd3909a37d901a2d7413b6
Author: Arunsundar Kannan <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
M
Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.cpp
M Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.h
M Source/WebKit/NetworkProcess/NetworkContentRuleListManager.cpp
M Source/WebKit/NetworkProcess/NetworkContentRuleListManager.h
M Source/WebKit/NetworkProcess/NetworkProcess.h
Log Message:
-----------
Cherry-pick 262240@main (9f577500830e).
https://bugs.webkit.org/show_bug.cgi?id=254500.
Remove smart pointer violation in NetworkContentRuleListManager,
LegacyCustomProtocolManager.
https://bugs.webkit.org/show_bug.cgi?id=254500.
rdar://107255403.
Reviewed by Chris Dumez.
m_process is using raw references, this changes uses WTF:: Ref.
*
Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.cpp:
(WebKit::LegacyCustomProtocolManager::LegacyCustomProtocolManager):
(WebKit::LegacyCustomProtocolManager::startLoading):
(WebKit::LegacyCustomProtocolManager::stopLoading):
*
Source/WebKit/NetworkProcess/CustomProtocols/LegacyCustomProtocolManager.h:
* Source/WebKit/NetworkProcess/NetworkContentRuleListManager.cpp:
(WebKit::NetworkContentRuleListManager::contentExtensionsBackend):
* Source/WebKit/NetworkProcess/NetworkContentRuleListManager.h:
Canonical link: https://commits.webkit.org/262240@main
Commit: a42f850c9f9c3c6206520fb7e0ed743656d11f55
https://github.com/WebKit/WebKit/commit/a42f850c9f9c3c6206520fb7e0ed743656d11f55
Author: Enrique Ocaña González <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp
Log Message:
-----------
Cherry-pick 262144@main (9bc4d3cabf88).
https://bugs.webkit.org/show_bug.cgi?id=228820
[MSE][GStreamer] Missing support for aborts not followed by an
initialization segment
https://bugs.webkit.org/show_bug.cgi?id=228820
This patch performs a flush on the AppendPipeline on SourceBuffer::abort().
Such action drains the AppendPipeline but leaves the demuxer still
configured with
the context provided by the last init segment. This is in compliance with
the spec,
which mandates that there's no need to append an init segment after an
abort,
because the last one should be reused.
For this patch to work, the following GStreamer merge requests, scheduled
to be
landed on 1.23.1, must be present:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4101.
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4199.
If the GStreamer version is lower than the required one, the old reset
technique,
consisting of setting the pipeline to READY and then PLAYING, is applied.
In the current circumstances, the layout tests still don't pass, so this
patch
isn't unskipping them yet. media-mp4-h264-partial-abort.html should be
unskipped
when we start using a GStreamer version that includes the MRs.
media-webm-opus-partial-abort.html should be unskipped when
https://github.com/WebKit/WebKit/pull/11807 lands.
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1016
Reviewed by Alicia Boya Garcia.
* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
(WebCore::AppendPipeline::resetParserState): If supported by GStreamer,
perform a flush instead of setting the pipeline state to READY and then again
to PLAYING.
Canonical link: https://commits.webkit.org/262144@main
Commit: 7f7073d7671af9cb02d1a94db2e441ce3b71b757
https://github.com/WebKit/WebKit/commit/7f7073d7671af9cb02d1a94db2e441ce3b71b757
Author: Mark Lam <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssembler.h
Log Message:
-----------
Cherry-pick 262260@main (dd5da1dca9b6).
https://bugs.webkit.org/show_bug.cgi?id=254634
Only CPU(X86_64) should do constant blinding.
https://bugs.webkit.org/show_bug.cgi?id=254634
<rdar://problem/107345556>
Reviewed by Justin Michaud and Yusuke Suzuki.
It is not relevant for CPUs with fixed alignment instruction sets.
* Source/JavaScriptCore/assembler/MacroAssembler.h:
(JSC::MacroAssembler::shouldBlind):
Canonical link: https://commits.webkit.org/262260@main
Commit: e2996b36dd38fee0c43fe8e8cb752bf31fb133f0
https://github.com/WebKit/WebKit/commit/e2996b36dd38fee0c43fe8e8cb752bf31fb133f0
Author: Chris Dumez <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
Log Message:
-----------
Cherry-pick 262274@main (ea7b758f5d2e).
https://bugs.webkit.org/show_bug.cgi?id=254646
RenderBox::computeInlineDirectionMargins() is causing system malloc heap
allocations
https://bugs.webkit.org/show_bug.cgi?id=254646
Reviewed by Darin Adler.
RenderBox::computeInlineDirectionMargins() was causing system malloc heap
allocations due to its use of std::function:
Sample Count, Samples %, Normalized CPU %, Symbol
21, 0.0%, 0.0%, tiny_malloc_should_clear (in libsystem_malloc.dylib)
20, 0.0%, 0.0%, szone_malloc_should_clear (in libsystem_malloc.dylib)
8, 0.0%, 0.0%, operator new(unsigned long) (in libc++abi.dylib)
5, 0.0%, 0.0%,
WebCore::RenderBox::computeInlineDirectionMargins(WebCore::RenderBlock const&,
WebCore::LayoutUnit, std::__1::optional<WebCore::LayoutUnit>,
WebCore::LayoutUnit, WebCore::LayoutUnit&, WebCore::LayoutUnit&) const (in
WebCore)
3, 0.0%, 0.0%,
WebCore::RenderBox::fillAvailableMeasure(WebCore::LayoutUnit,
WebCore::LayoutUnit&, WebCore::LayoutUnit&) const (in WebCore)
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeLogicalWidthInFragment const):
(WebCore::RenderBox::fillAvailableMeasure const):
(WebCore::RenderBox::computeOrTrimInlineMargin const):
(WebCore::RenderBox::computeInlineDirectionMargins const):
* Source/WebCore/rendering/RenderBox.h:
Canonical link: https://commits.webkit.org/262274@main
Commit: 5ab093369840e0ca98c0d803c6d12cf29dfa3ed1
https://github.com/WebKit/WebKit/commit/5ab093369840e0ca98c0d803c6d12cf29dfa3ed1
Author: Tim Nguyen <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
A
LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto-expected.txt
A
LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp
Log Message:
-----------
Cherry-pick 262281@main (b8bf24826066).
https://bugs.webkit.org/show_bug.cgi?id=254632
Exiting fullscreen on ign.com fails to restore scroll position
https://bugs.webkit.org/show_bug.cgi?id=254632
rdar://106774841
Reviewed by Jer Noble.
The bug is caused by a missing layout in some particular situations
(overflow: auto + percentage sizes) before restoring the scroll position.
Adding a call to forceLayout() fixes the issue.
However, in order for the test to work in WebKit Test runner, the
save/restoreScrollPosition methods also need to be called in the InjectedBundle.
Safari & minibrowser use a different codepath (involving the UIProcess).
*
LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto-expected.txt:
Added.
*
LayoutTests/fullscreen/fullscreen-restore-scroll-position-overflow-auto.html:
Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
(WebKit::WebFullScreenManager::restoreScrollPosition):
* Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h:
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageWillEnterFullScreen):
(WKBundlePageDidExitFullScreen):
Canonical link: https://commits.webkit.org/262281@main
Commit: 411f0f23cb2931f57d1c596499392cfcfd5ac6f4
https://github.com/WebKit/WebKit/commit/411f0f23cb2931f57d1c596499392cfcfd5ac6f4
Author: Ahmad Saleem <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
A LayoutTests/compositing/visibility/visibility-remove-layer-expected.html
A LayoutTests/compositing/visibility/visibility-remove-layer.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick 262284@main (059e2bb75dc3).
https://bugs.webkit.org/show_bug.cgi?id=253706
RenderLayer::hasVisibleContent() incorrect when layer removed
https://bugs.webkit.org/show_bug.cgi?id=253706
rdar://problem/106860749
Reviewed by Simon Fraser.
This patch is to align WebKit with Blink / Chromium and Gecko / Firefox.
Merge -
https://chromium.googlesource.com/chromium/blink/+/c5587982b1ed1ec62452f5d2c93c0f385a3941a1
Prior to this change, we were incorrectly dirtying
RenderLayer::hasVisibleContent() when removing a RenderLayer from the layer
tree. This caused us to incorrectly believe that the parent layer lacked
visible content.
* Source/WebCore/rendering/RenderLayer.cpp:
(RenderLayer::removeChild):
* LayoutTests/compositing/visibility/visibility-remove-layer.html: Add Test
Case
* LayoutTests/compositing/visibility/visibility-remove-layer-expected.html:
Add Test Case
Canonical link: https://commits.webkit.org/262284@main
Compare: https://github.com/WebKit/WebKit/compare/6cbd9746ce11...411f0f23cb29
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
