[webkit-changes] [WebKit/WebKit] 2b986c: Versioning.
Chris Dumez
noreply at github.com
Wed Oct 25 14:27:51 PDT 2023
Branch: refs/heads/safari-7615.2.9.13-branch
Home: https://github.com/WebKit/WebKit
Commit: 2b986ce0b2551a3c14b88645cb8684bdfa8bb89d
https://github.com/WebKit/WebKit/commit/2b986ce0b2551a3c14b88645cb8684bdfa8bb89d
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.13.1
Identifier: 259548.661 at safari-7615.2.9.13-branch
Commit: a9dcf3bfdd0ef48ced5267c9f65f833d6f9dc4b7
https://github.com/WebKit/WebKit/commit/a9dcf3bfdd0ef48ced5267c9f65f833d6f9dc4b7
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.662 at safari-7615.2.9.13-branch
Commit: a20b8eb0f79f94e93aeac2af3d9373385761c10e
https://github.com/WebKit/WebKit/commit/a20b8eb0f79f94e93aeac2af3d9373385761c10e
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.663 at safari-7615.2.9.13-branch
Commit: 487d3d08391c582321d5548861c921a57527b008
https://github.com/WebKit/WebKit/commit/487d3d08391c582321d5548861c921a57527b008
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.664 at safari-7615.2.9.13-branch
Commit: 45ef58bc3791e46362775bbce9b9ea5962ca2452
https://github.com/WebKit/WebKit/commit/45ef58bc3791e46362775bbce9b9ea5962ca2452
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.665 at safari-7615.2.9.13-branch
Compare: https://github.com/WebKit/WebKit/compare/2b986ce0b255%5E...45ef58bc3791
More information about the webkit-changes
mailing list