[webkit-changes] [WebKit/WebKit] 00ffde: Cherry-pick 281307 at main (52ae7a91d2f1). https://bu...

[Simon Fraser]

  Branch: refs/heads/webkitglib/2.44
  Home:   https://github.com/WebKit/WebKit
  Commit: 00ffde40dfc59c157170922f6c876b08fa3e0bc6
      https://github.com/WebKit/WebKit/commit/00ffde40dfc59c157170922f6c876b08fa3e0bc6
  Author: Ahmad Saleem <ahmad.saleem792 at gmail.com>
  Date:   2024-09-04 (Wed, 04 Sep 2024)

  Changed paths:
    M Source/WebCore/rendering/RenderLayer.cpp
    M Source/WebCore/rendering/RenderLayerModelObject.cpp

  Log Message:
  -----------
  Cherry-pick 281307 at main (52ae7a91d2f1). https://bugs.webkit.org/show_bug.cgi?id=276996

    destroyLayer() should call setHasLayer(false)

    https://bugs.webkit.org/show_bug.cgi?id=276996

    Reviewed by Simon Fraser.

    Merge: https://github.com/chromium/chromium/commit/515b887cc764eff0fd976bf60efd6dd6fd099ec5

    This change synchronize clearing the layer and calling setHasLayer.
    The old code would dissociate the two operations to handle clean-ups
    during RenderLayer::removeOnlyThisLayer. The dissociation was
    introduced to handle bug 25252 (33539 at main)
    and Eric wasn't sure at the time it was the right solution.

    Based on the fact that the tests are still passing, it wasn't.

    * Source/WebCore/rendering/RenderLayer.cpp:
    (WebCore::RenderLayer::removeOnlyThisLayer):
    * Source/WebCore/rendering/RenderLayerModelObject.cpp:
    (WebCore::RenderLayerModelObject::willBeDestroyed):
    (WebCore::RenderLayerModelObject::destroyLayer):

    Canonical link: https://commits.webkit.org/281307@main

Canonical link: https://commits.webkit.org/274313.414@webkitglib/2.44


  Commit: b098c860ae82c7f508639b1246dea6ecd949fdda
      https://github.com/WebKit/WebKit/commit/b098c860ae82c7f508639b1246dea6ecd949fdda
  Author: Tyler Wilcock <tyler_w at apple.com>
  Date:   2024-09-04 (Wed, 04 Sep 2024)

  Changed paths:
    A LayoutTests/accessibility/mixed-contenteditable-double-br-visible-character-range-hang-expected.txt
    A LayoutTests/accessibility/mixed-contenteditable-double-br-visible-character-range-hang.html
    A LayoutTests/accessibility/mixed-contenteditable-visible-character-range-hang-expected.txt
    A LayoutTests/accessibility/mixed-contenteditable-visible-character-range-hang.html
    M LayoutTests/platform/glib/TestExpectations
    M LayoutTests/platform/ios/TestExpectations
    A LayoutTests/platform/ios/accessibility/mixed-contenteditable-double-br-visible-character-range-hang-expected.txt
    A LayoutTests/platform/ios/accessibility/mixed-contenteditable-visible-character-range-hang-expected.txt
    M LayoutTests/platform/mac-wk1/TestExpectations
    M Source/WebCore/accessibility/AccessibilityObject.cpp

  Log Message:
  -----------
  Cherry-pick 281089 at main (4b84c3ea8c26). https://bugs.webkit.org/show_bug.cgi?id=276656

    AX: WebCore::endOfLine can return the same position it started with, causing an infinite loop when iterating over `AccessibilityObject::nextLineEndPosition`s
    https://bugs.webkit.org/show_bug.cgi?id=276656
    rdar://131837344

    Reviewed by Andres Gonzalez.

    In `WebCore::endOfLine(const VisiblePosition& input)`, the input position is taken, and an `endPositionForLine` is
    computed. It then checks to ensure that `inSameLine(input, computedEnd)`, and if not, it walks `previous()` one position
    from `input` and gets the `endPositionForLine` of that position.

    This all makes sense on the surface. `endOfLine`s job is to find the end position of the line `input` belongs to. The
    problem is that `inSameLine` does not arguably work intuitively — it returns false if position A is editable, while
    position B is not, even if they are rendered on the same line.

    This mixed editability is present in markup on Google Docs documents:

    <span class="text-style">Line of text</span><span contenteditable="false"> <br role="presentation"/></span>

    There is a single space character before the br element, and if that position is compared with any earlier one,
    `inSameLine` will return false.

    I did try passing a flag through to `isSameLine` that ignored this editability requirement, but there are other ways
    to trigger this behavior too, so the bug persisted. Instead, I've made nextLineEndPosition resilient to this issue
    by looping until we have moved off the start position.

    Two testcases added — these hang indefinitely without the changes in this commit.

    * LayoutTests/accessibility/mixed-contenteditable-double-br-visible-character-range-hang-expected.txt: Added.
    * LayoutTests/accessibility/mixed-contenteditable-double-br-visible-character-range-hang.html: Added.
    * LayoutTests/accessibility/mixed-contenteditable-visible-character-range-hang-expected.txt: Added.
    * LayoutTests/accessibility/mixed-contenteditable-visible-character-range-hang.html: Added.
    * LayoutTests/platform/glib/TestExpectations: Disable new tests.
    * LayoutTests/platform/ios/TestExpectations: Enable new tests.
    * LayoutTests/platform/ios/accessibility/mixed-contenteditable-double-br-visible-character-range-hang-expected.txt: Added.
    * LayoutTests/platform/ios/accessibility/mixed-contenteditable-visible-character-range-hang-expected.txt: Added.
    * LayoutTests/platform/mac-wk1/TestExpectations:
    * Source/WebCore/accessibility/AccessibilityObject.cpp:
    (WebCore::AccessibilityObject::nextLineEndPosition const):

    Canonical link: https://commits.webkit.org/281089@main

Canonical link: https://commits.webkit.org/274313.415@webkitglib/2.44


  Commit: 2d09b43768b70c0c2af2ef58796d8009ad7d16c2
      https://github.com/WebKit/WebKit/commit/2d09b43768b70c0c2af2ef58796d8009ad7d16c2
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2024-09-04 (Wed, 04 Sep 2024)

  Changed paths:
    M Source/WebCore/rendering/ImageQualityController.cpp
    M Source/WebCore/rendering/ImageQualityController.h

  Log Message:
  -----------
  Cherry-pick 280872 at main (42d62602b564). https://bugs.webkit.org/show_bug.cgi?id=276347

    ImageQualityController thrashes a timer
    https://bugs.webkit.org/show_bug.cgi?id=276347
    rdar://131352675

    Reviewed by Tim Horton.

    For content with lots of images, `ImageQualityController::chooseInterpolationQuality()` is called each time
    an image paints and potentially restarts a timer. Use a DeferrableOneShotTimer instead, which is designed
    for this kind of use case.

    Also do some other minor optimizations; only call `context.getCTM().isIdentityOrTranslationOrFlipped()` if we need to,
    and only set a new value in the hash tables if the size changed.

    * Source/WebCore/rendering/ImageQualityController.cpp:
    (WebCore::ImageQualityController::ImageQualityController):
    (WebCore::ImageQualityController::restartTimer):
    * Source/WebCore/rendering/ImageQualityController.h:

    Canonical link: https://commits.webkit.org/280872@main

Canonical link: https://commits.webkit.org/274313.416@webkitglib/2.44


Compare: https://github.com/WebKit/WebKit/compare/5f48d180c1b7...2d09b43768b7

To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications