Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: b2efd5099a8798816f425bd401efda65d966efa2
https://github.com/WebKit/WebKit/commit/b2efd5099a8798816f425bd401efda65d966efa2
Author: Carlos Garcia Campos <[email protected]>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp
Log Message:
-----------
Cherry-pick 317536@main (9e6e8ccd4bcf).
https://bugs.webkit.org/show_bug.cgi?id=319810
[WPE] webkit://gpu doesn't show the preferred format device when using the
default
https://bugs.webkit.org/show_bug.cgi?id=319810
Reviewed by Adrian Perez de Castro.
A null device in a preferred buffer format tranche means using the main
device, so check if tranche device is null and use the main one instead.
* Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp:
(WebKit::preferredBufferFormats):
Canonical link: https://commits.webkit.org/317536@main
Canonical link: https://commits.webkit.org/305877.1010@webkitglib/2.52
Commit: 8c2ed3b35c7f802167742b42c76f191ab40688f2
https://github.com/WebKit/WebKit/commit/8c2ed3b35c7f802167742b42c76f191ab40688f2
Author: Carlos Garcia Campos <[email protected]>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp
Log Message:
-----------
Cherry-pick 317535@main (7b34c82d13a8).
https://bugs.webkit.org/show_bug.cgi?id=319809
[GTK][WPE] Function webkitDrmGetFormatName produces wrong string when
trimming trailing spaces
https://bugs.webkit.org/show_bug.cgi?id=319809
Reviewed by Adrian Perez de Castro.
It replaces the empty spaces with null characters, but the size of the
CString doesn't change. This is causing that the formats string shown in
webkit://gpu is garbled. It doesn't affect GTK for me because it doesn't
show any format with trailing spaces, but the bug is present anyway. We
can use a std::array instead of a CString, wich also saves a heap
allocation for every format, and then construct a std::span with the
buffer size without the trailing spaces.
* Source/WebKit/UIProcess/API/glib/WebKitProtocolHandler.cpp:
(WebKit::webkitDrmGetFormatName):
Canonical link: https://commits.webkit.org/317535@main
Canonical link: https://commits.webkit.org/305877.1011@webkitglib/2.52
Commit: bce095daa5ecbf53239c50b887fd2f2ec758a60d
https://github.com/WebKit/WebKit/commit/bce095daa5ecbf53239c50b887fd2f2ec758a60d
Author: SABITHSAHEB <[email protected]>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M Source/WTF/wtf/URLHelpers.cpp
M Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebKitURIUtilities.cpp
Log Message:
-----------
Cherry-pick 317537@main (e08a16763c94).
https://bugs.webkit.org/show_bug.cgi?id=319161
Fix out-of-bounds buffer index in userVisibleURL when probing for xn--
https://bugs.webkit.org/show_bug.cgi?id=319161
Reviewed by Patrick Griffis.
userVisibleURL() probes the output buffer for an "xn--" prefix by reading
back from the index it just wrote (after[afterIndex - 4 .. afterIndex - 2]),
but it gated those reads on the input index (i >= 3) rather than the output
index. When an earlier percent escape decodes to a single byte (for example
%AB, which is > 0x7f), the input index advances three positions while the
output index advances one, so a '-' can be reached while afterIndex < 4.
afterIndex - 4 then wraps around as size_t and indexes the bounds-checked
Vector out of range.
Gate the probe on afterIndex >= 4 so it tracks the buffer it actually reads.
A legitimate "xn--" prefix always writes four literal output bytes, so its
detection is unaffected. The input is reachable from untrusted data through
the public webkit_uri_for_display() API and Internals.userVisibleString; the
minimal trigger is "%AB-".
* Source/WTF/wtf/URLHelpers.cpp:
(WTF::URLHelpers::userVisibleURL):
* Tools/TestWebKitAPI/Tests/WebKit/WKPage/glib/TestWebKitURIUtilities.cpp:
(testURIForDisplayShortPercentEncoded):
(beforeAll):
Canonical link: https://commits.webkit.org/317537@main
Canonical link: https://commits.webkit.org/305877.1012@webkitglib/2.52
Commit: 9d13dd1044b113a8cd37bd86774056a240482cc8
https://github.com/WebKit/WebKit/commit/9d13dd1044b113a8cd37bd86774056a240482cc8
Author: Przemyslaw Gorszkowski <[email protected]>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
A
LayoutTests/accessibility/focus-notification-without-prior-tree-access-expected.txt
A
LayoutTests/accessibility/focus-notification-without-prior-tree-access.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 317504@main (48f6c283035d).
https://bugs.webkit.org/show_bug.cgi?id=319475
[WPE][Accessibility] focus change accessibility event is not exposed
https://bugs.webkit.org/show_bug.cgi?id=319475
Reviewed by Tyler Wilcock.
On WPE, if nothing else has queried the accessibility tree yet (e.g. a fresh
AT-SPI client that goes straight to listening for focus events), the very
first
focus change finds no AXObjectCache and is silently dropped:
onFocusChange() is
never called, and no "focused" state-changed notification is ever sent.
Add WPE alongside GTK to the platforms that lazily create the AXObjectCache
on
the first focus change, matching how GTK already behaves.
Test: accessibility/focus-notification-without-prior-tree-access.html
*
LayoutTests/accessibility/focus-notification-without-prior-tree-access-expected.txt:
Added.
*
LayoutTests/accessibility/focus-notification-without-prior-tree-access.html:
Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setFocusedElement):
Canonical link: https://commits.webkit.org/317504@main
Canonical link: https://commits.webkit.org/305877.1013@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/bf31587aee9a...9d13dd1044b1
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
