Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: d7ea5ce0b4875fd179ec6656a03e1443215f145a
https://github.com/WebKit/WebKit/commit/d7ea5ce0b4875fd179ec6656a03e1443215f145a
Author: Chris Dumez <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
M Source/WTF/wtf/Deque.h
Log Message:
-----------
Cherry-pick 310082@main (7e3461d08115).
https://bugs.webkit.org/show_bug.cgi?id=310873
Deque's implementation truncates `size_t` to `unsigned` in a few places
https://bugs.webkit.org/show_bug.cgi?id=310873
Reviewed by Darin Adler.
* Source/WTF/wtf/Deque.h:
Canonical link: https://commits.webkit.org/310082@main
Canonical link: https://commits.webkit.org/305877.387@webkitglib/2.52
Commit: bb7b68b3067e2899ec61fd109dde900821c238e6
https://github.com/WebKit/WebKit/commit/bb7b68b3067e2899ec61fd109dde900821c238e6
Author: Chris Dumez <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
M Source/WTF/wtf/Deque.h
Log Message:
-----------
Cherry-pick 310084@main (5f5525e0e2ec).
https://bugs.webkit.org/show_bug.cgi?id=310872
Deque::swap() fails to invalidate `other`'s iterators
https://bugs.webkit.org/show_bug.cgi?id=310872
Reviewed by Darin Adler.
After the swap, `other`'s existing iterators still have stale `m_index`
values that corresponded to `other`'s old data layout, but other now holds
`this`'s old data.
* Source/WTF/wtf/Deque.h:
(WTF::inlineCapacity>::swap):
Canonical link: https://commits.webkit.org/310084@main
Canonical link: https://commits.webkit.org/305877.388@webkitglib/2.52
Commit: afac7fcaf2a6f4bdc52b33dbbd607278035e792c
https://github.com/WebKit/WebKit/commit/afac7fcaf2a6f4bdc52b33dbbd607278035e792c
Author: Basuke Suzuki <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/scroll-to-text-fragment/scroll-to-text-fragment-security.sub-expected.txt
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac/TestExpectations
M Source/WebCore/page/LocalFrameView.cpp
Log Message:
-----------
Cherry-pick 301765.417@safari-7623-branch (75bcb9f43cbe).
https://bugs.webkit.org/show_bug.cgi?id=310872
Block text fragments in cross-origin window.open() popups.
rdar://163804356
Reviewed by Chris Dumez.
This implements a security defense against timing side-channel attacks
using Text Fragments in cross-origin popups.
The exploit pattern:
w = window.open("attacker.com");
w.location = "victim.com";
w.location = "victim.com#:~:text=secret";
w.location = "about:blank";
// Measure timing to detect if text was found
Defense mechanism:
- Add checkTextFragmentSecurity() in LocalFrameView.cpp
- Block text fragments when opener origin ≠ current document origin
- Allow text fragments in same-origin popups (legitimate use)
- Allow text fragments in top-level navigation (no opener)
This aligns with Chrome's 2019 defense (commit c0d3c4cca8b16),
which uses RelatedPages().size() check. WebKit uses a simpler
cross-origin check that achieves the same security goal.
The fix does not affect about:blank origin inheritance or WPT tests,
as those don't use text fragments.
Tests: http/tests/security/text-fragment/popup-cross-origin-blocked.html
http/tests/security/text-fragment/popup-same-origin-allowed.html
* LayoutTests/http/tests/security/resources/page-with-text.html: Added.
*
LayoutTests/http/tests/security/text-fragment/popup-cross-origin-blocked-expected.txt:
Added.
*
LayoutTests/http/tests/security/text-fragment/popup-cross-origin-blocked.html:
Added.
*
LayoutTests/http/tests/security/text-fragment/popup-same-origin-allowed-expected.txt:
Added.
*
LayoutTests/http/tests/security/text-fragment/popup-same-origin-allowed.html:
Added.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::checkTextFragmentSecurity):
(WebCore::LocalFrameView::scrollToTextFragment):
Identifier: 301765.417@safari-7623-branch
Identifier: 305413.221@safari-7624-branch
Canonical link: https://commits.webkit.org/310046@main
Canonical link: https://commits.webkit.org/305877.389@webkitglib/2.52
Commit: a54a87820272a68ef2eec7604353d164e2c4048d
https://github.com/WebKit/WebKit/commit/a54a87820272a68ef2eec7604353d164e2c4048d
Author: Karl Dubost <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/QuirksData.h
Log Message:
-----------
Cherry-pick 310809@main (81b942bfeab5).
https://bugs.webkit.org/show_bug.cgi?id=311602
[Quirk] invideo.io: add a window.chrome object to bypass the code sniffing.
https://bugs.webkit.org/show_bug.cgi?id=311602
rdar://171741842
Reviewed by Brent Fulgham.
There is a double block on Safari:
1. !!window.chrome (line 1798) — a property-based sniff that excludes
all non-Chromium browsers
2. ["safari"].includes(browserName) (line 1921) — an explicit UA-based
Safari exclusion via dhe(), used to prevent Safari from passing even
if it supports the required Web APIs
Safari actually supports both WebGL2 and SharedArrayBuffer (with proper
COOP/COEP headers). The site's playback engine likely depends on
Chromium-specific behavior or simply never tested on Safari/WebKit. The block
is browser-sniffing, not feature-detection — Safari is excluded by name and by
the absence of window.chrome, not because it lacks the required capabilities.
There is an outreach radar too. rdar://172352516
If you are working for invideo.io, please contact us.
The User-Agent override has been done on the side of the Safari code.
This part is adding the window.chrome object faking.
* Source/WebCore/page/Quirks.cpp:
* Source/WebCore/page/QuirksData.h:
Canonical link: https://commits.webkit.org/310809@main
Canonical link: https://commits.webkit.org/305877.390@webkitglib/2.52
Commit: 9cd35f1a45e094f0e2121e95432074be7677447c
https://github.com/WebKit/WebKit/commit/9cd35f1a45e094f0e2121e95432074be7677447c
Author: Fujii Hironori <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
M Source/WebCore/page/scrolling/coordinated/ScrollerCoordinated.cpp
Log Message:
-----------
Cherry-pick 310829@main (a8b923f87381).
https://bugs.webkit.org/show_bug.cgi?id=311789
[GTK][WPE] ASSERTION FAILED: GLContextWrapper::currentContext() in
WebCore::BitmapTexturePool::acquireTexture()
https://bugs.webkit.org/show_bug.cgi?id=311789
Reviewed by Carlos Garcia Campos.
An assertion failed in WebCore::BitmapTexturePool::acquireTexture() since
there
was no current GL context in the scrolling thread.
Make the GL context current before calling
BitmapTexturePool::acquireTexture().
* Source/WebCore/page/scrolling/coordinated/ScrollerCoordinated.cpp:
(WebCore::ScrollerCoordinated::updateValues):
Canonical link: https://commits.webkit.org/310829@main
Canonical link: https://commits.webkit.org/305877.391@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/db006c1bed60...9cd35f1a45e0
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
