Branch: refs/heads/webkitglib/2.44
Home: https://github.com/WebKit/WebKit
Commit: 1d4824ae52feb74ac746e59bcfe1ebce8749985c
https://github.com/WebKit/WebKit/commit/1d4824ae52feb74ac746e59bcfe1ebce8749985c
Author: Philippe Normand <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/gstreamer/VideoEncoderPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 276261@main (b65e2001a308).
https://bugs.webkit.org/show_bug.cgi?id=271110
[GStreamer] Caps negotiation issue in video encoder for I422 formats
https://bugs.webkit.org/show_bug.cgi?id=271110
Reviewed by Xabier Rodriguez-Calvar.
The encoder was being configured to convert input buffers to Y422, which is
not a valid GStreamer
video format. Use I422 instead.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/platform/gstreamer/VideoEncoderPrivateGStreamer.cpp:
(webkit_video_encoder_class_init):
Canonical link: https://commits.webkit.org/276261@main
Canonical link: https://commits.webkit.org/274313.376@webkitglib/2.44
Commit: e2bb9ccd6f785a927b35fc366775cc5cf293cc4d
https://github.com/WebKit/WebKit/commit/e2bb9ccd6f785a927b35fc366775cc5cf293cc4d
Author: Antti Koivisto <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A LayoutTests/media/track/captions-webvtt/inline.vtt
A LayoutTests/media/track/webvtt-inline-expected.txt
A LayoutTests/media/track/webvtt-inline.html
M Source/WebCore/Modules/modern-media-controls/controls/text-tracks.css
M Source/WebCore/css/mediaControls.css
Log Message:
-----------
Cherry-pick 275918@main (472c2a9abc39).
https://bugs.webkit.org/show_bug.cgi?id=270783
REGRESSION(272743@main): WebVTT default styling is broken
https://bugs.webkit.org/show_bug.cgi?id=270783
rdar://124380882
Reviewed by Anne van Kesteren.
272743@main changed the attribute name for pseudo elements.
The WebVTT styling relied on those names.
* LayoutTests/media/track/captions-webvtt/inline.vtt: Added.
* LayoutTests/media/track/webvtt-inline-expected.txt: Added.
* LayoutTests/media/track/webvtt-inline.html: Added.
Add a test. We had no coverage.
* Source/WebCore/Modules/modern-media-controls/controls/text-tracks.css:
([useragentpart="-webkit-media-text-track-display"]):
(u):
(i):
(.hidden):
([pseudo="-webkit-media-text-track-display"] b): Deleted.
([pseudo="-webkit-media-text-track-display"] u): Deleted.
([pseudo="-webkit-media-text-track-display"] i): Deleted.
([pseudo="-webkit-media-text-track-display"] .hidden): Deleted.
* Source/WebCore/css/mediaControls.css:
([useragentpart="-webkit-media-text-track-display"]):
(u):
(i):
(.hidden):
Also add missing .hidden to this legacy stylesheet.
([pseudo="-webkit-media-text-track-display"] b): Deleted.
([pseudo="-webkit-media-text-track-display"] u): Deleted.
([pseudo="-webkit-media-text-track-display"] i): Deleted.
Canonical link: https://commits.webkit.org/275918@main
Canonical link: https://commits.webkit.org/274313.377@webkitglib/2.44
Commit: 2536b831c481ba3798e2f4396eec4c5e2147bf5c
https://github.com/WebKit/WebKit/commit/2536b831c481ba3798e2f4396eec4c5e2147bf5c
Author: Chris Dumez <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxyInternals.h
Log Message:
-----------
Cherry-pick 275921@main (0a93df5a4011).
https://bugs.webkit.org/show_bug.cgi?id=270796
Regression: Pages that display notifications now get suspended as soon as
backgrounded
https://bugs.webkit.org/show_bug.cgi?id=270796
rdar://124390299
Reviewed by Ben Nham.
We used to prevent suspension in the background of pages that show (or are
likely to show) notifications. However, we recently stopped taking
near-suspended assertions on both iOS and macOS and it broke this heuristic.
To address the issue, we now take a background activity whenever we get a
signal that a page displayed (or is likely to display) notifications. This
way,
the page won't suspend after backgrounding, even though we're no longer
taking
near-suspended assertions.
Note that the heuristic was also checking if a page updated its title while
in
the background. This part of the heuristic is still broken and still needs
to
be addressed in a follow-up.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didCommitLoadForFrame):
(WebKit::WebPageProxy::didFailLoadForFrame):
(WebKit::WebPageProxy::resetStateAfterProcessExited):
(WebKit::WebPageProxy::pageWillLikelyUseNotifications):
(WebKit::WebPageProxy::showNotification):
* Source/WebKit/UIProcess/WebPageProxyInternals.h:
Canonical link: https://commits.webkit.org/275921@main
Canonical link: https://commits.webkit.org/274313.378@webkitglib/2.44
Commit: 2b1d61ab069aadcb26102dfd40965535b01f0a91
https://github.com/WebKit/WebKit/commit/2b1d61ab069aadcb26102dfd40965535b01f0a91
Author: Antti Koivisto <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A
LayoutTests/fast/animation/animation-with-DOM-mutation-and-display-none-expected.html
A
LayoutTests/fast/animation/animation-with-DOM-mutation-and-display-none.html
M Source/WebCore/style/StyleTreeResolver.cpp
Log Message:
-----------
Cherry-pick 276035@main (d83537abc7e7).
https://bugs.webkit.org/show_bug.cgi?id=270697
REGRESSION (iOS 17.4, macOS 14.4, 270890@main): Animating element with
display: none still remain visible
https://bugs.webkit.org/show_bug.cgi?id=270697
rdar://124289418
Reviewed by Antoine Quint and Darin Adler.
The page sets the root of the overlay containing tree to display:none and
immediately (before style recall) reinserts
it into another position in the document, causing render tree teardown.
When we recompute the style (applying display:none)
we don't consider it a style change since there was no existing style due
to the earlier teardown.
In this case we fail to clear lastStyleChangeEventStyle which has been set
by an animation on the element.
Another animation triggered style recalc comes along, takes the optimized
AnimationOnly code path and picks up
the lastStyleChangeEventStyle (which doesn't have display:none) bringing
the element back alive.
*
LayoutTests/fast/animation/animation-with-DOM-mutation-and-display-none-expected.html:
Added.
*
LayoutTests/fast/animation/animation-with-DOM-mutation-and-display-none.html:
Added.
* Source/WebCore/style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::resolveElement):
Fix by clearing lastStyleChangeEventStyle also when we have a style change
to display:none without existing renderer.
Canonical link: https://commits.webkit.org/276035@main
Canonical link: https://commits.webkit.org/274313.379@webkitglib/2.44
Commit: 8474f9911005fe75ff42666ceba3ac189e8aac82
https://github.com/WebKit/WebKit/commit/8474f9911005fe75ff42666ceba3ac189e8aac82
Author: David Degazio <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebCore/bindings/js/JSExecState.h
M Source/WebCore/bindings/js/ScriptController.cpp
M Source/WebCore/workers/WorkerOrWorkletScriptController.cpp
Log Message:
-----------
Cherry-pick 276190@main (20cd6e8fdcc8).
https://bugs.webkit.org/show_bug.cgi?id=270934
JSExecState::loadModule can dereference null result
https://bugs.webkit.org/show_bug.cgi?id=270934
rdar://121268593
Reviewed by Yusuke Suzuki.
Fixes a bug where JSExecState::loadModule always dereferenced the
result of JSC::loadModule, even though JSC::loadModule will return
null if there is an exception. This patch changes the return type
of JSExecState::loadModule to a raw pointer, so callers of it can
detect and handle null results returned from deeper calls.
* Source/WebCore/bindings/js/JSExecState.h:
(WebCore::JSExecState::loadModule):
* Source/WebCore/bindings/js/ScriptController.cpp:
(WebCore::ScriptController::loadModuleScriptInWorld):
* Source/WebCore/workers/WorkerOrWorkletScriptController.cpp:
(WebCore::WorkerOrWorkletScriptController::loadModuleSynchronously):
(WebCore::WorkerOrWorkletScriptController::loadAndEvaluateModule):
Canonical link: https://commits.webkit.org/276190@main
Canonical link: https://commits.webkit.org/274313.380@webkitglib/2.44
Commit: c9507c5fb075619276c721e87201eff162f11779
https://github.com/WebKit/WebKit/commit/c9507c5fb075619276c721e87201eff162f11779
Author: Matt Woodrow <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A LayoutTests/fast/clip/offscreen-transparency-clip-expected.html
A LayoutTests/fast/clip/offscreen-transparency-clip.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick 276294@main (afd16103076c).
https://bugs.webkit.org/show_bug.cgi?id=270926
REGRESSION(268173@main) Safari rendered bdiusa.com as all white.
https://bugs.webkit.org/show_bug.cgi?id=270926
<rdar://123983879>
Reviewed by Simon Fraser.
We're using transparencyClipBox to determine the size of the transparency
layer to push,
and it's returning an empty rectangle.
It recurses through descendants, and finds a child layer positioned way off
to the left
of the screen (at -33553151).
Due to limits of int32, adding the bounds of that child into the original
rect
(0,0) width=1686 height=18933.45, results in (-33554430,0) width=33554432
height=18933.45
which no longer includes the visible area of the screen (except for the
very left edge).
This fix moves the intersection with the dirty rect down to happen
per-layer, so that
we clip before unioning the descendants in, and avoid this problem.
As the existing code comment mentions, it would still be preferable to take
CSS clips
into account when computing these rectangles.
* LayoutTests/fast/clip/offscreen-transparency-clip-expected.html: Added.
* LayoutTests/fast/clip/offscreen-transparency-clip.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::transparencyClipBox):
(WebCore::expandClipRectForDescendantsAndReflection):
(WebCore::RenderLayer::beginTransparencyLayers):
(WebCore::paintingExtent): Deleted.
Canonical link: https://commits.webkit.org/276294@main
Canonical link: https://commits.webkit.org/274313.381@webkitglib/2.44
Commit: 14a1972f685fe66653ab55065fb6be53ea8b2149
https://github.com/WebKit/WebKit/commit/14a1972f685fe66653ab55065fb6be53ea8b2149
Author: Aditya Keerthi <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M LayoutTests/fast/forms/ios/select-option-removed-update.html
A LayoutTests/fast/forms/ios/select-option-update-1000-expected.txt
A LayoutTests/fast/forms/ios/select-option-update-1000.html
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
Cherry-pick 276349@main (cfd86982fcdf).
https://bugs.webkit.org/show_bug.cgi?id=271138
REGRESSION (271805@main): [iOS] Updating options in a visible <select> menu
can result in hangs
https://bugs.webkit.org/show_bug.cgi?id=271138
rdar://124576235
Reviewed by Abrar Rahman Protyasha.
271805@main introduced logic that would update a visible <select> menu's
options
as they are changed. Currently, the logic sends an update every time an
option is
added or removed. This is problematic when options are added in a loop, as
(n - 1)
unnecessary IPC messages are sent, and O(n^2) menu items are constructed in
the UI
process. Additionally, there is further overhead from auto layout.
Consequently,
adding options in a loop can result in a hang when there is a visible
<select> menu.
Fix by adding a debouncing mechanism, so that changes to options can be
coalesced
into a single update.
* LayoutTests/fast/forms/ios/select-option-removed-update.html:
* LayoutTests/fast/forms/ios/select-option-update-1000-expected.txt: Added.
* LayoutTests/fast/forms/ios/select-option-update-1000.html: Added.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close):
(WebKit::WebPage::elementDidFocus):
(WebKit::WebPage::focusedSelectElementDidChangeOptions):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
Use a `DeferrableOneShotTimer` to ensure that any changes that happen
within 100ms
are coalesced into a single update.
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::updateFocusedElementInformation):
Canonical link: https://commits.webkit.org/276349@main
Canonical link: https://commits.webkit.org/274313.382@webkitglib/2.44
Commit: fb3070e3f4473e65d9533a74589a6d99d630a3b3
https://github.com/WebKit/WebKit/commit/fb3070e3f4473e65d9533a74589a6d99d630a3b3
Author: Chris Dumez <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm
M Source/WebKit/UIProcess/AuxiliaryProcessProxy.h
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.h
M Source/WebKit/UIProcess/ProcessThrottler.cpp
M Source/WebKit/UIProcess/ProcessThrottler.h
R Source/WebKit/UIProcess/ProcessThrottlerClient.h
M Source/WebKit/UIProcess/WebProcessProxy.h
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 274938@main (e64b8cfcb1ee).
https://bugs.webkit.org/show_bug.cgi?id=269605
Adopt more smart pointers in ProcessThrottler
https://bugs.webkit.org/show_bug.cgi?id=269605
Reviewed by Per Arne Vollan.
Adopt more smart pointers in ProcessThrottler. Also drop the
ProcessThrottlerClient
abstraction since ProcessThrottler already has a pointer back to the
AuxiliaryProcessProxy, which is the only ProcessThrottlerClient. This
simplifies
the code a bit and gets rid of an unnecessary data member.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewTesting.mm:
(-[WKWebView _processDidResumeForTesting]):
* Source/WebKit/UIProcess/AuxiliaryProcessProxy.h:
(WebKit::AuxiliaryProcessProxy::isRunning const):
(WebKit::AuxiliaryProcessProxy::didChangeThrottleState):
(WebKit::AuxiliaryProcessProxy::environmentIdentifier const):
(WebKit::AuxiliaryProcessProxy::prepareToDropLastAssertion):
(WebKit::AuxiliaryProcessProxy::didDropLastAssertion):
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:
* Source/WebKit/UIProcess/ProcessThrottler.cpp:
(WebKit::ProcessThrottler::ProcessThrottler):
(WebKit::ProcessThrottler::assertionName const):
(WebKit::ProcessThrottler::setThrottleState):
(WebKit::ProcessThrottler::ref):
(WebKit::ProcessThrottler::deref):
(WebKit::ProcessThrottler::updateThrottleStateIfNeeded):
(WebKit::ProcessThrottler::didConnectToProcess):
(WebKit::ProcessThrottler::didDisconnectFromProcess):
(WebKit::ProcessThrottler::sendPrepareToSuspendIPC):
(WebKit::ProcessThrottler::setShouldTakeNearSuspendedAssertion):
(WebKit::ProcessThrottler::clearAssertion):
(WebKit::ProcessThrottler::protectedProcess const):
(WebKit::ProcessThrottler::isSuspended const):
(WebKit::ProcessThrottlerActivity::invalidate):
* Source/WebKit/UIProcess/ProcessThrottler.h:
* Source/WebKit/UIProcess/ProcessThrottlerClient.h: Removed.
* Source/WebKit/UIProcess/WebProcessProxy.h:
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::sendNetworkProcessDidResume):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/274938@main
Canonical link: https://commits.webkit.org/274313.383@webkitglib/2.44
Commit: 8eb5168bcbc5e69b8638413d18d90514bf72c7f5
https://github.com/WebKit/WebKit/commit/8eb5168bcbc5e69b8638413d18d90514bf72c7f5
Author: Carlos Garcia Campos <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 275540@main (6a7b2d62c794).
https://bugs.webkit.org/show_bug.cgi?id=269699
[GTK] Crash in WebPageProxy::getLoadDecisionForIcon
https://bugs.webkit.org/show_bug.cgi?id=269699
Reviewed by Michael Catanzaro.
This probably regressed in 274563@main, that changed the way a
SharedBuffer is serialized for IPC and now segments are sent, instead of
the contiguous. So, in getLoadDecisionForIcon() we need to handle the
case of data being non contiguous, by using
SharedBufferReference::unsafeBuffer()
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::getLoadDecisionForIcon):
Canonical link: https://commits.webkit.org/275540@main
Canonical link: https://commits.webkit.org/274313.384@webkitglib/2.44
Commit: d94e4b9083bc3ba9bdafd3570fc463edb00ad36e
https://github.com/WebKit/WebKit/commit/d94e4b9083bc3ba9bdafd3570fc463edb00ad36e
Author: Erica Li <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A LayoutTests/fast/images/imageDocument-appendBytes-crash-expected.txt
A LayoutTests/fast/images/imageDocument-appendBytes-crash.html
M Source/WebCore/html/ImageDocument.cpp
Log Message:
-----------
Cherry-pick 275537@main (bac31e80659a).
https://bugs.webkit.org/show_bug.cgi?id=270283.
Null pointer dereference in WebCore::ImageDocument::createDocumentStructure.
https://bugs.webkit.org/show_bug.cgi?id=270283.
rdar://122779661.
Reviewed by Chris Dumez.
Adding null check to prevent the cases where local frame would be detached
during createDocumentStructure.
* LayoutTests/fast/images/imageDocument-appendBytes-crash-expected.txt:
Added.
* LayoutTests/fast/images/imageDocument-appendBytes-crash.html: Added.
* Source/WebCore/html/ImageDocument.cpp:
(WebCore::ImageDocument::updateDuringParsing):
(WebCore::ImageDocument::createDocumentStructure):
Canonical link: https://commits.webkit.org/275537@main
Canonical link: https://commits.webkit.org/274313.385@webkitglib/2.44
Commit: 9a8dae2cd99dc36ad27fd672cceddb003ea99dcc
https://github.com/WebKit/WebKit/commit/9a8dae2cd99dc36ad27fd672cceddb003ea99dcc
Author: Claudio Saavedra <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/wpe/WebPageProxyWPE.cpp
Log Message:
-----------
Cherry-pick 275559@main (291cc0752318).
https://bugs.webkit.org/show_bug.cgi?id=270355
[WPE] Fix build in older platforms
https://bugs.webkit.org/show_bug.cgi?id=270355
Unreviewed build fix.
The include was wrong, even if WPE_PLATFORM is not enabled,
the DMABufRendererBufferFormat definition is needed for
the empty vector.
* Source/WebKit/UIProcess/wpe/WebPageProxyWPE.cpp:
Canonical link: https://commits.webkit.org/275559@main
Canonical link: https://commits.webkit.org/274313.386@webkitglib/2.44
Commit: 30e2720e7a0a2d681e5832f503a28380da945b6b
https://github.com/WebKit/WebKit/commit/30e2720e7a0a2d681e5832f503a28380da945b6b
Author: Matthew Finkel <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp
Log Message:
-----------
Cherry-pick 275572@main (4caf2bb34aab).
https://bugs.webkit.org/show_bug.cgi?id=270208
Simplify handling addGrant result when granting storage access
https://bugs.webkit.org/show_bug.cgi?id=270208
rdar://123728856
Reviewed by Charlie Wolfe.
In 271821@main I added support for granting storage access for a group of
domains. This change simplifies part of that logic.
* Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsStore.cpp:
(WebKit::ResourceLoadStatisticsStore::grantStorageAccess):
Canonical link: https://commits.webkit.org/275572@main
Canonical link: https://commits.webkit.org/274313.387@webkitglib/2.44
Commit: d6dd2741311a857f845a9bad2a8e4a13b7df04a5
https://github.com/WebKit/WebKit/commit/d6dd2741311a857f845a9bad2a8e4a13b7df04a5
Author: Nikolaos Mouchtaris <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebCore/page/scrolling/ScrollingStateFixedNode.cpp
Log Message:
-----------
Cherry-pick 275574@main (0c592c9b1e0c).
https://bugs.webkit.org/show_bug.cgi?id=270361
Crash under ScrollingStateFixedNode::reconcileLayerPositionForViewportRect
https://bugs.webkit.org/show_bug.cgi?id=270361
rdar://105887621
Reviewed by Simon Fraser.
We need a similar fix to https://github.com/WebKit/WebKit/pull/17453 as
there is
the same crash signature under
ScrollingStateFixedNode::reconcileLayerPositionForViewportRect
this time.
* Source/WebCore/page/scrolling/ScrollingStateFixedNode.cpp:
(WebCore::ScrollingStateFixedNode::reconcileLayerPositionForViewportRect):
Canonical link: https://commits.webkit.org/275574@main
Canonical link: https://commits.webkit.org/274313.388@webkitglib/2.44
Commit: 5b2a8fea4f677d451820b296599082e41da504f1
https://github.com/WebKit/WebKit/commit/5b2a8fea4f677d451820b296599082e41da504f1
Author: Ryosuke Niwa <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A
LayoutTests/fast/images/create-image-bitmap-after-stopping-script-execution-context-expected.txt
A
LayoutTests/fast/images/create-image-bitmap-after-stopping-script-execution-context.html
M Source/WebCore/html/ImageBitmap.cpp
Log Message:
-----------
Cherry-pick 275581@main (198cfb4f193c).
https://bugs.webkit.org/show_bug.cgi?id=270379
Assertion failure in ~CompletionHandler() via
ImageBitmap::createCompletionHandler
https://bugs.webkit.org/show_bug.cgi?id=270379
Reviewed by Wenson Hsieh.
Call the completion handler when exiting early in PendingImageBitmap::fetch.
*
LayoutTests/fast/images/create-image-bitmap-after-stopping-script-execution-context-expected.txt:
Added.
*
LayoutTests/fast/images/create-image-bitmap-after-stopping-script-execution-context.html:
Added.
* Source/WebCore/html/ImageBitmap.cpp:
Canonical link: https://commits.webkit.org/275581@main
Canonical link: https://commits.webkit.org/274313.389@webkitglib/2.44
Commit: ff0a81399f1a11fc93f3f8b318b655419740fcd0
https://github.com/WebKit/WebKit/commit/ff0a81399f1a11fc93f3f8b318b655419740fcd0
Author: Ben Nham <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/WebProcess/WebProcess.cpp
M Source/WebKit/WebProcess/WebProcess.h
M Source/WebKit/WebProcess/WebProcess.messages.in
Log Message:
-----------
Cherry-pick 275588@main (199ca3488158).
https://bugs.webkit.org/show_bug.cgi?id=270236
Avoid updating hidden page timer throttling interval for suspended processes
https://bugs.webkit.org/show_bug.cgi?id=270236
rdar://problem/123773191
Reviewed by Chris Dumez.
Currently, every time a tab is created or destroyed, we update the hidden
page timer throttling
interval and broadcast the change to all processes, including suspended
processes. While this
doesn't cause a suspended process to resume, it can cause messages to build
up in IPC queues that
never get drained. This is because the receiver might be a suspended
WebContent process.
To avoid this, skip sending the timer throttling interval to suspended
processes and defer the
update until the resume IPC.
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::hiddenPageThrottlingAutoIncreaseLimit):
(WebKit::WebProcessPool::updateHiddenPageThrottlingAutoIncreaseLimit):
* Source/WebKit/UIProcess/WebProcessPool.h:
(WebKit::WebProcessPool::sendToAllProcesses):
(WebKit::WebProcessPool::sendToAllProcessesForSession):
(WebKit::WebProcessPool::sendToAllRemoteWorkerProcesses):
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::sendProcessDidResume):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::setHiddenPageDOMTimerThrottlingIncreaseLimit):
(WebKit::WebProcess::processDidResume):
* Source/WebKit/WebProcess/WebProcess.h:
* Source/WebKit/WebProcess/WebProcess.messages.in:
Canonical link: https://commits.webkit.org/275588@main
Canonical link: https://commits.webkit.org/274313.390@webkitglib/2.44
Commit: 24e2a5805647d851d055bd0137625893df0ac176
https://github.com/WebKit/WebKit/commit/24e2a5805647d851d055bd0137625893df0ac176
Author: Dennis Camera <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/JavaScriptCore/disassembler/ARM64/A64DOpcode.h
Log Message:
-----------
Cherry-pick 275630@main (56001e951362).
https://bugs.webkit.org/show_bug.cgi?id=270394
[JSC] A64DOpcode include <mutex>
https://bugs.webkit.org/show_bug.cgi?id=270394
Reviewed by Michael Catanzaro.
When UNIFIED_BUILDS are disabled, the build fails due to missing
std::call_once.
* Source/JavaScriptCore/disassembler/ARM64/A64DOpcode.h: include <mutex>.
Canonical link: https://commits.webkit.org/275630@main
Canonical link: https://commits.webkit.org/274313.391@webkitglib/2.44
Commit: 62cae94447836247cc409487afaa0b92a523b101
https://github.com/WebKit/WebKit/commit/62cae94447836247cc409487afaa0b92a523b101
Author: Megan Gardner <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/scroll-to-text-fragment/scroll-to-text-fragment-target.html
M
LayoutTests/imported/w3c/web-platform-tests/scroll-to-text-fragment/scroll-to-text-fragment.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
Log Message:
-----------
Cherry-pick 281273@main (1d776f617268).
https://bugs.webkit.org/show_bug.cgi?id=276925
Scroll-to-text-fragment is leaked to the loaded page through Navigation
Timing.
https://bugs.webkit.org/show_bug.cgi?id=276925
rdar://124717009
Reviewed by Ryosuke Niwa.
We need to strip the fragment from the URL earlier so that the full URL
does not end up
in the performance metrics, leaking the fragment that should be invisible
to the page.
WPT test will need to be upstreamed after this patch lands.
*
LayoutTests/imported/w3c/web-platform-tests/scroll-to-text-fragment/scroll-to-text-fragment-target.html:
*
LayoutTests/imported/w3c/web-platform-tests/scroll-to-text-fragment/scroll-to-text-fragment.html:
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setURL):
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::startLoadingMainResource):
* Source/WebCore/page/Page.cpp:
(WebCore::Page::setMainFrameURLFragment):
* Source/WebCore/page/Page.h:
(WebCore::Page::mainFrameURLFragment const):
Canonical link: https://commits.webkit.org/281273@main
Canonical link: https://commits.webkit.org/274313.392@webkitglib/2.44
Commit: e4980fa56ea37c1ce33f3141fbdd7164f6e050f5
https://github.com/WebKit/WebKit/commit/e4980fa56ea37c1ce33f3141fbdd7164f6e050f5
Author: Jonathan Bedard <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py
Log Message:
-----------
Cherry-pick 279706@main (5ab9e6cd5bad).
https://bugs.webkit.org/show_bug.cgi?id=263825
[webkitcorepy] Failed to install setuptools
https://bugs.webkit.org/show_bug.cgi?id=263825
rdar://117940593
Reviewed by Dewei Zhu and Oriol Brufau.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py:
(Package.install): Differentiate between files and folders when removing
existing autoinstalled content.
Canonical link: https://commits.webkit.org/279706@main
Canonical link: https://commits.webkit.org/274313.393@webkitglib/2.44
Commit: 72b8bce49442b2e24db984d82dba4fb583ff480b
https://github.com/WebKit/WebKit/commit/72b8bce49442b2e24db984d82dba4fb583ff480b
Author: Devin Rousso <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebInspectorUI/UserInterface/Models/Recording.js
M Source/WebInspectorUI/UserInterface/Models/RecordingAction.js
Log Message:
-----------
Cherry-pick 280147@main (cba08d5a8e69).
https://bugs.webkit.org/show_bug.cgi?id=275539
Web Inspector: REGRESSION(252630@main): Canvas: clicking on trace call
frame doesn't jump to source
https://bugs.webkit.org/show_bug.cgi?id=275539
Reviewed by Timothy Hatcher.
`WI.StackTrace.fromPayload` expects that the `callFrames` property in the
`payload` parameter are protocol payloads, not actual `WI.CallFrame` objects.
* Source/WebInspectorUI/UserInterface/Models/Recording.js:
(WI.Recording.prototype.async swizzle):
* Source/WebInspectorUI/UserInterface/Models/RecordingAction.js:
(WI.RecordingAction.prototype.async swizzle):
Canonical link: https://commits.webkit.org/280147@main
Canonical link: https://commits.webkit.org/274313.394@webkitglib/2.44
Commit: 8bbc43b4355ce7782564810d3e55487ba6b28e90
https://github.com/WebKit/WebKit/commit/8bbc43b4355ce7782564810d3e55487ba6b28e90
Author: Devin Rousso <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/CanvasSidebarPanel.css
Log Message:
-----------
Cherry-pick 280145@main (7336e06e94b0).
https://bugs.webkit.org/show_bug.cgi?id=275540
Web Inspector: REGRESSION(?): Canvas: cannot scroll list of WebGL shader
programs
https://bugs.webkit.org/show_bug.cgi?id=275540
Reviewed by Timothy Hatcher.
* Source/WebInspectorUI/UserInterface/Views/CanvasSidebarPanel.css:
(.sidebar > .panel.navigation.canvas:not(.showing-recording) > .content):
Added.
(.sidebar > .panel.navigation.canvas > .content > .tree-outline.canvas):
Added.
(.sidebar > .panel.navigation.canvas:not(.showing-recording) > .content >
.navigation-bar): Added.
(.sidebar > .panel.navigation.canvas.showing-recording > .content >
.tree-outline.canvas):
(.sidebar > .panel.navigation.canvas:not(.showing-recording) >
:is(.filter-bar, .overflow-shadow), .sidebar >
.panel.navigation.canvas:not(.has-recordings) > .content > :is(.navigation-bar,
.recording-content)): Added.
(.sidebar > .panel.navigation.canvas:not(.has-recordings) > .filter-bar,
.sidebar > .panel.navigation.canvas:not(.has-recordings) > .content >
:is(.navigation-bar, .recording-content)): Deleted.
Move the `overflow-y: auto;` to always apply instead of only when a
recording is selected.
Also ensure that the recording scope bar is always visible if there are
recordings.
Drive-by: prevent the overflow shadow and filter bar from being shown when
a recording is not selected.
Canonical link: https://commits.webkit.org/280145@main
Canonical link: https://commits.webkit.org/274313.395@webkitglib/2.44
Commit: d0604cff548ea5f7ad5340a40f4695a8fa11e46f
https://github.com/WebKit/WebKit/commit/d0604cff548ea5f7ad5340a40f4695a8fa11e46f
Author: Simon Fraser <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M LayoutTests/fast/box-shadow/negative-shadow-box-expand-expected.txt
M LayoutTests/fast/box-shadow/negative-shadow-box-shrink-expected.txt
A LayoutTests/fast/repaint/4776765-expected.txt
A LayoutTests/fast/repaint/outline-bounds-repaint-expected.txt
A LayoutTests/fast/repaint/outline-bounds-repaint.html
M LayoutTests/platform/gtk/fast/repaint/4776765-expected.txt
M LayoutTests/platform/mac-ventura-wk2/fast/repaint/4776765-expected.txt
M LayoutTests/platform/mac-wk1/fast/repaint/4776765-expected.txt
R LayoutTests/platform/mac/fast/repaint/4776765-expected.txt
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
Cherry-pick 279717@main (939b1069b0b6).
https://bugs.webkit.org/show_bug.cgi?id=275090
REGRESSION (271254@main): Partial box-shadow left behind when resizing
elements
https://bugs.webkit.org/show_bug.cgi?id=275090
rdar://121966069
Reviewed by Alan Baradlay.
In 271254@main, RenderBox::localOutlineBoundsRepaintRect() failed to
actually return the
modified rect, resulting in under-repainting when an element with
box-shadow or outlines
changed size.
* LayoutTests/fast/box-shadow/negative-shadow-box-expand-expected.txt:
* LayoutTests/fast/box-shadow/negative-shadow-box-shrink-expected.txt:
* LayoutTests/fast/repaint/4776765-expected.txt: Renamed from
LayoutTests/platform/mac/fast/repaint/4776765-expected.txt.
* LayoutTests/fast/repaint/outline-bounds-repaint-expected.txt: Added.
* LayoutTests/fast/repaint/outline-bounds-repaint.html: Added.
* LayoutTests/platform/gtk/fast/repaint/4776765-expected.txt:
* LayoutTests/platform/mac-ventura-wk2/fast/repaint/4776765-expected.txt:
* LayoutTests/platform/mac-wk1/fast/repaint/4776765-expected.txt:
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::localOutlineBoundsRepaintRect const):
Canonical link: https://commits.webkit.org/279717@main
Canonical link: https://commits.webkit.org/274313.396@webkitglib/2.44
Commit: adb80b92153e32c45fdd00daa3eeef9e66d60abe
https://github.com/WebKit/WebKit/commit/adb80b92153e32c45fdd00daa3eeef9e66d60abe
Author: Patrick Griffis <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/wpe/AcceleratedBackingStoreDMABuf.cpp
Log Message:
-----------
Cherry-pick 276937@main (10960413a084).
https://bugs.webkit.org/show_bug.cgi?id=272030
[WPE] Fix build failure after 273995@main
https://bugs.webkit.org/show_bug.cgi?id=272030
Reviewed by Adrian Perez de Castro.
This moved some classes from the WebKit to WebCore namespace.
* Source/WebKit/UIProcess/wpe/AcceleratedBackingStoreDMABuf.cpp:
(WebKit::AcceleratedBackingStoreDMABuf::didCreateBufferSHM):
Canonical link: https://commits.webkit.org/276937@main
Canonical link: https://commits.webkit.org/274313.397@webkitglib/2.44
Commit: f4afc09e58f6919c7211bbb81356f82b52b7b174
https://github.com/WebKit/WebKit/commit/f4afc09e58f6919c7211bbb81356f82b52b7b174
Author: Simon Fraser <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing-expected.html
A
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing.html
M
LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/absolute-in-nested-overflow-scroll-expected.txt
M
LayoutTests/scrollingcoordinator/scrolling-tree/absolute-in-nested-overflow-scroll-expected.txt
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 276720@main (6fa1d3b94cd7).
https://bugs.webkit.org/show_bug.cgi?id=271710
REGRESSION (273999@main): Elements fail to render in Spinnaker
https://bugs.webkit.org/show_bug.cgi?id=271710
rdar://124483601
Reviewed by Alan Baradlay.
273999@main reverted some backing sharing behavior to an older
configuration, but this brought back
a bug which affects Spinnaker dashboards. The test reduction has a series
of overflow scrollers, both
siblings and nested, and an element later in the tree that ends up obscured
when the bug occurs.
A simplified paint-order tree dump (via the Compositing log channel) looks
like this:
-S---------C-c-- 0x118000810 RenderView 0x1180002c0
-S-----------c-- + 0x118001850 RenderBlock 0x118001700 HTML 0x118001050
-S---------C-c-- + 0x1180044a0 RenderBlock (relative positioned)
0x118004350 DIV 0x118003350 class='container'
-S-O-----XxC---- - 0x118004740 RenderTextControl 0x118005460 TEXTAREA
0x118003c20 class='fixed'
---O-------CPc-- + 0x1180049e0 RenderBlock (relative positioned)
0x1180045f0 DIV 0x1180033d0 id='main'
--NO-------C-c-- n 0x118004dd0 RenderBlock 0x118004890 DIV
0x118003530 class='outer-scroller'
--NO-------C--s- n 0x118005070 RenderBlock 0x118004c80 DIV
0x1180035b0 class='scroller'
------------p-s- + 0x1180055b0 RenderBlock (relative positioned)
0x1180051c0 DIV 0x118003790 class='indicator'
Note the P on '0x1180049e0' indicating that it's a shared backing provider,
and the p on '0x1180055b0' showing that
it paints into that shared backing. However, the normal flow descendant
layers of 0x1180049e0 (0x118004dd0 and 0x118005070)
are both [C]composited, so they appear on top of 0x1180055b0, which is the
bug.
A composited layer normally interrupts a backing sharing sequence. However,
we only determined that 0x1180049e0 could
be a backing provider after traversing its descendant layers in
`updateBackingSharingAfterDescendantTraversal()`,
and made it one despite it having composited descendants. So fix
`updateBackingSharingAfterDescendantTraversal()`
to check that.
This undoes the backing sharing that happened in
`scrollingcoordinator/scrolling-tree/absolute-in-nested-overflow-scroll`,
but that sharing was undone on scrolling anyway.
*
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing-expected.html:
Added.
*
LayoutTests/compositing/shared-backing/composited-descendants-should-prevent-sharing.html:
Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateBackingSharingAfterDescendantTraversal):
Canonical link: https://commits.webkit.org/276720@main
Canonical link: https://commits.webkit.org/274313.398@webkitglib/2.44
Commit: 11b35bc8d2a50d67e20a7b1ec0c24a9485a16066
https://github.com/WebKit/WebKit/commit/11b35bc8d2a50d67e20a7b1ec0c24a9485a16066
Author: Adrian Perez de Castro <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/JavaScriptCore/llint/LLIntOpcode.h
M Source/JavaScriptCore/llint/LowLevelInterpreter.cpp
Log Message:
-----------
Revert "BYTECODE_HELPER_ID LLint opcodes need look up for wide versions."
This reverts commit aa62ce7b905994f278e4661ae4c7425ce400be01.
Canonical link: https://commits.webkit.org/274313.399@webkitglib/2.44
Commit: 2fd522326fdd6ff705560fa437a8bc09e56b284e
https://github.com/WebKit/WebKit/commit/2fd522326fdd6ff705560fa437a8bc09e56b284e
Author: Sammy Gill <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A PerformanceTests/Layout/nested-grid-subgrid-free-space-columns.html
M Source/WebCore/Headers.cmake
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/rendering/style/RenderStyleInlines.h
Log Message:
-----------
Cherry-pick 276633@main (ba849a630cec).
https://bugs.webkit.org/show_bug.cgi?id=271083
[css-grid] Grid track sizing algorithm logical height computation
unnecessarily dirties grid items.
https://bugs.webkit.org/show_bug.cgi?id=271083
rdar://124713418
Reviewed by Matt Woodrow.
In certain situations when trying to compute the logical height for a
grid item, the grid track sizing algorithm will update the grid item's
overriding containing block size and mark it dirty for layout. This
dirtying would occur even it we end up setting the override size to the
same value and could result in bad performance with particular types
of content. For example, nested grid content would run grid layout
multiple times which is currently expensive.
In this patch we avoid this extra call to layout by checking to see if
the override size is already set to the value we are attempting to set
it to. If it is then we will avoid dirtying the renderer.
This also ended up exposing an invalidation bug in which we were not
properly invalidating the grid items when there was a style change on
the grid related to its column or row sizes. This was demonstrated with
new failures in
css-grid/layout-algorithm/grid-intrinsic-track-sizes-001.html
which was performing this behavior. Now when the grid style changes we
will check to see if any of the sizes for the columns or the rows are
different. If this occurs we should mark the grid items as dirty. This
is likely to be more than necessary since we could probably try to
identify the exact set of grid items that need to be invalidated, but
this approach is the least risky for now. Future patches should attempt
to reign this invalidation in a bit more.
Without this patch I was getting about 2 runs/s and afterwards I was
able to get about ~690 runs/s.
* PerformanceTests/Layout/nested-grid-subgrid-free-space-columns.html:
Added.
* Source/WebCore/Headers.cmake:
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithmStrategy::logicalHeightForChild const):
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::styleDidChange):
* Source/WebCore/rendering/style/RenderStyle.h:
* Source/WebCore/rendering/style/RenderStyleInlines.h:
(WebCore::RenderStyle::gridTrackSizes const):
Canonical link: https://commits.webkit.org/276633@main
Canonical link: https://commits.webkit.org/274313.400@webkitglib/2.44
Commit: 0b7bd0777686696923126fb5006a35aefd0ea89f
https://github.com/WebKit/WebKit/commit/0b7bd0777686696923126fb5006a35aefd0ea89f
Author: Justin Michaud <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A JSTests/wasm/stress/omg-stack-overflow.js
A JSTests/wasm/stress/omg-stack-overflow.wasm
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
Cherry-pick 276645@main (3a0671fdf831).
https://bugs.webkit.org/show_bug.cgi?id=270605
Add missing stack check to bbq->omg OSR
https://bugs.webkit.org/show_bug.cgi?id=270605
rdar://124060272
Reviewed by Keith Miller.
In https://commits.webkit.org/272448.466@safari-7618-branch, we turned
a stack overflow during OSR entry into a crash, preventing a security
issue. While the crash prevents memory corruption, it should never
happen. This patch fixes a case that was missed in the first patch.
Note: the test case currently runs forever, so it is skipped until
we fix the watchdog in wasm.
* JSTests/wasm/stress/omg-stack-overflow.js: Added.
(globalThis.callerIsBBQOrOMGCompiled.instantiateJsc):
(else.instantiateBrowser):
(async let):
* JSTests/wasm/stress/omg-stack-overflow.wasm: Added.
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
Originally-landed-as: 272448.704@safari-7618-branch (36930ea8be72).
rdar://125261536
Canonical link: https://commits.webkit.org/276645@main
Canonical link: https://commits.webkit.org/274313.401@webkitglib/2.44
Commit: 9dfda8a33ac583e608e236e47b3987b52e2e7cd4
https://github.com/WebKit/WebKit/commit/9dfda8a33ac583e608e236e47b3987b52e2e7cd4
Author: Justin Michaud <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
A JSTests/wasm/stress/omg-osr-stack-check-2.js
A JSTests/wasm/stress/omg-osr-stack-check-2.wasm
M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmCallee.h
M Source/JavaScriptCore/wasm/WasmOperations.cpp
M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp
Log Message:
-----------
Cherry-pick 276682@main (4322c3bd5293).
https://bugs.webkit.org/show_bug.cgi?id=271011
Stack check size can be zero if omg skips stack checks.
https://bugs.webkit.org/show_bug.cgi?id=271011
rdar://124390384
Reviewed by Yusuke Suzuki.
For leaf functions that have really small stacks, this stack check can
be skipped and the ASSERT(stackCheckSize()) is wrong.
We change the assert to ensure that the stack check size is set, but
if it is not needed, we can skip the stack check.
* Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompileB3):
* Source/JavaScriptCore/wasm/WasmCallee.h:
Originally-landed-as: 272448.753@safari-7618-branch (aef93328873d).
rdar://124390384
Canonical link: https://commits.webkit.org/276682@main
Canonical link: https://commits.webkit.org/274313.402@webkitglib/2.44
Commit: d5151e75c73766fc321989e24fb138040aa9112a
https://github.com/WebKit/WebKit/commit/d5151e75c73766fc321989e24fb138040aa9112a
Author: Richard Robinson <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebKit/UIProcess/UserContent/WebUserContentControllerProxy.cpp
Log Message:
-----------
Cherry-pick 282880@main (d1ee6bc865cb).
https://bugs.webkit.org/show_bug.cgi?id=278809
Debug assertion occasionally triggered in Mail via
`WebUserContentControllerProxy::didPostMessage`
https://bugs.webkit.org/show_bug.cgi?id=278809
rdar://134879673
Reviewed by Abrar Rahman Protyasha.
Ensure the completion handler is always called in this method.
* Source/WebKit/UIProcess/UserContent/WebUserContentControllerProxy.cpp:
(WebKit::WebUserContentControllerProxy::didPostMessage):
Canonical link: https://commits.webkit.org/282880@main
Canonical link: https://commits.webkit.org/274313.403@webkitglib/2.44
Commit: 70a60da0ef74d9d67ce6828d4b27f10a292c6931
https://github.com/WebKit/WebKit/commit/70a60da0ef74d9d67ce6828d4b27f10a292c6931
Author: Vitaly Dyachkov <[email protected]>
Date: 2024-08-30 (Fri, 30 Aug 2024)
Changed paths:
M Source/WebCore/xml/XPathNodeSet.cpp
Log Message:
-----------
Cherry-pick 282842@main (54db0db4919d).
https://bugs.webkit.org/show_bug.cgi?id=278781
Some `fast/xpath` tests hit an assertion in release with `ENABLE_ASSERTS=1`
https://bugs.webkit.org/show_bug.cgi?id=278781
Reviewed by Anne van Kesteren.
The code assumes that `ASSERT()` macro is only enabled in debug builds,
but it can be enabled in release builds too using `ENABLE_ASSERTS=1`.
* Source/WebCore/xml/XPathNodeSet.cpp:
(WebCore::XPath::sortBlock):
Canonical link: https://commits.webkit.org/282842@main
Canonical link: https://commits.webkit.org/274313.404@webkitglib/2.44
Commit: fd92484c3922ecf096d8381f49e7a70158ae74b6
https://github.com/WebKit/WebKit/commit/fd92484c3922ecf096d8381f49e7a70158ae74b6
Author: Philippe Normand <[email protected]>
Date: 2024-09-03 (Tue, 03 Sep 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerSinksWorkarounds.cpp
Log Message:
-----------
Cherry-pick 283051@main (03e1d775d51d).
https://bugs.webkit.org/show_bug.cgi?id=278989
[GStreamer] Memory leak in GStreamerSinksWorkarounds
https://bugs.webkit.org/show_bug.cgi?id=278989
Reviewed by Alicia Boya Garcia.
* Source/WebCore/platform/graphics/gstreamer/GStreamerSinksWorkarounds.cpp:
(WebCore::AppSinkFlushCapsWorkaroundProbe::checkIsNeeded): Make sure the
string allocated in
gst_plugins_base_version_string() is de-allocated afterwards.
Canonical link: https://commits.webkit.org/283051@main
Canonical link: https://commits.webkit.org/274313.405@webkitglib/2.44
Commit: 3637305650ee77c7163f09bb6a0a3d387a4e6a2d
https://github.com/WebKit/WebKit/commit/3637305650ee77c7163f09bb6a0a3d387a4e6a2d
Author: Vitaly Dyachkov <[email protected]>
Date: 2024-09-03 (Tue, 03 Sep 2024)
Changed paths:
M Source/WebCore/xml/XPathNodeSet.cpp
Log Message:
-----------
Cherry-pick 282992@main (7ce6a1c447e1).
https://bugs.webkit.org/show_bug.cgi?id=278781
Some `fast/xpath` tests hit an assertion in release with `ENABLE_ASSERTS=1`
https://bugs.webkit.org/show_bug.cgi?id=278781
Reviewed by Alexey Proskuryakov.
In https://github.com/WebKit/WebKit/pull/32818 @aproskuryakov rightly
noted that "when someone builds with ENABLE_ASSERTS=1, they presumably
want the asserts to work, not to be ifdefed out".
* Source/WebCore/xml/XPathNodeSet.cpp:
(WebCore::XPath::sortBlock):
Canonical link: https://commits.webkit.org/282992@main
Canonical link: https://commits.webkit.org/274313.406@webkitglib/2.44
Compare: https://github.com/WebKit/WebKit/compare/83e0705053cc...3637305650ee
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
