Branch: refs/heads/webkitglib/2.48
Home: https://github.com/WebKit/WebKit
Commit: f12babc19a0a0da260e05b1792384a0d5d1c8ac5
https://github.com/WebKit/WebKit/commit/f12babc19a0a0da260e05b1792384a0d5d1c8ac5
Author: Alex Christensen <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Cherry-pick 295732@main (e0d6e8ed6dc9).
https://bugs.webkit.org/show_bug.cgi?id=293913
Null check m_documentLoader in FrameLoader::commitProvisionalLoad
https://bugs.webkit.org/show_bug.cgi?id=293913
rdar://22895074
Reviewed by David Kilzer and Chris Dumez.
It's null checked consistently elsewhere and crash logs indicate it can be
null,
especially when interacting with a CachedPage.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::commitProvisionalLoad):
Canonical link: https://commits.webkit.org/295732@main
Canonical link: https://commits.webkit.org/290945.238@webkitglib/2.48
Commit: 6600a61e46cbe9e48aea319303535842a150c871
https://github.com/WebKit/WebKit/commit/6600a61e46cbe9e48aea319303535842a150c871
Author: Sosuke Suzuki <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
A JSTests/wasm/stress/parse-unreachable-try-table.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 295678@main (70f3c3efa49f).
https://bugs.webkit.org/show_bug.cgi?id=293106
[JSC] Fix parsing unreachable `try_table`
https://bugs.webkit.org/show_bug.cgi?id=293106
Reviewed by Yusuke Suzuki.
`try_table` blocks, like `try` and `block`, are always
terminated by an `end` opcode (`0x0b`). In unreachable
code paths, `parseUnreachableExpression` increments
`m_unreachableBlocks` for `try`/`block` so the parser
later skips the corresponding `end`, but it didn’t do
this for `try_table`.
This patch changes to increment `m_unreachableBlocks`
for unreachable `try_table` blocks as well, allowing
the parser to consume the `end` opcode and parse the
function correctly.
Canonical link: https://commits.webkit.org/295678@main
Canonical link: https://commits.webkit.org/290945.239@webkitglib/2.48
Commit: 6b94382632ecf67cc7fa5c34dc1d025fb7299663
https://github.com/WebKit/WebKit/commit/6b94382632ecf67cc7fa5c34dc1d025fb7299663
Author: Sosuke Suzuki <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
A JSTests/wasm/stress/parse-unreachable-ref-null.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 295644@main (d8a5f39bad4f).
https://bugs.webkit.org/show_bug.cgi?id=293107
[JSC] Fix parsing unreachable `ref.null`
https://bugs.webkit.org/show_bug.cgi?id=293107
Reviewed by Yusuke Suzuki.
WasmFunctionParser has a separate path for parsing known unreachable
code. However, this segment missed `ref.null` handling.
* JSTests/wasm/stress/parse-unreachable-ref-null.js: Added.
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
Canonical link: https://commits.webkit.org/295644@main
Canonical link: https://commits.webkit.org/290945.240@webkitglib/2.48
Commit: 4136fdeef8377f98185185c55fd128b8cdda30d3
https://github.com/WebKit/WebKit/commit/4136fdeef8377f98185185c55fd128b8cdda30d3
Author: Yusuke Suzuki <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
A JSTests/stress/stack-visit-from-non-exception-throwing-handler-ic.js
M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp
Log Message:
-----------
Cherry-pick 295518@main (17dac674cab9).
https://bugs.webkit.org/show_bug.cgi?id=292939
[JSC] ASSERTION FAILED: codeBlock->canGetCodeOrigin(index)
https://bugs.webkit.org/show_bug.cgi?id=292939
rdar://151233525
Reviewed by Justin Michaud.
Even while we do not throw an exception, we may visit a stack (for
ShadowChicken). Thus we should put CallSiteIndex before calling
operations from IC.
While we see assertion in Debug build, since we gracefully stop stack
visiting, we do not see an issue on Release build. Also this affects
only for debug information for ShadowChicken.
* JSTests/stress/stack-visit-from-non-exception-throwing-handler-ic.js:
Added.
(i1.let.i20):
(i1.i20.catch):
* Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:
(JSC::InlineCacheCompiler::generateWithGuard):
(JSC::putByIdTransitionHandlerImpl):
(JSC::putByIdTransitionReallocatingOutOfLineHandler):
(JSC::putByValTransitionHandlerImpl):
(JSC::putByValTransitionOutOfLineHandlerImpl):
Canonical link: https://commits.webkit.org/295518@main
Canonical link: https://commits.webkit.org/290945.241@webkitglib/2.48
Commit: be0cec3f3bdd52f6f8bf58c4d64e1c013a44edc3
https://github.com/WebKit/WebKit/commit/be0cec3f3bdd52f6f8bf58c4d64e1c013a44edc3
Author: Antoine Quint <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
M Source/WebCore/animation/CSSAnimation.cpp
Log Message:
-----------
Cherry-pick 289651.214@safari-7621-branch (b1c3584f086f).
https://bugs.webkit.org/show_bug.cgi?id=288441
ASAN_TRAP | WebCore::CSSAnimation::syncStyleOriginatedTimeline;
WebCore::CSSAnimation::syncPropertiesWithBackingAnimation;
WebCore::Styleable::updateCSSAnimations
https://bugs.webkit.org/show_bug.cgi?id=288441
rdar://144403873
Reviewed by Anne van Kesteren.
We would call into `CSSAnimation::syncStyleOriginatedTimeline()`, which
expects an owning element
for the given CSS Animation, through
`CSSAnimation::syncPropertiesWithBackingAnimation()`, which
did not check for a valid owning element. However, it does not make sense
to sync any of the
`animation-*` CSS properties if the owning element was disassociated, so an
early return for the
entire `CSSAnimation::syncPropertiesWithBackingAnimation()` method makes
sense here.
*
LayoutTests/webanimations/css-animation-update-without-an-effect-expected.txt:
Added.
* LayoutTests/webanimations/css-animation-update-without-an-effect.html:
Added.
* Source/WebCore/animation/CSSAnimation.cpp:
(WebCore::CSSAnimation::syncPropertiesWithBackingAnimation):
Canonical link: https://commits.webkit.org/289651.214@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.242@webkitglib/2.48
Commit: 020779c7a33c3a717cb5e0f6fdd8c6bbcc11bc3c
https://github.com/WebKit/WebKit/commit/020779c7a33c3a717cb5e0f6fdd8c6bbcc11bc3c
Author: Philippe Normand <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
R
LayoutTests/platform/glib/http/wpt/mediarecorder/MediaRecorder-audio-samplingrate-change-expected.txt
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 295096@main (745395403a0b).
https://bugs.webkit.org/show_bug.cgi?id=293112
REGRESSION(289993@main): [GStreamer] Introduced
http/wpt/mediarecorder/MediaRecorder-audio-samplingrate-change.html failure
https://bugs.webkit.org/show_bug.cgi?id=293112
Reviewed by Xabier Rodriguez-Calvar.
Use playbin3 when playback of blob URIs is requested. As on-disk buffering
makes little sense of
already in-memory data, configure urisourcebin to use a ring buffer when
playing blob URIs. This
forces downstream demuxers to operate in pull mode which works better than
push mode, specially for
matroska.
* LayoutTests/platform/glib/TestExpectations:
*
LayoutTests/platform/glib/http/wpt/mediarecorder/MediaRecorder-audio-samplingrate-change-expected.txt:
Removed.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::configureElement):
(WebCore::MediaPlayerPrivateGStreamer::createGSTPlayBin):
Canonical link: https://commits.webkit.org/295096@main
Canonical link: https://commits.webkit.org/290945.243@webkitglib/2.48
Commit: f4c894cd1efb03d1186d3a10361b116357b58f56
https://github.com/WebKit/WebKit/commit/f4c894cd1efb03d1186d3a10361b116357b58f56
Author: Antoine Quint <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
A
LayoutTests/webanimations/mismatching-animation-range-longhands-when-copying-expected.txt
A
LayoutTests/webanimations/mismatching-animation-range-longhands-when-copying.html
M Source/WebCore/css/ShorthandSerializer.cpp
Log Message:
-----------
Cherry-pick 294999@main (a8cec25e37d5).
https://bugs.webkit.org/show_bug.cgi?id=291738
Tab Crash When ASSERTION FAILED: startList->size() == endList->size()
https://bugs.webkit.org/show_bug.cgi?id=291738
rdar://150018184
Reviewed by Anne van Kesteren.
Selecting an element that has `animation-range-start` and
`animation-range-end` values
with mismatching lengths would trigger the assertion that both values would
have the
same length under `ShorthandSerializer::serializeAnimationRange()`.
We now account for that possibility and fallback to returning the empty
string.
We also add a new test that would have crashed in Debug to the assertion
failure prior
to this fix.
*
LayoutTests/webanimations/mismatching-animation-range-longhands-when-copying-expected.txt:
Added.
*
LayoutTests/webanimations/mismatching-animation-range-longhands-when-copying.html:
Added.
* Source/WebCore/css/ShorthandSerializer.cpp:
(WebCore::ShorthandSerializer::serializeAnimationRange const):
Canonical link: https://commits.webkit.org/294999@main
Canonical link: https://commits.webkit.org/290945.244@webkitglib/2.48
Commit: 4e2f228d6949438b9c1fdff9d61046a17cd128f6
https://github.com/WebKit/WebKit/commit/4e2f228d6949438b9c1fdff9d61046a17cd128f6
Author: Sam Weinig <[email protected]>
Date: 2025-06-10 (Tue, 10 Jun 2025)
Changed paths:
A LayoutTests/fast/canvas/font-line-height-normal-expected.txt
A LayoutTests/fast/canvas/font-line-height-normal.html
M Source/WebCore/css/parser/CSSPropertyParserConsumer+Font.cpp
M Source/WebCore/css/parser/CSSPropertyParserConsumer+MetaConsumer.h
M
Source/WebCore/css/parser/CSSPropertyParserConsumer+MetaConsumerDefinitions.h
Log Message:
-----------
Cherry-pick 294767@main (3606cb0acd00).
https://bugs.webkit.org/show_bug.cgi?id=291667
REGRESSION(288714@main): CanvasRenderingContext2D font with normal line
height fails to parse
https://bugs.webkit.org/show_bug.cgi?id=291667
rdar://149459999
Reviewed by Darin Adler.
Fixes regression in 288714@main that failed to parse the keyword `normal`
when parsing strings passed to `CanvasRenderingContext2D.font`.
The issue was due failing to include
CSSPropertyParserConsumer+KeywordDefinitions.h
in CSSPropertyParserConsumer+Font.cpp, which meant that the `MetaConsumer`
didn't have
a consumer for keyword values when being invoked in
`consumeLineHeightUnresolved`.
To ensure this kind of issue can't happen in the future, we now statically
assert
that all types passed to `MetaConsumer have `ConsumerDefinition`
specializations
defined. Confirmed this works by just adding the assertion, which
immediately caused
the build to fail pointing directly to `consumeLineHeightUnresolved`.
* LayoutTests/fast/canvas/font-line-height-normal-expected.txt: Added.
* LayoutTests/fast/canvas/font-line-height-normal.html: Added.
* Source/WebCore/css/parser/CSSPropertyParserConsumer+Font.cpp:
* Source/WebCore/css/parser/CSSPropertyParserConsumer+MetaConsumer.h:
*
Source/WebCore/css/parser/CSSPropertyParserConsumer+MetaConsumerDefinitions.h:
Canonical link: https://commits.webkit.org/294767@main
Canonical link: https://commits.webkit.org/290945.245@webkitglib/2.48
Compare: https://github.com/WebKit/WebKit/compare/235fc3204ba0...4e2f228d6949
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
