[webkit-changes] [WebKit/WebKit] 861d3a: Cherry-pick 283744 at main (5434ca72afd2). https://bu...

Charlie Wolfe noreply at github.com
Wed Sep 25 02:50:42 PDT 2024


  Branch: refs/heads/webkitglib/2.46
  Home:   https://github.com/WebKit/WebKit
  Commit: 861d3af01ee102920f1300442646507f3ce301c4
      https://github.com/WebKit/WebKit/commit/861d3af01ee102920f1300442646507f3ce301c4
  Author: Fujii Hironori <Hironori.Fujii at sony.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebCore/workers/service/server/SWServer.cpp

  Log Message:
  -----------
  Cherry-pick 283744 at main (5434ca72afd2). https://bugs.webkit.org/show_bug.cgi?id=279806

    Fix use-after-move in SWServer::scheduleJob
    https://bugs.webkit.org/show_bug.cgi?id=279806

    Reviewed by Chris Dumez.

    `jobData` was used after move in SWServer::scheduleJob for Windows
    port.

    * Source/WebCore/workers/service/server/SWServer.cpp:
    (WebCore::SWServer::scheduleJob):

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

Canonical link: https://commits.webkit.org/282416.138@webkitglib/2.46


  Commit: 15836b92cb35e00ca548f5d00fc9ea0496cc4780
      https://github.com/WebKit/WebKit/commit/15836b92cb35e00ca548f5d00fc9ea0496cc4780
  Author: Etienne Segonzac <sgz at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    A LayoutTests/interaction-region/guard-crash-expected.txt
    A LayoutTests/interaction-region/guard-crash.html
    M Source/WebCore/rendering/EventRegion.cpp
    M Source/WebCore/rendering/EventRegion.h
    M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm

  Log Message:
  -----------
  Cherry-pick 283602 at main (42916e1617b6). https://bugs.webkit.org/show_bug.cgi?id=279584

    Fix potential crash with InteractionRegion layers management
    https://bugs.webkit.org/show_bug.cgi?id=279584
    <rdar://134409589>

    Reviewed by Mike Wyrzykowski.

    This patches addresses 2 sources of assertion failures which could lead
    to a crash:
    - duplicate Guard layers covering the same IntRect, breaking the
      assertion on the uniqueness of the `<IntRect, InteractionRegion::Type>`
      pairs.
    - layers reused twice, breaking the assertion on the `insertionPoint`
      always being <=the sublayers count.

    * Source/WebCore/rendering/EventRegion.h:
    * Source/WebCore/rendering/EventRegion.cpp:
    (WebCore::EventRegionContext::uniteInteractionRegions):
    (WebCore::EventRegionContext::removeSuperfluousInteractionRegions):
    Keep track of all guard rects, _including_ the inflated ones we add for
    small elements or complex shapes, to avoid duplicates.
    We still need to differentiate the two since only the inflated ones can
    get collided out in `removeSuperfluousInteractionRegions`.

    (WebCore::EventRegionContext::convertGuardContainersToInterationIfNeeded):
    Finish migrating the InteractionRegion rect tracking code to use
    `HashMap#add()` / `isNewEntry` to avoid extra hash lookups.

    * Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
    (WebKit::updateLayersForInteractionRegions):
    Fix a bug where a layer was sometimes not removed from the reusable map
    after use.

    * LayoutTests/interaction-region/guard-crash-expected.txt: Added.
    * LayoutTests/interaction-region/guard-crash.html: Added.
    Introduce a test covering those assertion failures.
    (The expected layer tree would reveal the bug even in release mode.)

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

Canonical link: https://commits.webkit.org/282416.139@webkitglib/2.46


  Commit: e182570702b8e4e9193b982ac1c440a81a2fcd4d
      https://github.com/WebKit/WebKit/commit/e182570702b8e4e9193b982ac1c440a81a2fcd4d
  Author: Jani Hautakangas <jani at igalia.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebKit/UIProcess/Automation/libwpe/WebAutomationSessionWPE.cpp

  Log Message:
  -----------
  Cherry-pick 283541 at main (133e49a1e0db). https://bugs.webkit.org/show_bug.cgi?id=279438

    [WebDriver][WPE] Mouse interaction simulation needs to take accout device scale with old API
    https://bugs.webkit.org/show_bug.cgi?id=279438

    Reviewed by Carlos Garcia Campos.

    WebAutomationSession misses scaling mouse interaction simulation in case of old WPE API.

    * Source/WebKit/UIProcess/Automation/libwpe/WebAutomationSessionWPE.cpp:
    (WebKit::WebAutomationSession::platformSimulateMouseInteraction):

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

Canonical link: https://commits.webkit.org/282416.140@webkitglib/2.46


  Commit: 30139de441873ba9da3e9f2892a06df357e94b85
      https://github.com/WebKit/WebKit/commit/30139de441873ba9da3e9f2892a06df357e94b85
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M LayoutTests/TestExpectations
    M Source/WebCore/platform/text/SegmentedString.cpp

  Log Message:
  -----------
  Cherry-pick 283540 at main (818118e729fb). https://bugs.webkit.org/show_bug.cgi?id=268217

    HTML entity parsing hits SegmentedString::pushBack() assert through document.write()
    https://bugs.webkit.org/show_bug.cgi?id=268217

    Reviewed by Chris Dumez and Darin Adler.

    When advancing past a single-character substring, we should always mark
    such a substring as fully consumed (i.e., set its `length` to `0`),
    and add its consumed character number to `m_numberOfCharactersConsumedPriorToCurrentSubstring`.

    * LayoutTests/TestExpectations:
    * Source/WebCore/platform/text/SegmentedString.cpp:
    (WebCore::SegmentedString::advancePastSingleCharacterSubstringWithoutUpdatingLineNumber):

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

Canonical link: https://commits.webkit.org/282416.141@webkitglib/2.46


  Commit: 84185f402298f488d1bb48461864758a4f9c75e1
      https://github.com/WebKit/WebKit/commit/84185f402298f488d1bb48461864758a4f9c75e1
  Author: Matt Woodrow <mattwoodrow at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    A LayoutTests/compositing/shared-backing/multiple-backing-sharing-providers-expected.html
    A LayoutTests/compositing/shared-backing/multiple-backing-sharing-providers.html
    M LayoutTests/fast/scrolling/ios/event-region-scale-transform-shared-expected.txt
    M LayoutTests/fast/scrolling/ios/event-region-translate-transform-shared-expected.txt
    M Source/WebCore/rendering/RenderLayerCompositor.cpp
    M Source/WebCore/rendering/RenderLayerCompositor.h

  Log Message:
  -----------
  Cherry-pick 283515 at main (73e553cb3575). https://bugs.webkit.org/show_bug.cgi?id=279036

    REGRESSION(279868 at main) Alaska Airlines sign in popup loads behind the website's search field.
    https://bugs.webkit.org/show_bug.cgi?id=279036
    <rdar://134911588>

    Reviewed by Simon Fraser.

    This webpage had multiple backing store providers, and content was incorrectly
    added to the back one, despite overlapping the front one.

    The overlap test uses the bounds of the provider, not the to-be-added layer to
    check if it overlaps, and the providers themselves didn't overlap.

    This restricts multiple backing store providers to only be used when they're
    clipped (as was previously the case), so we can be sure the added layer doesn't
    extend beyond the bounds of the provider. This shouldn't break the performance
    improvement, since we still allow other composited layers to be added infront.

    It does mean in some cases we keep the scroll clipped backing store provider
    open, and prevent accumulating sharing layers into a further forward unclipped
    backing provider. I think given the support for multiple open clipped providers,
    this is a good tradeoff.

    Ideally, we'd allow accumulating bounds and adding to any provider, but that
    seems like a riskier change, as we have to account for scrolling.

    This also does a bit of cleanup, unifying the BackingSharingSnapshot and
    preDescendantProviderStartLayer using a generation counter. It also adds a few
    more comments, as I found the logic of why we end backing sharing sequences to
    be hard to follow.

    * LayoutTests/compositing/shared-backing/multiple-backing-sharing-providers-expected.html: Added.
    * LayoutTests/compositing/shared-backing/multiple-backing-sharing-providers.html: Added.
    * Source/WebCore/rendering/RenderLayerCompositor.cpp:
    (WebCore::RenderLayerCompositor::BackingSharingState::snapshot const):
    (WebCore::RenderLayerCompositor::BackingSharingState::generation const):
    (WebCore::RenderLayerCompositor::BackingSharingState::addBackingSharingCandidate):
    (WebCore::RenderLayerCompositor::BackingSharingState::endBackingSharingSequence):
    (WebCore::RenderLayerCompositor::BackingSharingState::backingProviderCandidateForLayer):
    (WebCore::RenderLayerCompositor::computeCompositingRequirements):
    (WebCore::RenderLayerCompositor::traverseUnchangedSubtree):
    (WebCore::RenderLayerCompositor::updateBackingSharingBeforeDescendantTraversal):
    (WebCore::RenderLayerCompositor::updateBackingSharingAfterDescendantTraversal):
    * Source/WebCore/rendering/RenderLayerCompositor.h:

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

Canonical link: https://commits.webkit.org/282416.142@webkitglib/2.46


  Commit: 112166db5a9a7ce5bc3da6b3525089ba17255389
      https://github.com/WebKit/WebKit/commit/112166db5a9a7ce5bc3da6b3525089ba17255389
  Author: Jer Noble <jer.noble at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebCore/Modules/webaudio/AudioWorkletGlobalScope.cpp

  Log Message:
  -----------
  Cherry-pick 283510 at main (f81ff1af098d). https://bugs.webkit.org/show_bug.cgi?id=279537

    CRASH: JSC::construct() under AudioWorkletGlobalScope::createProcessor()
    https://bugs.webkit.org/show_bug.cgi?id=279537
    rdar://133488018

    Reviewed by Ryan Reno.

    JSCallbackData's m_callback ivar is weakly held, so it must be null-checked at access time.

    * Source/WebCore/Modules/webaudio/AudioWorkletGlobalScope.cpp:
    (WebCore::AudioWorkletGlobalScope::createProcessor):

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

Canonical link: https://commits.webkit.org/282416.143@webkitglib/2.46


  Commit: 8467fdfde3848ce1f50088c8a4f7c335ea2aedb9
      https://github.com/WebKit/WebKit/commit/8467fdfde3848ce1f50088c8a4f7c335ea2aedb9
  Author: Said Abou-Hallawa <said at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    A LayoutTests/fast/canvas/canvas-filter-text-drawing-expected.html
    A LayoutTests/fast/canvas/canvas-filter-text-drawing.html
    A LayoutTests/fast/canvas/canvas-layer-filter-text-drawing-expected.html
    A LayoutTests/fast/canvas/canvas-layer-filter-text-drawing.html
    M LayoutTests/platform/glib/TestExpectations
    M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp

  Log Message:
  -----------
  Cherry-pick 283451 at main (59e4b7c01999). https://bugs.webkit.org/show_bug.cgi?id=279348

    Crash happens when applying filter and drawing text in 2D canvas
    https://bugs.webkit.org/show_bug.cgi?id=279348
    rdar://135455808

    Reviewed by Simon Fraser.

    CanvasRenderingContext2DBase::drawTextUnchecked() calls fontProxy() which returns
    a pointer to state().font. Then drawTextUnchecked() calls save() through
    CanvasFilterContextSwitcher::create(). This save() appends a new state to
    m_stateStack. Vector::append() may reallocate its buffer. Reallocating the buffer
    will make the pointer to fontProxy() invalid. This causes a crash when accessing
    the members of fontProxy.

    To fix this make sure, CanvasRenderingContext2D::fontProxy() is called after
    calling CanvasFilterContextSwitcher::create().

    * LayoutTests/fast/canvas/canvas-filter-text-drawing-expected.html: Added.
    * LayoutTests/fast/canvas/canvas-filter-text-drawing.html: Added.
    * LayoutTests/fast/canvas/canvas-layer-filter-text-drawing-expected.html: Added.
    * LayoutTests/fast/canvas/canvas-layer-filter-text-drawing.html: Added.
    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
    (WebCore::CanvasRenderingContext2DBase::drawTextUnchecked):

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

Canonical link: https://commits.webkit.org/282416.144@webkitglib/2.46


  Commit: 6043664de3985910667e09d4145d810858b48902
      https://github.com/WebKit/WebKit/commit/6043664de3985910667e09d4145d810858b48902
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    A LayoutTests/editing/deleting/delete-picture-expected.txt
    A LayoutTests/editing/deleting/delete-picture.html
    A LayoutTests/editing/deleting/delete-text-before-picture-expected.txt
    A LayoutTests/editing/deleting/delete-text-before-picture.html
    M Source/WebCore/editing/DeleteSelectionCommand.cpp

  Log Message:
  -----------
  Cherry-pick 283457 at main (1d56845bb42e). https://bugs.webkit.org/show_bug.cgi?id=279467

    Deleting content immediately before a `<picture>` unexpectedly removes `<source>`s
    https://bugs.webkit.org/show_bug.cgi?id=279467
    rdar://128100106

    Reviewed by Wenson Hsieh and Abrar Rahman Protyasha.

    `<picture>` elements may contain one or more `<source>` elements (which are not
    rendered) and an `<img>` element. When making selections around a `<picture>`
    element, the selection is anchored before or after the `<img>` child.

    Consequently, when the selection is visually before a `<picture>` element, and
    deletion is performed, all `<source>` elements before the selection are also
    removed. This is incorrect, as the `<picture>` element and all its children should
    be left intact.

    Fix by avoiding removal of nodes that have a parent node which cannot have
    children for editing. Only the direct parent is checked, since traversal is
    performed in document order.

    A longer term solution would be to (again) experiment with making
    `canContainRangeEndPoint` return `false` for `HTMLPictureElement`. That change would
    solve this issue by ensuring the selection could never be inside a `<picture>`.
    However, that change is much higher risk, and also causes other selection related
    issues, which need to be investigated independently.

    * LayoutTests/editing/deleting/delete-picture-expected.txt: Added.
    * LayoutTests/editing/deleting/delete-picture.html: Added.

    Test already working behavior to delete a `<picture> element.

    * LayoutTests/editing/deleting/delete-text-before-picture-expected.txt: Added.
    * LayoutTests/editing/deleting/delete-text-before-picture.html: Added.

    Test the issue fixed by this patch.

    * Source/WebCore/editing/DeleteSelectionCommand.cpp:
    (WebCore::DeleteSelectionCommand::handleGeneralDelete):

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

Canonical link: https://commits.webkit.org/282416.145@webkitglib/2.46


  Commit: c591879306ae302b0242c86c56f85c6cda433127
      https://github.com/WebKit/WebKit/commit/c591879306ae302b0242c86c56f85c6cda433127
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M LayoutTests/TestExpectations
    M Source/WebCore/cssjit/SelectorCompiler.cpp

  Log Message:
  -----------
  Cherry-pick 283428 at main (b9e946421ea6). https://bugs.webkit.org/show_bug.cgi?id=278654

    [Debug] ASSERTION FAILED on `fast/rendering/render-list-marker-select.html`
    https://bugs.webkit.org/show_bug.cgi?id=278654

    Reviewed by Matthieu Dubet.

    Do not compile `:is()` selector if it contains a pseudo-element subselector.

    * LayoutTests/TestExpectations:
    * Source/WebCore/cssjit/SelectorCompiler.cpp:
    (WebCore::SelectorCompiler::addPseudoClassType)

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

Canonical link: https://commits.webkit.org/282416.146@webkitglib/2.46


  Commit: 3e35d6447d1d10db6d318e97d2b6ffe0d674a233
      https://github.com/WebKit/WebKit/commit/3e35d6447d1d10db6d318e97d2b6ffe0d674a233
  Author: Jean-Yves Avenard <jya at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M LayoutTests/platform/mac/TestExpectations
    M Source/WebCore/Modules/mediasession/MediaSession.cpp
    M Source/WebCore/Modules/mediasession/MediaSession.h

  Log Message:
  -----------
  Cherry-pick 283269 at main (e7ba88dca5e7). https://bugs.webkit.org/show_bug.cgi?id=278052

    REGRESSION (282158 at main): [macOS] inspector/console/webcore-logging.html is a flaky failure
    https://bugs.webkit.org/show_bug.cgi?id=278052
    rdar://133791485

    Reviewed by Eric Carlson.

    Don't add default `favicon.ico` to the list of icons to retrieve if the document is local.

    Don't attempt to use favicons that aren't served over HTTP. The DocumentLoader automatically adds
    a search for '/favicon.ico' of none were set in the Document.
    Attempting to load a non-existent icon caused unnecessary verbosity in the web inspector's console
    which caused the test to intermittently fail.

    Covered by existing tests and the re-enabled one.

    * LayoutTests/platform/mac/TestExpectations:
    * Source/WebCore/Modules/mediasession/MediaSession.cpp:
    (WebCore::fallbackArtwork):
    (WebCore::MediaSession::updateNowPlayingInfo):
    * Source/WebCore/Modules/mediasession/MediaSession.h:

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

Canonical link: https://commits.webkit.org/282416.147@webkitglib/2.46


  Commit: 2921c5f62577ea49de19fd04c8a6f265b818dc47
      https://github.com/WebKit/WebKit/commit/2921c5f62577ea49de19fd04c8a6f265b818dc47
  Author: Ryosuke Niwa <rniwa at webkit.org>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebCore/platform/Timer.cpp
    M Source/WebCore/platform/ios/wak/WebCoreThread.h
    M Source/WebCore/platform/ios/wak/WebCoreThread.mm

  Log Message:
  -----------
  Cherry-pick 283280 at main (d9fd562a20d0). https://bugs.webkit.org/show_bug.cgi?id=279275

    Release assert in TimerBase::TimerBase on a worker thread
    https://bugs.webkit.org/show_bug.cgi?id=279275

    Reviewed by Chris Dumez.

    Allow the release assert to pass in worker threads.

    * Source/WebCore/platform/Timer.cpp:
    (WebCore::TimerBase::TimerBase):
    (WebCore::TimerBase::setNextFireTime):
    * Source/WebCore/platform/ios/wak/WebCoreThread.h:
    * Source/WebCore/platform/ios/wak/WebCoreThread.mm:
    (WebThreadIsLockedOrDisabledInMainOrWebThread):

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

Canonical link: https://commits.webkit.org/282416.148@webkitglib/2.46


  Commit: bdf8541e682492b0a2da2ad770d368e4da8ed836
      https://github.com/WebKit/WebKit/commit/bdf8541e682492b0a2da2ad770d368e4da8ed836
  Author: Said Abou-Hallawa <said at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebCore/platform/graphics/BitmapImageSource.cpp

  Log Message:
  -----------
  Cherry-pick 283241 at main (926b6385eb9e). https://bugs.webkit.org/show_bug.cgi?id=279221

    REGRESSION(276827 at main): Possible null pointer dereferencing when an image frame finishes decoding while the document is getting closed
    https://bugs.webkit.org/show_bug.cgi?id=279221
    rdar://133487516

    Reviewed by Simon Fraser.

    When the image decoding thread finishes decoding an image frame, don't cache
    this frame unless the ImageDecoder is still available.

    The callers of cacheMetadataAtIndex() and cacheNativeImageAtIndex() will ensure
    the ImageDecoder is still available before calling these functions.

    * Source/WebCore/platform/graphics/BitmapImageSource.cpp:
    (WebCore::BitmapImageSource::imageFrameDecodeAtIndexHasFinished):
    (WebCore::BitmapImageSource::cacheNativeImageAtIndex):

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

Canonical link: https://commits.webkit.org/282416.149@webkitglib/2.46


  Commit: 4e3edb71c8ea8326b9a4429417ceb3cabc47aa2c
      https://github.com/WebKit/WebKit/commit/4e3edb71c8ea8326b9a4429417ceb3cabc47aa2c
  Author: Pawel Lampe <plampe at igalia.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebCore/css/FontFace.cpp

  Log Message:
  -----------
  Cherry-pick 284210 at main (a05bcda9fa15). https://bugs.webkit.org/show_bug.cgi?id=280264

    Unable to load a font face on nxp imx6 platform
    https://bugs.webkit.org/show_bug.cgi?id=280264

    Reviewed by Adrian Perez de Castro.

    This change extends GCC bug workaround for ARM32 platforms as well.

    * Source/WebCore/css/FontFace.cpp:
    (WebCore::FontFace::create):

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

Canonical link: https://commits.webkit.org/282416.150@webkitglib/2.46


  Commit: 71f816fba474e72f7ed029b7b38e90cf1e352bd9
      https://github.com/WebKit/WebKit/commit/71f816fba474e72f7ed029b7b38e90cf1e352bd9
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-09-25 (Wed, 25 Sep 2024)

  Changed paths:
    M Source/WebKit/Platform/IPC/Connection.h

  Log Message:
  -----------
  herry-pick 283163 at main (21bdf1ac2bca). https://bugs.webkit.org/show_bug.cgi?id=279078

    REGRESSION(282321 at main): `MESSAGE_CHECK_WITH_MESSAGE_BASE()` does not return on failure
    https://bugs.webkit.org/show_bug.cgi?id=279078
    rdar://135007825

    Reviewed by Ryosuke Niwa and Sihui Liu.

    282321 at main removed function returns that would happen if an IPC message check failed, so we started to
    use some invalid objects.

    * Source/WebKit/Platform/IPC/Connection.h:

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

Canonical link: https://commits.webkit.org/282416.151@webkitglib/2.46


Compare: https://github.com/WebKit/WebKit/compare/5ec13d6e7ae3...71f816fba474

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


More information about the webkit-changes mailing list