Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 84aca86773f7e79504a987876d64a384b099f366
https://github.com/WebKit/WebKit/commit/84aca86773f7e79504a987876d64a384b099f366
Author: Sammy Gill <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M Source/WebCore/css/CSSStyleSheetObservableArray.cpp
M Source/WebCore/css/CSSToLengthConversionData.cpp
M Source/WebCore/style/values/primitives/StyleLengthResolution.cpp
Log Message:
-----------
Cherry-pick 306918@main (a7e0750c3077).
https://bugs.webkit.org/show_bug.cgi?id=306989
Speculative fix for crashes underneath
StyleLengthResolution::adjustValueForPageZoom
https://bugs.webkit.org/show_bug.cgi?id=306989
rdar://168722605
Reviewed by Brent Fulgham.
Stability data seems to suggest that it is possible to hit some crashes
underneath StyleLengthResolution::adjustValueForPageZoom. These crashes
seem to be coming from the fact that we attempt to access the page zoom
factor via the RenderView on CSSToLengthConversionData.
It is not very clear how we can get into this state since code
inspection seems to indicate that we try very hard to make sure that
cleanup between these two objects is handled properly. An investigation
to attempt to reproduce this crash has also not been very fruitful since
it seems at least some of those who experienced this crash were not
aware that it happened, could not remember it occurring, or were not
able to get it to reproduce either by navigating through history.
In order to increase stability, and also hopefully be able to obtain
more actionable bug reports, we attempt a speculative fix for
addressing this crash. The main change is that in the constructor for
CSSToLengthConversionData, we use a new helper function to figure out
what we should use for the RenderView field. Since we cannot directly
check the existence of the LocalFrameView on the RenderView, we
look at the Document, which is the sole owner of the RenderView, to see
if it is still there. If the Document no longer has its LocalFrameView,
then we will return nullptr for the RenderView. Much of the other code
in CSSToLengthConversionData already performs a nullptr check for
RenderView, so we also need to start doing the same in
adjustValueForPageZoom since there is no guarantee that this pointer is
always non-null.
Canonical link: https://commits.webkit.org/306918@main
Canonical link: https://commits.webkit.org/305877.58@webkitglib/2.52
Commit: 17389bf28724f9074e49cf041c93a7d1bd1453df
https://github.com/WebKit/WebKit/commit/17389bf28724f9074e49cf041c93a7d1bd1453df
Author: Alex Christensen <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/url/percent-encoding.window-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/url/resources/percent-encoding.json
M Source/WebCore/PAL/pal/text/TextCodecICU.cpp
Log Message:
-----------
Cherry-pick 306768@main (47164fceaef4).
https://bugs.webkit.org/show_bug.cgi?id=306742
URL query percent encoding is incorrect
https://bugs.webkit.org/show_bug.cgi?id=306742
rdar://169566553
Reviewed by Anne van Kesteren.
We have used ucnv_setFallback(converter, true) for many, many years
for our ICU-based text decoding. However, when using ICU to encode
non-UTF8 text through a URL, we need to not use the fallback.
This matches the behavior of Chrome and Firefox, and Chromium has a
comment saying this matches Netscape behavior.
This behavior is odd but already implemented and specified in
https://url.spec.whatwg.org/#string-percent-encode-after-encoding
Chromium implemented this by using a class for the URL encoding,
ICUCharsetConverter which does not call ucnv_setFallback, and a
separate class for text encoding, and TextCodecIcu, which does call
ucnv_setFallback. I've already used an abstract interface for this
rare case, URLTextEncoding, in order to keep it down to one
implementation, so I keep that design and use ucnv_setFallback
to turn off fallback when using UnencodableHandling::URLEncodedEntities
for URL query encoding, then I use ucnv_setFallback to reset the state
of the encoder when I'm done with the operation.
Test:
imported/w3c/web-platform-tests/url/resources/percent-encoding.window.html
*
LayoutTests/imported/w3c/web-platform-tests/url/percent-encoding.window-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/url/resources/percent-encoding.json:
* Source/WebCore/PAL/pal/text/TextCodecICU.cpp:
(PAL::TextCodecICU::encode const):
Canonical link: https://commits.webkit.org/306768@main
Canonical link: https://commits.webkit.org/305877.59@webkitglib/2.52
Commit: 41c5ef796c8eeca3abe9e46082f01d1e21ce7a07
https://github.com/WebKit/WebKit/commit/41c5ef796c8eeca3abe9e46082f01d1e21ce7a07
Author: Simon Pena <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M Source/WebKit/UIProcess/API/wpe/WPEWebViewPlatform.cpp
Log Message:
-----------
Cherry-pick 306969@main (f874af99156f).
https://bugs.webkit.org/show_bug.cgi?id=307172
[WPE] Check WPE_TOPLEVEL_STATE_ACTIVE flag when filtering WebPageProxy for
gamepad input
https://bugs.webkit.org/show_bug.cgi?id=307172
Reviewed by Adrian Perez de Castro.
When filtering through top level views,
platformWebPageProxyForGamepadInput was requiring a top level to be
exactly WPE_TOPLEVEL_STATE_ACTIVE, rather than having that flag set.
The effect was that running in full screen would filter out valid top
levels.
Tested manually by running MiniBrowser in full screen.
* Source/WebKit/UIProcess/API/wpe/WPEWebViewPlatform.cpp:
(WKWPE::ViewPlatform::platformWebPageProxyForGamepadInput):
Canonical link: https://commits.webkit.org/306969@main
Canonical link: https://commits.webkit.org/305877.60@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/629601ba3fc3...41c5ef796c8e
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
