Branch: refs/heads/webkitglib/2.42
Home: https://github.com/WebKit/WebKit
Commit: 41f2585617fb9228158f3fd587dfa9abbc0b7ed7
https://github.com/WebKit/WebKit/commit/41f2585617fb9228158f3fd587dfa9abbc0b7ed7
Author: Joseph Griego <[email protected]>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
M Source/JavaScriptCore/assembler/ARMv7Assembler.h
M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h
M Source/JavaScriptCore/llint/LowLevelInterpreter.asm
M Source/JavaScriptCore/offlineasm/arm.rb
Log Message:
-----------
Cherry-pick 269481@main (4a0ec7daa9e9).
https://bugs.webkit.org/show_bug.cgi?id=263322
[JSC][armv7] Use udf for break/breakpoint in offlineasm/masm
https://bugs.webkit.org/show_bug.cgi?id=263322
Reviewed by Yusuke Suzuki.
`bkpt` behaves very badly under gdb on armv7; it hangs [1] rather than
traps.
To workaround, use `udf #0` instead; the encodings and semantics are very
similar.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22645
* Source/JavaScriptCore/assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::udf):
* Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::breakpoint):
* Source/JavaScriptCore/offlineasm/arm.rb:
Canonical link: https://commits.webkit.org/269481@main
Commit: 2544043ab96039f921852093f40a754f7167c684
https://github.com/WebKit/WebKit/commit/2544043ab96039f921852093f40a754f7167c684
Author: Chris Dumez <[email protected]>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
M Source/WTF/wtf/URL.h
M Tools/TestWebKitAPI/Tests/WTF/URL.cpp
Log Message:
-----------
Cherry-pick 269750@main (e68882fc2467).
https://bugs.webkit.org/show_bug.cgi?id=263615
The URL move constructor doesn't invalidate the "moved-out" URL
https://bugs.webkit.org/show_bug.cgi?id=263615
Reviewed by Ryosuke Niwa.
The URL move constructor doesn't invalidate the "moved-out" URL. This can
lead
WebKit code to do weird things.
For example, URLKeepingBlobAlive contains a m_url data member and is often
moved-out to pass to a lambda. The destructor of the "moved-out"
URLKeepingBlobAlive then runs and calls
`unregisterBlobURLHandleIfNecessary()`.
`unregisterBlobURLHandleIfNecessary()` will try to use m_url after it's been
moved out to see if the URL protocol is "blob". This causes
URL::protocolIs()
to try to do out-of-bound access in the underlying String (since the URL is
marked as valid, even though it's m_string was moved out and other data
members
that are indexes into that string were not reset). Luckily, String's
operator[]
just returns nil when doing an out of bounds access at the moment.
* Source/WTF/wtf/URL.h:
(WTF::URL::URL):
(WTF::URL::operator=):
* Tools/TestWebKitAPI/Tests/WTF/URL.cpp:
(TestWebKitAPI::TEST_F):
Canonical link: https://commits.webkit.org/269750@main
Commit: f1e03c155822aac9c8ad44d3dbaa1d9d17bba68e
https://github.com/WebKit/WebKit/commit/f1e03c155822aac9c8ad44d3dbaa1d9d17bba68e
Author: Erica Li <[email protected]>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
M LayoutTests/TestExpectations
A
LayoutTests/http/tests/webshare/navigator-share-files-fail-access-control-checks-crash-expected.txt
A
LayoutTests/http/tests/webshare/navigator-share-files-fail-access-control-checks-crash.html
M Source/WebCore/page/ShareDataReader.cpp
Log Message:
-----------
Cherry-pick 269885@main (577579c2ca91).
https://bugs.webkit.org/show_bug.cgi\?id\=263643
jsc_fuz/wktr: null ptr deref in
WebCore::ShareDataReader::start(WebCore::Document*,
WebCore::ShareDataWithParsedURL&&) + 240 (ShareDataReader.cpp:53)
https://bugs.webkit.org/show_bug.cgi\?id\=263643
rdar://115059534
Reviewed by Chris Dumez.
Adding empty check for m_pendingFileLoads in case reader has canceled
during loop due to error and accessing null ptr.
* LayoutTests/TestExpectations: Exclude console message as this test
logging blob url which contains unique UUID generated from each run.
*
LayoutTests/http/tests/webshare/navigator-share-files-fail-access-control-checks-crash-expected.txt:
Added.
*
LayoutTests/http/tests/webshare/navigator-share-files-fail-access-control-checks-crash.html:
Added.
* Source/WebCore/page/ShareDataReader.cpp:
(WebCore::ShareDataReader::start):
Canonical link: https://commits.webkit.org/269885@main
Commit: 1507cdd08555a2559e249d475f079fcbb7fdbc22
https://github.com/WebKit/WebKit/commit/1507cdd08555a2559e249d475f079fcbb7fdbc22
Author: Mike Wyrzykowski <[email protected]>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
M Source/WebCore/rendering/RenderVideo.cpp
Log Message:
-----------
Cherry-pick 270032@main (0dfdb1a30720).
https://bugs.webkit.org/show_bug.cgi?id=263990
RenderVideo::videoBox crashes when intrinsic size is zero
https://bugs.webkit.org/show_bug.cgi?id=263990
<radar://116303559>
Reviewed by Alan Baradlay.
LayoutSize::fitToAspectRatio(aspectRatio, ) assumes that aspectRatio is
non-empty as it divides by aspectRatio.height() and aspectRatio.width().
When either are zero, this would result in a floating point exception due to
division by zero.
It's not clear we should add this check to fitToAspectRatio() and based on
where
fitToAspectRatio is called, it seems more appropriate to check before the
call site.
* Source/WebCore/rendering/RenderVideo.cpp:
(WebCore::RenderVideo::videoBox const):
Ensure that intrinsicSize is not empty.
Canonical link: https://commits.webkit.org/270032@main
Commit: 47c5ed1c26cc0346c1b3171068492e00ed2950cf
https://github.com/WebKit/WebKit/commit/47c5ed1c26cc0346c1b3171068492e00ed2950cf
Author: Aditya Keerthi <[email protected]>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
A
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-baseline-alignment-expected.html
A
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-baseline-alignment.html
A
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-taller-button-height-expected.html
A
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-taller-button-height.html
M LayoutTests/platform/gtk/TestExpectations
M
LayoutTests/platform/ios/fast/forms/auto-fill-button/input-strong-password-auto-fill-button-expected.txt
M
LayoutTests/platform/mac/fast/forms/auto-fill-button/input-strong-password-auto-fill-button-expected.txt
M Source/WebCore/rendering/RenderBlockFlow.cpp
M Source/WebCore/rendering/RenderTextControlSingleLine.cpp
Log Message:
-----------
Cherry-pick 270068@main (af06b864403c).
https://bugs.webkit.org/show_bug.cgi?id=263921
Strong Password button is clipped on google.com and imdb.com
https://bugs.webkit.org/show_bug.cgi?id=263921
rdar://113701243
Reviewed by Alan Baradlay.
Descenders in the "Strong Password" button in autofilled fields with strong
passwords are clipped on google.com and imdb. This issue is exacerbated when
the user has a system language which has very tall descenders, such as
Hindi.
There are two distinct issues contributing to the clipping, both as a
consequence of the behavior added in 200350@main, which made it so that
"Strong Password" is hidden in narrow inputs.
1. 200350@main began forcing the height of the text container in input
elements to equal the height of the inner text. This was done so that
the "Strong Password" button could overflow (and be hidden) on to the
next line in narrow inputs. However, this is problematic, as in cases
where the button does not overflow, and is taller than the inner text,
the button is clipped to match the height of the inner text. This
scenario commonly occurs for users with a Hindi language set, as the tall
descenders in Hindi often result in the button being taller than the
password text.
2. Following the changes in 232913@main to correct inline block baseline
behavior, the inner text element receives a "synthesized" baseline. This
means that the text sits on the baseline with the bottom of the
inline-block
box and not with the baseline of the last (only) line. Consequently, the
flex item that wraps the text ends up taller than the actual text. Then,
the
"Strong Password" button, which is also a flex item, gets pushed lower
due
to `align-items: center` alongside the taller flex item. Finally, it gets
clipped for the same reason as clipping in (1). If (1) were fixed,
clipping
would not occur, but the "Strong Password" button would still be
misaligned
with the text.
To fix (1), take the taller of the inner text and "Strong Password" button
in
order to determine the height to use for the container. This ensures that
the
container will not have a height smaller than the button's height in cases
where
the button is visible.
To fix (2), simply stop synthesizing the baseline for the inner text
renderer.
*
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-baseline-alignment-expected.html:
Added.
*
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-baseline-alignment.html:
Added.
*
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-taller-button-height-expected.html:
Added.
*
LayoutTests/fast/forms/auto-fill-button/input-strong-password-viewable-taller-button-height.html:
Added.
* LayoutTests/platform/gtk/TestExpectations:
*
LayoutTests/platform/ios/fast/forms/auto-fill-button/input-strong-password-auto-fill-button-expected.txt:
*
LayoutTests/platform/mac/fast/forms/auto-fill-button/input-strong-password-auto-fill-button-expected.txt:
Rebaseline the test to reflect the new positions and heights of the shadow
tree
elements. Notably, all the issues described in this commit message are
already
observable in this test. However, because it is a render tree dump test that
also involves additional user input, the issue was never observed.
Due to this testing flaw, additional ref tests have been added as part of
this change.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::inlineBlockBaseline const):
* Source/WebCore/rendering/RenderTextControlSingleLine.cpp:
(WebCore::RenderTextControlSingleLine::layout):
Canonical link: https://commits.webkit.org/270068@main
Commit: e136566934c0f418923942f070733f8654256216
https://github.com/WebKit/WebKit/commit/e136566934c0f418923942f070733f8654256216
Author: Yijia Huang <[email protected]>
Date: 2024-01-25 (Thu, 25 Jan 2024)
Changed paths:
A JSTests/stress/intl-data-time-format-string-overflow.js
M Source/JavaScriptCore/runtime/IntlDateTimeFormat.cpp
Log Message:
-----------
Cherry-pick 270080@main (9a421c3685d0).
https://bugs.webkit.org/show_bug.cgi?id=264056
[JSC] Fix StringAppend crash with tryMakeString in initializeDateTimeFormat
https://bugs.webkit.org/show_bug.cgi?id=264056
rdar://116647363
Reviewed by Yusuke Suzuki.
StringAppend may crash due to string concatenation may has int32
overflow in tryMakeStringFromAdapters. So, to fix issue, we should
use tryMakeString instead to avoid the crash.
* JSTests/stress/intl-data-time-format-string-overflow.js: Added.
(async arguments):
* Source/JavaScriptCore/runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
Canonical link: https://commits.webkit.org/270080@main
Compare: https://github.com/WebKit/WebKit/compare/14b6b197161c...e136566934c0
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
