Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 6bf4455a710ba548a80d0d652d9c3c2be2bad5b5
https://github.com/WebKit/WebKit/commit/6bf4455a710ba548a80d0d652d9c3c2be2bad5b5
Author: Franco Vieira de Souza <[email protected]>
Date: 2026-02-20 (Fri, 20 Feb 2026)
Changed paths:
A
LayoutTests/performance-api/event-timing-entry-schedules-update-rendering-expected.txt
A
LayoutTests/performance-api/event-timing-entry-schedules-update-rendering.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/page/LocalDOMWindow.cpp
M Source/WebCore/page/LocalDOMWindow.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
Log Message:
-----------
Cherry-pick 306142@main (8af8a7cdd78d).
https://bugs.webkit.org/show_bug.cgi?id=305251
High INP (Interaction to Next Paint) for interactions with no immediate
screen updates
https://bugs.webkit.org/show_bug.cgi?id=305251
rdar://168016487
Reviewed by Ryan Reno
We now ensure "update the rendering" (Page::updateRendering()) is
scheduled to run whenever an event timing entry is queued to be
dispatched. This ensures the dispatch will happen in a timely manner.
Previously, static pages in which nothing forces an update to
rendering could take too long to dispatch the entries, producing
entries with unreasonably large durations. That could be interpreted
as the page being unresponsive in metrics such as INP.
In order to test this, we need to probe the scheduling state, so a new
testing API was added: window.internals.timeToNextRenderingUpdate().
Test added:
*
LayoutTests/performance-api/event-timing-entry-schedules-update-rendering.html
Canonical link: https://commits.webkit.org/306142@main
Canonical link: https://commits.webkit.org/305877.89@webkitglib/2.52
Commit: 93e7030777124ba82abf69f6db57abe2709251a4
https://github.com/WebKit/WebKit/commit/93e7030777124ba82abf69f6db57abe2709251a4
Author: Fujii Hironori <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
A LayoutTests/http/tests/cookies/set-http-only-cookie-expected.txt
A LayoutTests/http/tests/cookies/set-http-only-cookie.html
A
LayoutTests/platform/glib/http/tests/cookies/js-get-and-set-http-only-cookie-expected.txt
M Source/WebCore/platform/network/soup/NetworkStorageSessionSoup.cpp
Log Message:
-----------
Cherry-pick 307889@main (8cb5592cf41f).
https://bugs.webkit.org/show_bug.cgi?id=308204
[Soup] NetworkStorageSession::domCookiesForHost shoudn't return httpOnly
cookies
https://bugs.webkit.org/show_bug.cgi?id=308204
Reviewed by Carlos Garcia Campos.
GTK and WPE ports were observing an assertion failure in WebCookieCache.cpp
while browsing some web sites.
> ASSERTION FAILED: !cookie.httpOnly
> ../../../Source/WebKit/WebProcess/WebPage/WebCookieCache.cpp(57) : String
WebKit::cookiesToString(const Vector<WebCore::Cookie> &)
httpOnly cookies shouldn't be included in DOM cookies. Changed
NetworkStorageSession::domCookiesForHost not to include httpOnly cookies.
After this change, http/tests/cookies/js-get-and-set-http-only-cookie.html
started to fail. However, it's the same result as Mac port. Copied
platform/mac/http/tests/cookies/js-get-and-set-http-only-cookie-expected.txt to
glib.
Test: http/tests/cookies/set-http-only-cookie.html
* LayoutTests/http/tests/cookies/set-http-only-cookie-expected.txt: Added.
* LayoutTests/http/tests/cookies/set-http-only-cookie.html: Added.
*
LayoutTests/platform/glib/http/tests/cookies/js-get-and-set-http-only-cookie-expected.txt:
Added.
* Source/WebCore/platform/network/soup/NetworkStorageSessionSoup.cpp:
(WebCore::NetworkStorageSession::domCookiesForHost):
Canonical link: https://commits.webkit.org/307889@main
Canonical link: https://commits.webkit.org/305877.90@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/99967de2ee4e...93e703077712
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
