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 <[email protected]>
Date: 2023-04-20 (Thu, 20 Apr 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7615.2.9.13.1
Identifier: [email protected]
Commit: a9dcf3bfdd0ef48ced5267c9f65f833d6f9dc4b7
https://github.com/WebKit/WebKit/commit/a9dcf3bfdd0ef48ced5267c9f65f833d6f9dc4b7
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: a20b8eb0f79f94e93aeac2af3d9373385761c10e
https://github.com/WebKit/WebKit/commit/a20b8eb0f79f94e93aeac2af3d9373385761c10e
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: 487d3d08391c582321d5548861c921a57527b008
https://github.com/WebKit/WebKit/commit/487d3d08391c582321d5548861c921a57527b008
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: 45ef58bc3791e46362775bbce9b9ea5962ca2452
https://github.com/WebKit/WebKit/commit/45ef58bc3791e46362775bbce9b9ea5962ca2452
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]
Compare: https://github.com/WebKit/WebKit/compare/2b986ce0b255%5E...45ef58bc3791
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
