Branch: refs/heads/safari-7615.2.9.11-branch
Home: https://github.com/WebKit/WebKit
Commit: e55a17a9b4328d779eafb230ba3e00f915e02db9
https://github.com/WebKit/WebKit/commit/e55a17a9b4328d779eafb230ba3e00f915e02db9
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.11.1
Identifier: [email protected]
Commit: 860bb513f288aa22e08f4d0a33b26b610494f58a
https://github.com/WebKit/WebKit/commit/860bb513f288aa22e08f4d0a33b26b610494f58a
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 54bbd87350b3. rdar://problem/107538083
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: 259548.663@safari-7615-branch
Identifier: [email protected]
Commit: 60f149edb00d0ce5fbdc32d934e8a74b4cc247f5
https://github.com/WebKit/WebKit/commit/60f149edb00d0ce5fbdc32d934e8a74b4cc247f5
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 855ddac11e97. rdar://problem/107756651
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]
Identifier: [email protected]
Commit: 5fc5eeaeb0fbdb4c08003f43e2903b091238fb01
https://github.com/WebKit/WebKit/commit/5fc5eeaeb0fbdb4c08003f43e2903b091238fb01
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: 0778b6f02b83590a85316d2b3651c0c253399b4e
https://github.com/WebKit/WebKit/commit/0778b6f02b83590a85316d2b3651c0c253399b4e
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: 79cf9f653868046b35735823b1ba8cc0e2fe5c47
https://github.com/WebKit/WebKit/commit/79cf9f653868046b35735823b1ba8cc0e2fe5c47
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: 67fde8264a914c4fff7432d6dc26438eda27ae0f
https://github.com/WebKit/WebKit/commit/67fde8264a914c4fff7432d6dc26438eda27ae0f
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: f37823604606d5764edbfe776ef0d00cd823aa69
https://github.com/WebKit/WebKit/commit/f37823604606d5764edbfe776ef0d00cd823aa69
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: 002e7982eb3db52a345076315cd254bd548f67dc
https://github.com/WebKit/WebKit/commit/002e7982eb3db52a345076315cd254bd548f67dc
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: aee8e12e83c351154a6bd6fc0e1257229c1460b5
https://github.com/WebKit/WebKit/commit/aee8e12e83c351154a6bd6fc0e1257229c1460b5
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: 0dca9d5e0965b02a16e6ccf3244d212e9cb3d513
https://github.com/WebKit/WebKit/commit/0dca9d5e0965b02a16e6ccf3244d212e9cb3d513
Author: Russell Epstein <[email protected]>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.11.2
Identifier: [email protected]
Commit: 51f8c5ae49bb762c8e24a478125f28399f546764
https://github.com/WebKit/WebKit/commit/51f8c5ae49bb762c8e24a478125f28399f546764
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: c536ae1b17bf20963f0821be06fd093f307088ce
https://github.com/WebKit/WebKit/commit/c536ae1b17bf20963f0821be06fd093f307088ce
Author: Russell Epstein <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.11.3
Canonical link: https://commits.webkit.org/[email protected]
Commit: 727b595a17c52cd3b074bf7c1d39483c24adf84a
https://github.com/WebKit/WebKit/commit/727b595a17c52cd3b074bf7c1d39483c24adf84a
Author: Jer Noble <[email protected]>
Date: 2023-04-27 (Thu, 27 Apr 2023)
Changed paths:
M Source/WebKit/WebProcess/GPU/media/cocoa/VideoLayerRemoteCocoa.mm
Log Message:
-----------
Cherry-pick 8a95a469c00c. rdar://problem/108109357
[Cocoa] Extra transform left on video layer when UI-side compositing is
disabled
https://bugs.webkit.org/show_bug.cgi?id=256027
rdar://108109357
Reviewed by Eric Carlson.
In -resolveBounds, we bail out early if the WKVideoLayerRemote has the
correct bounds and has
a identity affineTransform. But in -layoutSublayers we apply the transform
directly to the
videoLayer, rather than the WKVideoLayerRemote itself, so this check will
always succeed.
Leaving the transformation in place _should_ have no perceivable side
effects. However power
testing has revealed that in some circumstances, this layer change may
result in excess power
use when displaying video in fullscreen mode.
* Source/WebKit/WebProcess/GPU/media/cocoa/VideoLayerRemoteCocoa.mm:
(-[WKVideoLayerRemote resolveBounds]):
Canonical link: https://commits.webkit.org/263456@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 31cc4c6fdeeb1b79f84de819569de551851050df
https://github.com/WebKit/WebKit/commit/31cc4c6fdeeb1b79f84de819569de551851050df
Author: Myah Cobbs <[email protected]>
Date: 2023-05-02 (Tue, 02 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: [email protected]
Commit: 801e05f5cf7ea0848484eeff31200ab881ec2613
https://github.com/WebKit/WebKit/commit/801e05f5cf7ea0848484eeff31200ab881ec2613
Author: Chris Dumez <[email protected]>
Date: 2023-05-02 (Tue, 02 May 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/AuxiliaryProcessProxyCocoa.mm
M Source/WebKit/UIProcess/Cocoa/XPCConnectionTerminationWatchdog.h
M Source/WebKit/UIProcess/Cocoa/XPCConnectionTerminationWatchdog.mm
Log Message:
-----------
Cherry-pick 256bf3a7dde7. rdar://problem/108674417
Use the XPCConnectionTerminationWatchdog on macOS too
https://bugs.webkit.org/show_bug.cgi?id=256096
Reviewed by Ben Nham.
Use the XPCConnectionTerminationWatchdog on macOS too now that process
suspension is no longer specific to iOS.
* Source/WebKit/UIProcess/Cocoa/AuxiliaryProcessProxyCocoa.mm:
(WebKit::AuxiliaryProcessProxy::platformStartConnectionTerminationWatchdog):
* Source/WebKit/UIProcess/Cocoa/XPCConnectionTerminationWatchdog.h:
* Source/WebKit/UIProcess/Cocoa/XPCConnectionTerminationWatchdog.mm:
(WebKit::XPCConnectionTerminationWatchdog::XPCConnectionTerminationWatchdog):
Canonical link: https://commits.webkit.org/263514@main
Identifier: [email protected]
Commit: 86cc79d3c3e138ccd318e50e01032cb142f9b324
https://github.com/WebKit/WebKit/commit/86cc79d3c3e138ccd318e50e01032cb142f9b324
Author: Myah Cobbs <[email protected]>
Date: 2023-05-04 (Thu, 04 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.11.5
Identifier: [email protected]
Commit: cfabbe9b2415172ad893edfa91eb1034c1a11b40
https://github.com/WebKit/WebKit/commit/cfabbe9b2415172ad893edfa91eb1034c1a11b40
Author: Dan Robson <[email protected]>
Date: 2023-05-10 (Wed, 10 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.11.6
Identifier: [email protected]
Compare: https://github.com/WebKit/WebKit/compare/e55a17a9b432%5E...cfabbe9b2415
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
