[webkit-changes] [WebKit/WebKit] e55a17: Versioning.
Dan Robson
noreply at github.com
Thu May 18 16:08:58 PDT 2023
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 <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.11.1
Identifier: 259548.661 at safari-7615.2.9.11-branch
Commit: 860bb513f288aa22e08f4d0a33b26b610494f58a
https://github.com/WebKit/WebKit/commit/860bb513f288aa22e08f4d0a33b26b610494f58a
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 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 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.663 at safari-7615-branch
Identifier: 259548.662 at safari-7615.2.9.11-branch
Commit: 60f149edb00d0ce5fbdc32d934e8a74b4cc247f5
https://github.com/WebKit/WebKit/commit/60f149edb00d0ce5fbdc32d934e8a74b4cc247f5
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 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: 259548.662 at safari-7615.2.9.10-branch
Identifier: 259548.663 at safari-7615.2.9.11-branch
Commit: 5fc5eeaeb0fbdb4c08003f43e2903b091238fb01
https://github.com/WebKit/WebKit/commit/5fc5eeaeb0fbdb4c08003f43e2903b091238fb01
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.664 at safari-7615.2.9.11-branch
Commit: 0778b6f02b83590a85316d2b3651c0c253399b4e
https://github.com/WebKit/WebKit/commit/0778b6f02b83590a85316d2b3651c0c253399b4e
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.665 at safari-7615.2.9.11-branch
Commit: 79cf9f653868046b35735823b1ba8cc0e2fe5c47
https://github.com/WebKit/WebKit/commit/79cf9f653868046b35735823b1ba8cc0e2fe5c47
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.666 at safari-7615.2.9.11-branch
Commit: 67fde8264a914c4fff7432d6dc26438eda27ae0f
https://github.com/WebKit/WebKit/commit/67fde8264a914c4fff7432d6dc26438eda27ae0f
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.667 at safari-7615.2.9.11-branch
Commit: f37823604606d5764edbfe776ef0d00cd823aa69
https://github.com/WebKit/WebKit/commit/f37823604606d5764edbfe776ef0d00cd823aa69
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.668@safari-7615.2.9.11-branch
Commit: 002e7982eb3db52a345076315cd254bd548f67dc
https://github.com/WebKit/WebKit/commit/002e7982eb3db52a345076315cd254bd548f67dc
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.669 at safari-7615.2.9.11-branch
Commit: aee8e12e83c351154a6bd6fc0e1257229c1460b5
https://github.com/WebKit/WebKit/commit/aee8e12e83c351154a6bd6fc0e1257229c1460b5
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.670 at safari-7615.2.9.11-branch
Commit: 0dca9d5e0965b02a16e6ccf3244d212e9cb3d513
https://github.com/WebKit/WebKit/commit/0dca9d5e0965b02a16e6ccf3244d212e9cb3d513
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-7615.2.9.11.2
Identifier: 259548.671 at safari-7615.2.9.11-branch
Commit: 51f8c5ae49bb762c8e24a478125f28399f546764
https://github.com/WebKit/WebKit/commit/51f8c5ae49bb762c8e24a478125f28399f546764
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.672 at safari-7615.2.9.11-branch
Commit: c536ae1b17bf20963f0821be06fd093f307088ce
https://github.com/WebKit/WebKit/commit/c536ae1b17bf20963f0821be06fd093f307088ce
Author: Russell Epstein <repstein at apple.com>
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/259548.673@safari-7615.2.9.11-branch
Commit: 727b595a17c52cd3b074bf7c1d39483c24adf84a
https://github.com/WebKit/WebKit/commit/727b595a17c52cd3b074bf7c1d39483c24adf84a
Author: Jer Noble <jer.noble at apple.com>
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/259548.674@safari-7615.2.9.11-branch
Commit: 31cc4c6fdeeb1b79f84de819569de551851050df
https://github.com/WebKit/WebKit/commit/31cc4c6fdeeb1b79f84de819569de551851050df
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-05-02 (Tue, 02 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: 259548.675 at safari-7615.2.9.11-branch
Commit: 801e05f5cf7ea0848484eeff31200ab881ec2613
https://github.com/WebKit/WebKit/commit/801e05f5cf7ea0848484eeff31200ab881ec2613
Author: Chris Dumez <cdumez at apple.com>
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: 259548.676 at safari-7615.2.9.11-branch
Commit: 86cc79d3c3e138ccd318e50e01032cb142f9b324
https://github.com/WebKit/WebKit/commit/86cc79d3c3e138ccd318e50e01032cb142f9b324
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-05-04 (Thu, 04 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.11.5
Identifier: 259548.677 at safari-7615.2.9.11-branch
Commit: cfabbe9b2415172ad893edfa91eb1034c1a11b40
https://github.com/WebKit/WebKit/commit/cfabbe9b2415172ad893edfa91eb1034c1a11b40
Author: Dan Robson <dan_robson at apple.com>
Date: 2023-05-10 (Wed, 10 May 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.11.6
Identifier: 259548.678 at safari-7615.2.9.11-branch
Compare: https://github.com/WebKit/WebKit/compare/e55a17a9b432%5E...cfabbe9b2415
More information about the webkit-changes
mailing list