Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 49e242a2ca89d9e4cc30379c6261a0c029e2878b
https://github.com/WebKit/WebKit/commit/49e242a2ca89d9e4cc30379c6261a0c029e2878b
Author: Razvan Caliman <[email protected]>
Date: 2026-03-30 (Mon, 30 Mar 2026)
Changed paths:
A LayoutTests/inspector/timeline/timeline-recording-autocapture-expected.txt
A LayoutTests/inspector/timeline/timeline-recording-autocapture.html
M Source/WebCore/inspector/agents/page/PageTimelineAgent.cpp
Log Message:
-----------
Cherry-pick 309566@main (cd3ed2f6e666).
https://bugs.webkit.org/show_bug.cgi?id=310137
REGRESSION(290430@main): Timelines recording stops on page reload even when
auto-stop is disabled
https://bugs.webkit.org/show_bug.cgi?id=310137
rdar://169732727
Reviewed by BJ Burg and Devin Rousso.
290430@main split `InspectorTimelineAgent` into `PageTimelineAgent` and
`WorkerTimelineAgent`. When `mainFrameStartedLoading()` was moved to
`PageTimelineAgent`, the `if (m_tracking) return;` guard was dropped.
This guard prevents the backend from dispatching
`Timeline.autoCaptureStarted`
to the frontend when a recording is already active. Without it, every page
reload
or navigation during an active recording causes
`WI.TimelineManager.prototype.autoCaptureStarted()`
on the frontend to unconditionally stop the current recording and start a
new one,
regardless of the "Stop recording once page loads" setting.
This patch restores the guard so that
`PageTimelineAgent::mainFrameStartedLoading()`
is a no-op when instruments are already recording.
Added a test for auto-capture behavior.
*
LayoutTests/inspector/timeline/timeline-recording-autocapture-expected.txt:
Added.
* LayoutTests/inspector/timeline/timeline-recording-autocapture.html: Added.
* Source/WebCore/inspector/agents/page/PageTimelineAgent.cpp:
(WebCore::PageTimelineAgent::mainFrameStartedLoading):
Canonical link: https://commits.webkit.org/309566@main
Canonical link: https://commits.webkit.org/305877.331@webkitglib/2.52
Commit: bb5705f0e1cc87f64bbaeb4ef1dc7abbf51270fd
https://github.com/WebKit/WebKit/commit/bb5705f0e1cc87f64bbaeb4ef1dc7abbf51270fd
Author: Adrian Perez de Castro <[email protected]>
Date: 2026-03-30 (Mon, 30 Mar 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp
Log Message:
-----------
Cherry-pick 310202@main (1729470dcaa6).
https://bugs.webkit.org/show_bug.cgi?id=311037
[GTK] SkImage leaked in webkit_favicon_database_get_favicon_finish()
https://bugs.webkit.org/show_bug.cgi?id=311037
Reviewed by Fujii Hironori.
The call to the g_task_propagate_pointer() function used to obtain the
SkImage for a favicon moves the ownership to the caller; but the
reference was not being accounted for. Adopt the reference into a sk_sp
to ensure that it gets dropped at the end of the scope, this avoiding
the leak of the SkImage.
* Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp:
(webkit_favicon_database_get_favicon_finish):
Canonical link: https://commits.webkit.org/310202@main
Canonical link: https://commits.webkit.org/305877.332@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/a8273f12f0c5...bb5705f0e1cc
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
