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 <[email protected]>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.10.1
Identifier: [email protected]
Commit: 855ddac11e97ef528a4778ebb475f947fed22957
https://github.com/WebKit/WebKit/commit/855ddac11e97ef528a4778ebb475f947fed22957
Author: Brent Fulgham <[email protected]>
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: [email protected]
Commit: a0f1bd6fb9c48974796a41d94da7987a40565719
https://github.com/WebKit/WebKit/commit/a0f1bd6fb9c48974796a41d94da7987a40565719
Author: Simon Fraser <[email protected]>
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: [email protected]
Commit: fc54789c41deba74cfa75655774969b51b5083b0
https://github.com/WebKit/WebKit/commit/fc54789c41deba74cfa75655774969b51b5083b0
Author: Chris Dumez <[email protected]>
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@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@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@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@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: [email protected]
Commit: 4e700d7ec6105fae4486f2d7d648116d7d9fc334
https://github.com/WebKit/WebKit/commit/4e700d7ec6105fae4486f2d7d648116d7d9fc334
Author: Wenson Hsieh <[email protected]>
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@safari-7615-branch
Identifier: [email protected]
Commit: 302eb8deec34f9574877cc84dd3c7d8cf544b0c3
https://github.com/WebKit/WebKit/commit/302eb8deec34f9574877cc84dd3c7d8cf544b0c3
Author: Simon Fraser <[email protected]>
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@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@safari-7615-branch
Identifier: [email protected]
Commit: fd926e8b1a81b49adf6b554b5523b0b635a9c6f6
https://github.com/WebKit/WebKit/commit/fd926e8b1a81b49adf6b554b5523b0b635a9c6f6
Author: Wenson Hsieh <[email protected]>
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@safari-7615-branch
Identifier: [email protected]
Commit: 4a74cdae1f42fdcac74b5674b6440b64beb64b16
https://github.com/WebKit/WebKit/commit/4a74cdae1f42fdcac74b5674b6440b64beb64b16
Author: Wenson Hsieh <[email protected]>
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@safari-7615-branch
Identifier: [email protected]
Commit: cbb31e0324a839ea51f4f4fa355cc46b16af9f2f
https://github.com/WebKit/WebKit/commit/cbb31e0324a839ea51f4f4fa355cc46b16af9f2f
Author: Jer Noble <[email protected]>
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@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: [email protected]
Commit: e66b99f0ed5b43e382617ff222596e3ae4b2348e
https://github.com/WebKit/WebKit/commit/e66b99f0ed5b43e382617ff222596e3ae4b2348e
Author: Russell Epstein <[email protected]>
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/[email protected]
Commit: 0434636ed95f505aeeae1ec16d205ca54eaa6375
https://github.com/WebKit/WebKit/commit/0434636ed95f505aeeae1ec16d205ca54eaa6375
Author: Chris Dumez <[email protected]>
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@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: [email protected]
Commit: b0daf7f0db3e799d10b7ab619e42efc53f850c36
https://github.com/WebKit/WebKit/commit/b0daf7f0db3e799d10b7ab619e42efc53f850c36
Author: Chris Dumez <[email protected]>
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: [email protected]
Commit: 0c62a343d51cb889661ea34936c82551967a4144
https://github.com/WebKit/WebKit/commit/0c62a343d51cb889661ea34936c82551967a4144
Author: Russell Epstein <[email protected]>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-615.2.9.10.2
Identifier: [email protected]
Commit: ccdecd09e78188e234f910b89cd36264be57ed76
https://github.com/WebKit/WebKit/commit/ccdecd09e78188e234f910b89cd36264be57ed76
Author: Dan Glastonbury <[email protected]>
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: [email protected]
Commit: b2800b173f1a0faf15fbcbd8596105b829c7b702
https://github.com/WebKit/WebKit/commit/b2800b173f1a0faf15fbcbd8596105b829c7b702
Author: Dan Robson <[email protected]>
Date: 2023-04-25 (Tue, 25 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.10.3
Identifier: [email protected]
Commit: 77899089cc29f732abe2c258e19c970c0df364e3
https://github.com/WebKit/WebKit/commit/77899089cc29f732abe2c258e19c970c0df364e3
Author: Chris Dumez <[email protected]>
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@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@main. 255052@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: [email protected]
Commit: 8db330e78c6665074e89979548d0ccf8a3f1cb24
https://github.com/WebKit/WebKit/commit/8db330e78c6665074e89979548d0ccf8a3f1cb24
Author: Dan Robson <[email protected]>
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@safari-7615-branch
Identifier: [email protected]
Compare: https://github.com/WebKit/WebKit/compare/e2edd5feef73%5E...8db330e78c66
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
