[webkit-changes] [WebKit/WebKit] 5b9d8c: Cherry-pick 803a4e01df61. rdar://127422298

Jonathan Bedard noreply at github.com
Tue May 14 14:28:32 PDT 2024


  Branch: refs/heads/safari-7619.1.12-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 5b9d8c8ae8ac1739835d112510e6c89546f595d7
      https://github.com/WebKit/WebKit/commit/5b9d8c8ae8ac1739835d112510e6c89546f595d7
  Author: Said Abou-Hallawa <said at apple.com>
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
    R LayoutTests/ipc/send-gpu-GetShareableBitmap-RemoteRenderingBackend-expected.txt
    R LayoutTests/ipc/send-gpu-GetShareableBitmap-RemoteRenderingBackend.html
    M Source/WebCore/Headers.cmake
    M Source/WebCore/Sources.txt
    M Source/WebCore/WebCore.xcodeproj/project.pbxproj
    M Source/WebCore/platform/graphics/ImageBuffer.cpp
    M Source/WebCore/platform/graphics/ImageBuffer.h
    R Source/WebCore/platform/graphics/PixelFormatValidated.cpp
    R Source/WebCore/platform/graphics/PixelFormatValidated.h
    M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
    M Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.cpp
    M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
    M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.h
    M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.messages.in
    M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
    M Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.h
    M Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp
    M Source/WebKit/WebProcess/GPU/graphics/RemoteRenderingBackendProxy.h
    M Tools/TestWebKitAPI/Tests/WebCore/DisplayListRecorderTests.cpp

  Log Message:
  -----------
  Cherry-pick 803a4e01df61. rdar://127422298

    Revert "Assert hit in WebKit::RemoteImageBuffer::getShareableBitmap"
    rdar://127422298

    Reviewed by Simon Fraser.

    This reverts commit 393949a1c17caf79bfdab86b7b0a5fc9cf603ea9.

    It caused bad rendering on NYT.

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


  Commit: b99e3c5e4503430531e4805c85ee9252ebc1181e
      https://github.com/WebKit/WebKit/commit/b99e3c5e4503430531e4805c85ee9252ebc1181e
  Author: Eric Carlson <eric.carlson at apple.com>
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
    M Source/WebCore/PAL/pal/mac/ScreenCaptureKitSoftLink.h
    M Source/WebCore/PAL/pal/mac/ScreenCaptureKitSoftLink.mm
    M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.h
    M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm

  Log Message:
  -----------
  Cherry-pick 88ff63ad3bde. rdar://125925090

    Do not trigger stream configuration updates in case user is capturing screen in large presenter overlay mode

    Do not trigger stream configuration updates in case user is capturing screen in large presenter overlay mode
    https://bugs.webkit.org/show_bug.cgi?id=273684
    rdar://125925090

    Reviewed by Eric Carlson.

    We enter in a loop of reconfiguration when trying to update the stream configuration size when user selects large presenter overlay mode.
    We are now skipping the reconfiguration step.
    This reintroduces black stripes like there used to have before rdar://124131045.
    A future patch will fix this by adding cropping within ScreenCaptureKitCaptureSource.

    We detect large presenter overlay mode by:
    - detecting whether video effect is enabled (which means presenter mode is on or off)
    - detecting whether the overlay rectangle (showing the screen content) origin is filled with valid values.

    Manually tested.

    * Source/WebCore/PAL/pal/mac/ScreenCaptureKitSoftLink.h:
    * Source/WebCore/PAL/pal/mac/ScreenCaptureKitSoftLink.mm:
    * Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.h:
    * Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm:
    (-[WebCoreScreenCaptureKitHelper outputVideoEffectDidStartForStream:]):
    (-[WebCoreScreenCaptureKitHelper outputVideoEffectDidStopForStream:]):
    (WebCore::ScreenCaptureKitCaptureSource::streamDidOutputVideoSampleBuffer):

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


  Commit: 54f915a8ea7c5b8c46120d5114a73dd6123454e5
      https://github.com/WebKit/WebKit/commit/54f915a8ea7c5b8c46120d5114a73dd6123454e5
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
    A LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes-expected-mismatch.html
    A LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes.html
    M LayoutTests/platform/mac-wk2/TestExpectations
    M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
    M Source/WebCore/editing/Editor.h
    M Source/WebCore/editing/VisibleSelection.cpp
    M Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h
    M Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Source/WebKit/UIProcess/mac/WebViewImpl.h
    M Source/WebKit/UIProcess/mac/WebViewImpl.mm
    M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Source/WebKit/WebProcess/WebPage/WebPage.h
    M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
    M Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm
    M Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm

  Log Message:
  -----------
  Cherry-pick 6cd1f4e75e31. rdar://127392270

    Letters disappear randomly while typing in Stash when writing suggestions are enabled
    https://bugs.webkit.org/show_bug.cgi?id=273748
    rdar://127392270

    Reviewed by Richard Robinson.

    Stash's JavaScript listens for `keydown` events and, in response, replaces text nodes right before
    the selection in the editable container when writing comments. This interferes with both current
    implementations of writing suggestions (i.e. inline predictions), which depend on the text node
    before the user's selection being the same, as the user types.

    We can detect this case by computing and remembering the last node before the user's selection after
    each editing keyboard event (where writing suggestions would normally be inserted). If this text
    node changes in between the last key event and when sending the next editor state after changing the
    selection, then don't allow writing suggestions.

    * LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes-expected-mismatch.html: Added.
    * LayoutTests/editing/input/mac/do-not-allow-inline-predictions-if-text-changes.html: Added.

    Add a layout test to exercise the new heuristic.

    * LayoutTests/platform/mac-wk2/TestExpectations:
    * Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:

    Remove the internal `InlinePredictionsInAllEditableElementsEnabled` setting. This was only used to
    test writing suggestions on the web, before enabling it by default.

    * Source/WebCore/editing/Editor.h:
    * Source/WebCore/editing/VisibleSelection.cpp:
    (WebCore::VisibleSelection::canEnableWritingSuggestions const):

    Make the `writingsuggestions` state in editable elements follow the enclosing text form control, if
    applicable. This is needed to keep `WritingSuggestionsWebAPI.DefaultStateWithDisabledAutocomplete`
    passing after the change to consult `EditorState` in `-[WKContentView _updateTextInputTraits:]`, now
    that we don't solely depend on the initial focused element information.

    * Source/WebKit/UIProcess/API/mac/WKWebViewPrivateForTestingMac.h:
    * Source/WebKit/UIProcess/API/mac/WKWebViewTestingMac.mm:
    (-[WKWebView _allowsInlinePredictions]):
    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _updateTextInputTraits:]):

    Make the iOS codepath honor editor state's writing suggestions enablement flag (which may change on
    the fly, unlike focused element information).

    * Source/WebKit/UIProcess/mac/WebViewImpl.h:
    * Source/WebKit/UIProcess/mac/WebViewImpl.mm:
    (WebKit::WebViewImpl::allowsInlinePredictions const):

    Remove logic to honor the (now-removed) internal feature flag, and simplify the logic a bit.

    * Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
    (WebKit::WebPage::getPlatformEditorStateCommon const):

    Consult `m_lastNodeBeforeWritingSuggestions` when computing `canEnableWritingSuggestions` on the
    `EditorState`'s post-layout data. If the current node has changed since the last key event, avoid
    trying to compute and inject writing suggestions.

    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::didCommitLoad):

    Reset `m_lastNodeBeforeWritingSuggestions`.

    (WebKit::WebPage::updateLastNodeBeforeWritingSuggestions):

    Add a helper method to update `m_lastNodeBeforeWritingSuggestions` after a `keydown`.

    * Source/WebKit/WebProcess/WebPage/WebPage.h:
    * Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
    (WebKit::WebPage::handleEditingKeyboardEvent):
    * Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm:
    (WebKit::WebPage::handleEditingKeyboardEvent):

    Call the helper method above when handling keyboard editing.

    * Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm:
    (WTR::UIScriptControllerMac::setInlinePrediction):

    Make this a no-op when `-_allowsInlinePredictions` is `NO`, so that we can (somewhat indirectly)
    test the new logic to avoid writing suggestions in the case where the text node before the selection
    keeps changing after each key event.

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


  Commit: e88b96ed42e1b7f930fb47fd288878fcb74a560e
      https://github.com/WebKit/WebKit/commit/e88b96ed42e1b7f930fb47fd288878fcb74a560e
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2024-05-07 (Tue, 07 May 2024)

  Changed paths:
    A LayoutTests/editing/style/apply-font-size-to-picture-expected.txt
    A LayoutTests/editing/style/apply-font-size-to-picture.html
    M Source/WebCore/editing/ApplyStyleCommand.cpp

  Log Message:
  -----------
  Cherry-pick 585d66186f6e. rdar://123786373

    Changing font size while the selection is inside a <picture> element breaks source selection
    https://bugs.webkit.org/show_bug.cgi?id=273782
    rdar://123786373

    Reviewed by Wenson Hsieh and Ryosuke Niwa.

    When changing font properties using editor commands, a <font> element may wrap
    the selected nodes. However, when selecting a <picture> element, the selection
    is actually around the contained <img>. Consequently, changing the font currently
    inserts the <font> element as a child of the <picture>. This behavior breaks
    source selection, as <picture> elements should only contain <source> and <img>
    elements.

    Fix by ensuring the <font> element wraps the <picture>.

    * LayoutTests/editing/style/apply-font-size-to-picture-expected.txt: Added.
    * LayoutTests/editing/style/apply-font-size-to-picture.html: Added.
    * Source/WebCore/editing/ApplyStyleCommand.cpp:
    (WebCore::ApplyStyleCommand::applyInlineStyleChange):

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


  Commit: a95e12c5e1ea0bf8fb1c3a428594a7f5dae38db0
      https://github.com/WebKit/WebKit/commit/a95e12c5e1ea0bf8fb1c3a428594a7f5dae38db0
  Author: Megan Gardner <megan_gardner at apple.com>
  Date:   2024-05-08 (Wed, 08 May 2024)

  Changed paths:
    M Source/WebCore/dom/DocumentMarker.h
    M Source/WebKit/WebProcess/WebPage/Cocoa/UnifiedTextReplacementController.mm
    M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
    M Source/WebKit/WebProcess/WebPage/UnifiedTextReplacementController.h
    M Source/WebKit/WebProcess/WebPage/WebPage.h

  Log Message:
  -----------
  Cherry-pick 2605e06756ff. rdar://127563319

    Text invisible after a UnifiedTextReplacement session ends.
    https://bugs.webkit.org/show_bug.cgi?id=273850
    rdar://127563319

    Reviewed by Aditya Keerthi.

    We should be getting a call to set the text visible again, but
    since that isn't happening we should remove the document markers
    associated with a session when it ends. This is a good thing
    to do regardless, and unblocks us while waiting for a more
    correct solution.

    * Source/WebCore/dom/DocumentMarker.h:
    * Source/WebKit/WebProcess/WebPage/Cocoa/UnifiedTextReplacementController.mm:
    (WebKit::UnifiedTextReplacementController::didEndTextReplacementSession<WebUnifiedTextReplacementType::PlainText>):
    (WebKit::UnifiedTextReplacementController::didEndTextReplacementSession):
    * Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
    (WebKit::WebPage::updateTextIndicatorStyleVisibilityForID):

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

Canonical link: https://commits.webkit.org/278385.5@safari-7619.1.12-branch


  Commit: 7e201269cce051111b6b214a51dea32414ecbe23
      https://github.com/WebKit/WebKit/commit/7e201269cce051111b6b214a51dea32414ecbe23
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2024-05-08 (Wed, 08 May 2024)

  Changed paths:
    M Source/WebCore/editing/WebContentReader.h
    M Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm
    M Source/WebKit/WebProcess/WebPage/Cocoa/UnifiedTextReplacementController.mm

  Log Message:
  -----------
  Cherry-pick 1c0cfd634d26. rdar://125998208

    [Unified Text Replacement] Perform sanitization during attributed string conversion
    https://bugs.webkit.org/show_bug.cgi?id=273853
    rdar://125998208

    Reviewed by Wenson Hsieh.

    Unwanted attributes may be added when converting attributed strings to markup.
    Add a new option to fragment creation to sanitize the markup.

    * Source/WebCore/editing/WebContentReader.h:
    * Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm:
    (WebCore::createFragmentInternal):
    * Source/WebKit/WebProcess/WebPage/Cocoa/UnifiedTextReplacementController.mm:
    (WebKit::UnifiedTextReplacementController::textReplacementSessionDidReceiveTextWithReplacementRange):

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

Canonical link: https://commits.webkit.org/278385.6@safari-7619.1.12-branch


  Commit: dfa442fcf81a64b3dde8f739799f2a4397bc40b9
      https://github.com/WebKit/WebKit/commit/dfa442fcf81a64b3dde8f739799f2a4397bc40b9
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-05-08 (Wed, 08 May 2024)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick c4a6aea4c0a2. rdar://127713566

    Add logging when mouse events are not sent when waiting for a context menu to show
    https://bugs.webkit.org/show_bug.cgi?id=273862
    rdar://127713566

    Reviewed by Abrar Rahman Protyasha and Wenson Hsieh.

    There have been recent reports that web content has been unresponsive to mouse events. In 274771 at main, I
    made a change that could be related, but I’m not sure how. If this logging repeatedly appears when the
    bug reproduces, we’ll know 274771 at main is the cause.

    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::processNextQueuedMouseEvent):

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

Canonical link: https://commits.webkit.org/278385.7@safari-7619.1.12-branch


  Commit: ca582a527217ebb39e3ce69fd9c3c8f41bf4a479
      https://github.com/WebKit/WebKit/commit/ca582a527217ebb39e3ce69fd9c3c8f41bf4a479
  Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
  Date:   2024-05-08 (Wed, 08 May 2024)

  Changed paths:
    M Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm

  Log Message:
  -----------
  Cherry-pick 77eafb20baed. rdar://127678373

    REGRESSION (278263 at main): [UnifiedPDF] Using Find-in-page results in stuck text selections
    https://bugs.webkit.org/show_bug.cgi?id=273891
    rdar://127678373

    Reviewed by Sammy Gill.

    We gate our interactions with the selection layer behind a selector
    check for `enumerateRectsAndTransformsForPage:usingBlock:` on the current
    selection. When the current selection gets nulled, because, say,
    Find-in-page is dismissed, canPaintSelectionIntoOwnedLayer() returns
    false. This causes the selection rect invalidation to target the content
    layer and not the selection layer.

    This means that since 278263 at main, we’ve been getting a hodgepodge of
    painting selection rects on both the content layer and the selection
    layer, which is clearly incorrect.

    The fix here is to not perform the selector check on the current
    selection, but instead to perform an instancesRespondToSelector check on
    the PDFSelection class itself, since all we care about is the runtime
    availability of the `enumreateRectsAndTransformsForPage:usingBlock:` API.

    * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm:
    (WebKit::UnifiedPDFPlugin::canPaintSelectionIntoOwnedLayer const):

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

Canonical link: https://commits.webkit.org/278385.8@safari-7619.1.12-branch


  Commit: 199a1da681a76696911c83bac8da2d8d228246e2
      https://github.com/WebKit/WebKit/commit/199a1da681a76696911c83bac8da2d8d228246e2
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2024-05-09 (Thu, 09 May 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7619.1.12.1

Canonical link: https://commits.webkit.org/278385.9@safari-7619.1.12-branch


  Commit: 80cc30023697ade959ec25948846333283b924e3
      https://github.com/WebKit/WebKit/commit/80cc30023697ade959ec25948846333283b924e3
  Author: Mohsin Qureshi <mohsinq at apple.com>
  Date:   2024-05-10 (Fri, 10 May 2024)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.

WebKit-7619.1.12.2

Canonical link: https://commits.webkit.org/278385.10@safari-7619.1.12-branch


Compare: https://github.com/WebKit/WebKit/compare/5b9d8c8ae8ac%5E...80cc30023697

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