Branch: refs/heads/safari-7615.2.9.12-branch
Home: https://github.com/WebKit/WebKit
Commit: ab942171c8f6fcbd9157313a43b79798b5f6ae17
https://github.com/WebKit/WebKit/commit/ab942171c8f6fcbd9157313a43b79798b5f6ae17
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.12.1
Identifier: [email protected]
Commit: 6faea8d613f6ef91b5a839fc3ff715471c195784
https://github.com/WebKit/WebKit/commit/6faea8d613f6ef91b5a839fc3ff715471c195784
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: 5dfeccbaa554594dff70a73f7d372a7e0b0d1ffa
https://github.com/WebKit/WebKit/commit/5dfeccbaa554594dff70a73f7d372a7e0b0d1ffa
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: 1d42b7cbb09bf52b0f3dcb8df8bf574fdd82756a
https://github.com/WebKit/WebKit/commit/1d42b7cbb09bf52b0f3dcb8df8bf574fdd82756a
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: 0a18238c522043a0348e233d36466293beb332fa
https://github.com/WebKit/WebKit/commit/0a18238c522043a0348e233d36466293beb332fa
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: 67a2259acd794f0f8277b08fd6267872362f424e
https://github.com/WebKit/WebKit/commit/67a2259acd794f0f8277b08fd6267872362f424e
Author: Russell Epstein <[email protected]>
Date: 2023-04-24 (Mon, 24 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: [email protected]
Compare: https://github.com/WebKit/WebKit/compare/ab942171c8f6%5E...67a2259acd79
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
