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 <s...@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.carl...@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_hs...@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 <akeer...@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_gard...@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 <akeer...@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 <charl...@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@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@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_protya...@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@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@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_bugzi...@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 <mohs...@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
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
