[webkit-changes] [WebKit/WebKit] e2edd5: Versioning.
Dan Robson
noreply at github.com
Thu May 18 16:08:59 PDT 2023
Branch: refs/heads/safari-7615.2.9.10-branch
Home: https://github.com/WebKit/WebKit
Commit: e2edd5feef735b9746b06acc7376c667704bde24
https://github.com/WebKit/WebKit/commit/e2edd5feef735b9746b06acc7376c667704bde24
Author: Dan Robson <dan_robson at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.10.1
Identifier: 259548.661 at safari-7615.2.9.10-branch
Commit: 855ddac11e97ef528a4778ebb475f947fed22957
https://github.com/WebKit/WebKit/commit/855ddac11e97ef528a4778ebb475f947fed22957
Author: Brent Fulgham <bfulgham at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
A LayoutTests/dom/html/navigator-plugins-expected.txt
A LayoutTests/dom/html/navigator-plugins.html
M Source/WebCore/page/Navigator.cpp
Log Message:
-----------
Cherry-pick 1cc30ed20c25. rdar://problem/107756651
Correct PDF Plugin descriptions returned by navigator.plugins[x].description
https://bugs.webkit.org/show_bug.cgi?id=255155
<rdar://problem/107756651>
Reviewed by Geoffrey Garen.
In Bug 254189 we corrected a bug where the name of the WebKit Built-in PDF plugin was localized
for the user's settings, which confused some anti-fraud software because the specification requires
the name to be in plain English text.
While that issue was fixed, the specification also requires a consistent English label, "Portable
Document Format" be returned by the 'description' property of the plugin. This is currently localized
in Safari, leading to some anti-fraud software failing.
This patch modifies only the return value from Navigator.plugins[].description, so that other
elements of the Browser UI can correctly localize the description.
* Source/WebCore/page/Navigator.cpp:
(WebCore::Navigator::initializePluginAndMimeTypeArrays):
Canonical link: https://commits.webkit.org/262779@main
Identifier: 259548.662 at safari-7615.2.9.10-branch
Commit: a0f1bd6fb9c48974796a41d94da7987a40565719
https://github.com/WebKit/WebKit/commit/a0f1bd6fb9c48974796a41d94da7987a40565719
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
A LayoutTests/svg/masking/masking-with-event-region-expected.html
A LayoutTests/svg/masking/masking-with-event-region.html
M Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp
M Source/WebCore/rendering/svg/RenderSVGResourceClipper.h
Log Message:
-----------
Cherry-pick e4d2a7474950. rdar://problem/107885344
SVG clip-path is sometimes broken on stevejobsarchive.com
https://bugs.webkit.org/show_bug.cgi?id=255577
rdar://107885344
Reviewed by Said Abou-Hallawa.
http://book.stevejobsarchive.com/ uses CSS clip-path with a reference to an SVG <clipPath> element
which contains text.
In this configuration, RenderSVGResourceClipper::applyClippingToContext() falls back to a code path
that uses an ImageBuffer as a mask, and it caches the ImageBuffer between calls. This caused a
problem when DOM Rendering in the GPU Process was enabled; this code is first hit for a "fake" paint
with a NullGraphicsContext which is updating EventRegions, called out of
`RenderLayerBacking::updateEventRegion()`. The NullGraphicsContext will make a local ImageBuffer.
If we then hit this same code for actual painting with a painting GraphicsContext, we'll use that
cached ImageBuffer, rather than creating a new one with appropriate GPU Process backing.
Fix this by adding `isPaintingDisabled` to the criteria used to decide if the cached buffer can be
re-used.
* LayoutTests/svg/masking/masking-with-event-region-expected.html: Added.
* LayoutTests/svg/masking/masking-with-event-region.html: Added.
* Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp:
(WebCore::RenderSVGResourceClipper::computeInputs):
(WebCore::RenderSVGResourceClipper::applyClippingToContext):
* Source/WebCore/rendering/svg/RenderSVGResourceClipper.h:
(WebCore::ClipperData::Inputs::operator== const):
Canonical link: https://commits.webkit.org/263087@main
Identifier: 259548.663 at safari-7615.2.9.10-branch
Commit: fc54789c41deba74cfa75655774969b51b5083b0
https://github.com/WebKit/WebKit/commit/fc54789c41deba74cfa75655774969b51b5083b0
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
A LayoutTests/fast/events/message-event-data-isolated-world-expected.txt
A LayoutTests/fast/events/message-event-data-isolated-world.html
M Source/WebCore/dom/MessageEvent.cpp
Log Message:
-----------
Cherry-pick ca6ca7d1895d. rdar://problem/107538083
REGRESSION (Safari 16.4): PostMessage with transfer object is broken between contexts
https://bugs.webkit.org/show_bug.cgi?id=254777
rdar://107538083
Reviewed by Geoffrey Garen.
Before 256896 at main, we would construct MessageEvents and give them a
SerializedScriptValue to store internally. Then, the deserialization of this
SerializedScriptValue would happen lazily when the JS accesses
MessageEvent.data. We would then cache the result of the deserialization
inside MessageEvent::m_cachedData to avoid repeated deserializations.
Also note that we would make sure that the cachedData's world matches the
current world before using it. We would deserialize again if the worlds
don't match.
After 256896 at main, we now deserialize the SerializedScriptValue eagerly, so
that we know whether to fire a `message` event or a `messageerror` one.
This deserialization would happen in the main JS world and we would pass
the resulting JSValue to the MessageEvent to store instead of the
SerializedScriptValue. This would work fine for main worlds and regressed
isolated worlds since JSMessageEvent::data() would not have a
SerializedScriptValue to re-deserialize for isolated worlds.
To address the issue, we now construct MessageEvents with a
SerializedScriptValue, like we did before 256896 at main. For performance reasons
we also store the deserialized JSValue in MessageEvent::cachedData so that
later calls to JSMessageEvent::data() don't end up deserializing the
SerializedScriptValue again if called from the main world. However, if the
call for JSMessageEvent::data() comes from an isolated world, the
implementation will properly deserialize the SerializedScriptValue again,
like it did before 256896 at main.
This was tested manually on strava.com.
Test: fast/events/message-event-data-isolated-world.html
* Source/WebCore/dom/MessageEvent.cpp:
(WebCore::MessageEvent::create):
Canonical link: https://commits.webkit.org/263155@main
Identifier: 259548.664 at safari-7615.2.9.10-branch
Commit: 4e700d7ec6105fae4486f2d7d648116d7d9fc334
https://github.com/WebKit/WebKit/commit/4e700d7ec6105fae4486f2d7d648116d7d9fc334
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
A LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-event-in-mainframe-expected.txt
A LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-event-in-mainframe.html
M LayoutTests/css3/scroll-snap/scroll-snap-wheel-event.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios-wk2/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/platform/ScrollingEffectsController.h
M Source/WebCore/platform/mac/ScrollingEffectsController.mm
Log Message:
-----------
Cherry-pick f001b0bc6b6a. rdar://problem/107885426
Cherry-pick 939e8d49f5a5. rdar://problem/107885426
[macOS] Scrolling with a physical mouse wheel should not always animate to the closest snap point
https://bugs.webkit.org/show_bug.cgi?id=255493
rdar://107885426
Reviewed by Simon Fraser.
When scrolling using a physical mouse wheel in a scroll snap container, WebKit's current scroll snap
implementation handles each wheel event in a stateless manner, kicking off a scroll snap animation
to the closest snap point if no other wheel event is observed after 750 ms. This can lead to some
unintuitive behaviors when distances between scroll snap points are large, since the user may scroll
for a single wheel tick expecting to advance to the next page, only for the scroll position to
animate back to where they started.
This patch improves this by treating a stream of discrete wheel events similarly to trackpad-based
momentum scrolling, and animates to the appropriate snap point in the direction of scrolling; this
also aligns our implementation more closely with both Gecko and Blink.
See below for more details.
Test: css3/scroll-snap/scroll-snap-discrete-wheel-event-in-mainframe.html
* LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-event-in-mainframe-expected.txt: Added.
* LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-event-in-mainframe.html: Added.
Add a new layout test to exercise the change, in a mainframe (root) scroll snapping context.
* LayoutTests/css3/scroll-snap/scroll-snap-wheel-event.html:
Adjust an existing stateless scroll snapping test to exercise the change by lowering the scrolling
tick count from 3 to 1. Without this change, this adjustment would've bumped us back to the original
scroll position; after this change, we'll now animate to the next snap point.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/ios-wk2/TestExpectations:
* LayoutTests/platform/mac-wk1/TestExpectations:
Discrete wheel events on the root don't seem to trigger scroll snapping at all in WebKit1, both
before and after this patch. I filed webkit.org/b/255498, to track that issue separately.
* Source/WebCore/platform/ScrollingEffectsController.h:
Maintain a LIFO queue of up to three discrete wheel event deltas, which we use to determine the
user's intended scrolling direction after finishing a stream of discrete wheel events.
* Source/WebCore/platform/mac/ScrollingEffectsController.mm:
(WebCore::ScrollingEffectsController::stopAllTimers):
(WebCore::toWheelEventStatus):
(WebCore::operator<<):
(WebCore::ScrollingEffectsController::scheduleDiscreteScrollSnap):
(WebCore::ScrollingEffectsController::discreteSnapTransitionTimerFired):
Rename "stateless" -> "discrete", to reflect the fact that the new implementation is now stateful
by way of maintaining a queue of recent discrete wheel event deltas. Additionally, use
`transitionToGlideAnimationState()` to kick off scroll snapping if the average wheel event delta is
nonzero.
(WebCore::ScrollingEffectsController::processWheelEventForScrollSnap):
(WebCore::ScrollingEffectsController::scheduleStatelessScrollSnap): Deleted.
Dramatically reduce the delay before firing the scroll snap timer for discrete wheel events, now
that the purpose is no longer to wait for the user to manually scroll to the next page before
snapping, but rather observe enough events to estimate the user's intended scrolling direction.
(WebCore::ScrollingEffectsController::statelessSnapTransitionTimerFired): Deleted.
Canonical link: https://commits.webkit.org/263071@main
Identifier: 259548.665 at safari-7615-branch
Identifier: 259548.665 at safari-7615.2.9.10-branch
Commit: 302eb8deec34f9574877cc84dd3c7d8cf544b0c3
https://github.com/WebKit/WebKit/commit/302eb8deec34f9574877cc84dd3c7d8cf544b0c3
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
A LayoutTests/css3/scroll-snap/resnap-after-layout-expected.txt
A LayoutTests/css3/scroll-snap/resnap-after-layout.html
M LayoutTests/platform/gtk/TestExpectations
M LayoutTests/platform/ios-wk2/TestExpectations
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/platform/ScrollSnapAnimatorState.cpp
M Source/WebCore/platform/ScrollSnapAnimatorState.h
M Source/WebCore/platform/ScrollableArea.cpp
Log Message:
-----------
Cherry-pick 502cd653a7f7. rdar://problem/107885376
Cherry-pick ee03689988d7. rdar://problem/107885376
Scroll snap sometimes jumps back to the wrong place on stevejobsarchive.com
https://bugs.webkit.org/show_bug.cgi?id=255492
rdar://107885376
Reviewed by Wenson Hsieh.
259696 at main added some logic that attempts to re-snap after layout when multiple boxes were snapped,
adding a `m_currentlySnappedBoxes` member to `ScrollSnapAnimatorState`.
However, `m_currentlySnappedBoxes` was only updated in the `resnapAfterLayout` code path, not when
scrolling moved you to a new snap point. That resulted in `resnapAfterLayout` sometimes returning
you to a stale location if you'd scrolled to a new snap point since the last time
`resnapAfterLayout` was run, especially when hitting the "multiple boxes were snapped" clause.
It's troublesome to have both `m_currentlySnappedBoxes` and a `snapTargetID` in each SnapOffset (a
future patch will clean this up). But for now, ensure that `m_currentlySnappedBoxes` is updated on
each scroll-related snap as well as resnapping after layout.
* LayoutTests/css3/scroll-snap/resnap-after-layout-expected.txt: Added.
* LayoutTests/css3/scroll-snap/resnap-after-layout.html: Added.
* LayoutTests/platform/gtk/TestExpectations:
* LayoutTests/platform/ios-wk2/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/platform/ScrollSnapAnimatorState.cpp:
(WebCore::ScrollSnapAnimatorState::setActiveSnapIndexForAxis):
(WebCore::ScrollSnapAnimatorState::updateCurrentlySnappedBoxes):
(WebCore::chooseBoxToResnapTo):
(WebCore::ScrollSnapAnimatorState::resnapAfterLayout):
(WebCore::ScrollSnapAnimatorState::setNearestScrollSnapIndexForAxisAndOffsetInternal):
(WebCore::ScrollSnapAnimatorState::setNearestScrollSnapIndexForOffset):
(WebCore::ScrollSnapAnimatorState::chooseBoxToResnapTo const): Deleted.
(WebCore::ScrollSnapAnimatorState::setNearestScrollSnapIndexForAxisAndOffset): Deleted.
* Source/WebCore/platform/ScrollSnapAnimatorState.h: Some functions can be private.
(WebCore::ScrollSnapAnimatorState::setActiveSnapIndexForAxisInternal): The "internal" implies that it doesn't update m_currentlySnappedBoxes.
(WebCore::ScrollSnapAnimatorState::setActiveSnapIndexForAxis): Deleted.
* Source/WebCore/platform/ScrollableArea.cpp:
(WebCore::ScrollableArea::resnapAfterLayout): Improved logging.
(WebCore::ScrollableArea::doPostThumbMoveSnapping): Improved logging.
Canonical link: https://commits.webkit.org/263097@main
Identifier: 259548.666 at safari-7615-branch
Identifier: 259548.666 at safari-7615.2.9.10-branch
Commit: fd926e8b1a81b49adf6b554b5523b0b635a9c6f6
https://github.com/WebKit/WebKit/commit/fd926e8b1a81b49adf6b554b5523b0b635a9c6f6
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
A LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-events-with-layout-expected.txt
A LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-events-with-layout.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios-wk2/TestExpectations
M Source/WebCore/page/scrolling/ScrollingTree.cpp
M Source/WebCore/page/scrolling/ScrollingTree.h
M Source/WebCore/platform/mac/ScrollingEffectsController.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
Log Message:
-----------
Cherry-pick 361116a68ae6. rdar://problem/108231619
Cherry-pick 025262762049. rdar://problem/108231619
[macOS] Performing layout when scroll snapping with a physical mouse wheel snaps to the last snap position
https://bugs.webkit.org/show_bug.cgi?id=255603
Reviewed by Tim Horton.
Currently, when `resnapAfterLayout()` is called after a layout pass while scrolling with a physical
mouse wheel in a scroll snapping container, we end up erroneously re-snapping to the last active
snap position. This doesn't happen when using a trackpad to scroll because we bail here:
```
void ScrollableArea::resnapAfterLayout()
{
…
if (!scrollAnimator || isScrollSnapInProgress() || isUserScrollInProgress())
return;
```
…due to the fact that `isUserScrollInProgress()` is `true`, since this flag is set over the course
of both user-driven and momentum scrolling phases. Importantly, note that `isScrollSnapInProgress()`
is only `true` in this case where UI-side compositing is *disabled* — this is because nothing
currently calls `{add|remove}NodeWithActiveScrollSnap` on `RemoteScrollingUIState`, which means that
we never end up propagating `m_nodesWithActiveScrollSnap` to the web process when UI-side
compositing is enabled, so from the web-process' perspective, `isScrollSnapInProgress()` is always
`false`.
As such, in order to make physical mouse wheel scrolling work well when there are interleaved layout
passes, the fix is two-fold:
1. Consider `isScrollSnapInProgress()` to be true if the discrete wheel event timer is scheduled.
2. Add plumbing to deliver `isScrollSnapInProgress()` state from the UI process to the web process
through the scrolling state tree, to ensure that this bug fix is also effective when UI-side
compositing is enabled.
Test: css3/scroll-snap/scroll-snap-discrete-wheel-events-with-layout.html
* LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-events-with-layout-expected.txt: Added.
* LayoutTests/css3/scroll-snap/scroll-snap-discrete-wheel-events-with-layout.html: Added.
Add a new test case to exercise the bug fix.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/ios-wk2/TestExpectations:
* Source/WebCore/page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::setNodeScrollSnapInProgress):
* Source/WebCore/page/scrolling/ScrollingTree.h:
(WebCore::ScrollingTree::scrollingTreeNodeDidBeginScrollSnapping):
(WebCore::ScrollingTree::scrollingTreeNodeDidEndScrollSnapping):
Add new override hooks to allow the client layer to know when scrolling tree nodes change "scroll
snap in progress" state. See WebKit2 changes below for more information.
* Source/WebCore/platform/mac/ScrollingEffectsController.mm:
(WebCore::ScrollingEffectsController::stopAllTimers):
(WebCore::ScrollingEffectsController::isScrollSnapInProgress const):
Consider scroll snap in progress if we've scheduled a scroll snap while handling discrete wheel
events.
(WebCore::ScrollingEffectsController::discreteSnapTransitionTimerFired):
Add a couple of call sites to `m_client.didStopScrollSnapAnimation()` in the case where the timer
is either stopped early or without triggering a scroll snap animation, such that we don't end up
with a node being stuck indefinitely in `nodesWithActiveScrollSnap`.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTreeNodeDidBeginScrollSnapping):
(WebKit::RemoteScrollingCoordinatorProxy::scrollingTreeNodeDidEndScrollSnapping):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp:
(WebKit::RemoteScrollingTree::scrollingTreeNodeDidBeginScrollSnapping):
(WebKit::RemoteScrollingTree::scrollingTreeNodeDidEndScrollSnapping):
Add plumbing from `RemoteScrollingTree` -> `RemoteScrollingCoordinatorProxy` ->
`RemoteScrollingUIState` whenever a scrolling node begins or ends scroll snapping progress.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
(WebKit::RemoteScrollingCoordinatorProxyMac::scrollingTreeNodeDidBeginScrollSnapping):
(WebKit::RemoteScrollingCoordinatorProxyMac::scrollingTreeNodeDidEndScrollSnapping):
Canonical link: https://commits.webkit.org/263108@main
Identifier: 259548.667 at safari-7615-branch
Identifier: 259548.667 at safari-7615.2.9.10-branch
Commit: 4a74cdae1f42fdcac74b5674b6440b64beb64b16
https://github.com/WebKit/WebKit/commit/4a74cdae1f42fdcac74b5674b6440b64beb64b16
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-scroll-deceleration-with-obscured-inset-expected.txt
A LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-scroll-deceleration-with-obscured-inset.html
M LayoutTests/platform/ios-wk2/TestExpectations
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
M Tools/WebKitTestRunner/TestOptions.cpp
M Tools/WebKitTestRunner/TestOptions.h
M Tools/WebKitTestRunner/ios/TestControllerIOS.mm
Log Message:
-----------
Cherry-pick 005d93b39e87. rdar://problem/108008480
Cherry-pick dc3e66efee5b. rdar://problem/108008480
[iOS] Scrolling snaps to previous snap point when tapping during a scroll snap in mainframe
https://bugs.webkit.org/show_bug.cgi?id=255670
rdar://108008480
Reviewed by Tim Horton.
When interrupting scroll view deceleration with a tap gesture, we re-run logic to retarget the snap
offset given the current scroll offset and the projected (original) scroll offset where we would've
ended up scrolling. In an overflow region where this bug does *not* reproduce, the current offset is
equal to the projected offset, so we simply retarget to the closest snap point.
However, in a mainframe scroll snapping context where the bug reproduces, the projected snap offset
is off by an amount equal to the top obscured inset, which means that instead of defaulting to the
closest snap position, we'll instead always retarget the previous snap point. To fix this, we simply
apply this same adjustment to this projected offset.
Test: css3/scroll-snap/ios/scroll-snap-mainframe-scroll-deceleration-with-obscured-inset.html
* LayoutTests/TestExpectations:
* LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-scroll-deceleration-with-obscured-inset-expected.txt: Added.
* LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-scroll-deceleration-with-obscured-inset.html: Added.
Add a layout test to exercise this change, by scrolling via a swipe gesture, tapping, and verifying
that we don't snap back to the start.
* LayoutTests/platform/ios-wk2/TestExpectations:
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxyIOS::adjustTargetContentOffsetForSnapping):
Offset the projected offset by the top obscured inset, for consistency with the current offset.
* Tools/WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):
(WTR::TestOptions::keyTypeMapping):
* Tools/WebKitTestRunner/TestOptions.h:
(WTR::TestOptions::obscuredInsetTop const):
* Tools/WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):
Add a new test option to specify a top obscured inset value on the web view.
Canonical link: https://commits.webkit.org/263158@main
Identifier: 259548.669 at safari-7615-branch
Identifier: 259548.668 at safari-7615.2.9.10-branch
Commit: cbb31e0324a839ea51f4f4fa355cc46b16af9f2f
https://github.com/WebKit/WebKit/commit/cbb31e0324a839ea51f4f4fa355cc46b16af9f2f
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
M LayoutTests/media/media-source/media-webm-opus-partial-abort-expected.txt
M LayoutTests/media/media-source/media-webm-opus-partial-abort.html
M LayoutTests/media/media-source/media-webm-opus-partial-expected.txt
M LayoutTests/media/media-source/media-webm-opus-partial.html
M LayoutTests/media/video-test.js
M Source/WebCore/platform/MediaSample.h
M Source/WebCore/platform/graphics/cocoa/CMUtilities.mm
M Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.cpp
M Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.h
Log Message:
-----------
Cherry-pick a1c1e04148d7. rdar://problem/106976225
Cherry-pick 262837 at main (7f1bcb55362b). rdar://106976225
[Cocoa] "Pop" of bad audio heard at the start of certain YouTube videos
https://bugs.webkit.org/show_bug.cgi?id=255212
rdar://106976225
Reviewed by Eric Carlson.
Tracking addition of a test via https://bugs.webkit.org/show_bug.cgi?id=255227.
Two interrelated problems cause discontinuties in the audio output at the
start of certain Opus-encoded WebM files.
1) A bug in the ffmpeg muxer causes the initial block in a cluster to be 1ms
too long, which causes an audible discontinuity to be generated from
AVSampleBufferAudioRenderer.
2) Some Opus-encoded WebM files include a CodecDelay value, which requires
players to decode, but not render, the initial audio frames in a stream.
For 2), map the CodecDelay value to a kCMSampleBufferAttachmentKey_TrimDurationAtStart
attachment in the resulting CMSampleBuffer. This causes the output duration of the
sample to be reduced by the trim duration, and the output presentation time to be
increased by the trim duration, so also shift the input presentation time by the same
amount. This aligns the first audible frame with the start time of the track.
For 1), if a discontinuity is encountered, and the discontinuity is less than 15ms
simply advance the presentation time of the subsequent sample by the discontinuity
duration. Track this discontinuity cumulatively, so that if multiple discontinuities
are encountered that total greater than 15ms, a real audible discontinuity is generated
and the track is brought back in sync with the master timeline.
* Source/WebCore/platform/MediaSample.h:
* Source/WebCore/platform/graphics/cocoa/CMUtilities.mm:
(WebCore::toCMSampleBuffer):
* Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.cpp:
(WebCore::WebMParser::VideoTrackData::consumeFrameData):
(WebCore::WebMParser::AudioTrackData::AudioTrackData):
(WebCore::WebMParser::AudioTrackData::consumeFrameData):
* Source/WebCore/platform/graphics/cocoa/SourceBufferParserWebM.h:
(WebCore::WebMParser::AudioTrackData::AudioTrackData): Deleted.
Canonical link: https://commits.webkit.org/262837@main
Canonical link: https://commits.webkit.org/259548.670@safari-7615-branch
Identifier: 259548.669 at safari-7615.2.9.10-branch
Commit: e66b99f0ed5b43e382617ff222596e3ae4b2348e
https://github.com/WebKit/WebKit/commit/e66b99f0ed5b43e382617ff222596e3ae4b2348e
Author: Russell Epstein <repstein at apple.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp
Log Message:
-----------
Cherry-pick be22708f4dbd. rdar://problem/107885426
Unreviewed build fix. rdar://107885426
Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp:76:9: error: value of type 'WebKit::RemoteScrollingCoordinatorProxy' is not contextually convertible to 'bool'
Canonical link: https://commits.webkit.org/259548.677@safari-7615-branch
Canonical link: https://commits.webkit.org/259548.670@safari-7615.2.9.10-branch
Commit: 0434636ed95f505aeeae1ec16d205ca54eaa6375
https://github.com/WebKit/WebKit/commit/0434636ed95f505aeeae1ec16d205ca54eaa6375
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKWebGeolocationPolicyDeciderIOS.mm
Log Message:
-----------
Cherry-pick 14f467660549. rdar://problem/107352115
Regression(259658 at main) Geolocation permission prompt is no longer showing in modal view
https://bugs.webkit.org/show_bug.cgi?id=255133
rdar://107352115
Reviewed by Wenson Hsieh and Tim Horton.
Use the same view controller to present the prompt as the UIWebView code used to.
I have verified locally that this fixes the issue.
* Source/WebKit/UIProcess/ios/WKWebGeolocationPolicyDeciderIOS.mm:
(-[WKWebGeolocationPolicyDecider _executeNextChallenge]):
Canonical link: https://commits.webkit.org/262697@main
Identifier: 259548.671 at safari-7615.2.9.10-branch
Commit: b0daf7f0db3e799d10b7ab619e42efc53f850c36
https://github.com/WebKit/WebKit/commit/b0daf7f0db3e799d10b7ab619e42efc53f850c36
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-21 (Fri, 21 Apr 2023)
Changed paths:
M Source/WebKit/Shared/Cocoa/SandboxExtensionCocoa.mm
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Cherry-pick 2dbbdbf493db. rdar://problem/107723629
REGRESSION (iOS 16.4): Chrome crashes in WebBackForwardCache::takeSuspendedPage
https://bugs.webkit.org/show_bug.cgi?id=255102
rdar://107723629
Reviewed by Geoffrey Garen.
We recently added an AddAllowedFirstPartyForCookies async IPC call inside
WebProcessPool::processForNavigation(), right after we decide which process to
use. Because the IPC is async, this means that the selected process may crash
while we're waiting for a response. If this happens, we now call
processForNavigation() again to select a new process instead of trying to
proceed with the navigation with the terminated process.
Similarly, also make sure that the destination suspendedPage is still valid
after receiving the async IPC, in case the back/forward cache got cleared
during the IPC (e.g. due to memory pressure).
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::processForNavigation):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
Canonical link: https://commits.webkit.org/262709@main
Identifier: 259548.672 at safari-7615.2.9.10-branch
Commit: 0c62a343d51cb889661ea34936c82551967a4144
https://github.com/WebKit/WebKit/commit/0c62a343d51cb889661ea34936c82551967a4144
Author: Russell Epstein <repstein at apple.com>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-615.2.9.10.2
Identifier: 259548.673 at safari-7615.2.9.10-branch
Commit: ccdecd09e78188e234f910b89cd36264be57ed76
https://github.com/WebKit/WebKit/commit/ccdecd09e78188e234f910b89cd36264be57ed76
Author: Dan Glastonbury <djg at apple.com>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm
Log Message:
-----------
Cherry-pick 4aa8750579fb. rdar://problem/106964250
[ANGLE] UBO convert only whole block
rdar://106964250
Reviewed by Dean Jackson.
OpenGL doesn't guarantee that the buffer backing uniform blocks needs to be a
multiple of the block size. When converting OpenGL layout blocks to Metal
layout, ConvertUniformBufferData is rounding up the size of the backing buffer
to a multiple of the block size which leads to reading out of bounds.
To ensure we don't read outside the source buffer, this change replaces calls to
`memcpy` with `memcpy_guarded` which accepts a pointer to the limit of available
data and copies as much data as is available, writing zeroes for any unavailable
amount.
Conversion of bools didn't use memcpy, so the raw pointer is checked against
maxSrcPtr and only dereferenced if valid, otherwise zero is used.
This has been tested with ASan and UBSan enabled against the OpenGL dEQP tests
for Uniform Buffer Objects in ANGLE.
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ProgramMtl.mm:
Canonical link: https://commits.webkit.org/259548.667@safari-7615-branch
Identifier: 259548.674 at safari-7615.2.9.10-branch
Commit: b2800b173f1a0faf15fbcbd8596105b829c7b702
https://github.com/WebKit/WebKit/commit/b2800b173f1a0faf15fbcbd8596105b829c7b702
Author: Dan Robson <dan_robson at apple.com>
Date: 2023-04-25 (Tue, 25 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.10.3
Identifier: 259548.675 at safari-7615.2.9.10-branch
Commit: 77899089cc29f732abe2c258e19c970c0df364e3
https://github.com/WebKit/WebKit/commit/77899089cc29f732abe2c258e19c970c0df364e3
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-25 (Tue, 25 Apr 2023)
Changed paths:
A LayoutTests/fast/dom/object-load-pdf-data-url-expected.txt
A LayoutTests/fast/dom/object-load-pdf-data-url.html
M Source/WebCore/html/HTMLImageLoader.cpp
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
Log Message:
-----------
Cherry-pick 2c5a97645ec0. rdar://problem/107795151
Regression(255052 at main) Some streaming sites fail with an Embedded Video Sandbox Browser Error
https://bugs.webkit.org/show_bug.cgi?id=255900
<rdar://107795151>
Reviewed by Tim Horton and Darin Adler.
Some streaming sites fail with an Embedded Video Sandbox Browser Error since
255052 at main. 255052 at main seems correct per the specification but exposing the
"Chrome PDF Viewer" caused those sites to use a different code path for
validating iframe sandboxing.
They now try to load a data URL with a pdf MIME type inside an <object> element
and this was firing an error event on iOS, which was causing the site's logic
to display the sandbox error.
There is logic inside WebFrameLoaderClient::objectContentType() that is iOS
specific and causes us to try to load PDF as an image when inside an <object>.
This is because we don't support loadings such PDFs as plugins on iOS.
However, WebKit, in general, doesn't fire load/error events on <object> elements
that are loaded as plugins. It only does so when loading the <object> as an image.
I propose that we stop firing the load/error events for <object> loads of PDFs on
iOS, to make it look like they were loaded as plugins and avoid firing events that
could confuse sites such as the ones in the radar.
* LayoutTests/fast/dom/object-load-pdf-data-url-expected.txt: Added.
* LayoutTests/fast/dom/object-load-pdf-data-url.html: Added.
* Source/WebCore/html/HTMLImageLoader.cpp:
(WebCore::HTMLImageLoader::dispatchLoadEvent():
Canonical link: https://commits.webkit.org/263377@main
Identifier: 259548.676 at safari-7615.2.9.10-branch
Commit: 8db330e78c6665074e89979548d0ccf8a3f1cb24
https://github.com/WebKit/WebKit/commit/8db330e78c6665074e89979548d0ccf8a3f1cb24
Author: Dan Robson <dan_robson at apple.com>
Date: 2023-04-25 (Tue, 25 Apr 2023)
Changed paths:
A LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-pinch-out-expected.txt
A LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-pinch-out.html
M LayoutTests/css3/scroll-snap/ios/scroll-snap-mainframe-scroll-deceleration-with-obscured-inset.html
M LayoutTests/resources/ui-helper.js
M Source/WebCore/page/ChromeClient.h
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
M Source/WebCore/platform/ScrollableArea.cpp
M Source/WebCore/platform/ScrollableArea.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
M Source/WebKit/UIProcess/ios/WKScrollView.mm
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.h
Log Message:
-----------
Cherry-pick 2c37e8ef640d. rdar://problem/108008629
Apply patch. rdar://problem/108008629
Identifier: 259548.687 at safari-7615-branch
Identifier: 259548.677 at safari-7615.2.9.10-branch
Compare: https://github.com/WebKit/WebKit/compare/e2edd5feef73%5E...8db330e78c66
More information about the webkit-changes
mailing list