[webkit-changes] [WebKit/WebKit] 41f258: Cherry-pick 269481 at main (4a0ec7daa9e9). https://bu...

Thu Jan 25 08:20:42 PST 2024

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: 41f2585617fb9228158f3fd587dfa9abbc0b7ed7
      https://github.com/WebKit/WebKit/commit/41f2585617fb9228158f3fd587dfa9abbc0b7ed7
  Author: Joseph Griego <jgriego at igalia.com>
  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 at 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 <cdumez at apple.com>
  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 at 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 <lerica at apple.com>
  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 at 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 <mwyrzykowski at apple.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M Source/WebCore/rendering/RenderVideo.cpp

  Log Message:
  -----------
  Cherry-pick 270032 at 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 <akeerthi at apple.com>
  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 at 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 at main, which made it so that
    "Strong Password" is hidden in narrow inputs.

    1. 200350 at 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 at 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 <yijia_huang at apple.com>
  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 at 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