[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