[webkit-changes] [WebKit/WebKit] 73eb68: Crash under PlatformCALayerRemote::recursiveBuildT...
mwyrzykowski
noreply at github.com
Wed Oct 25 12:57:05 PDT 2023
Branch: refs/heads/safari-7616-branch
Home: https://github.com/WebKit/WebKit
Commit: 73eb68ead0fcb51147823c80d8a9f3866f883487
https://github.com/WebKit/WebKit/commit/73eb68ead0fcb51147823c80d8a9f3866f883487
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
A LayoutTests/compositing/reflections/video-mask-reflection-crash-expected.txt
A LayoutTests/compositing/reflections/video-mask-reflection-crash.html
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
Log Message:
-----------
Crash under PlatformCALayerRemote::recursiveBuildTransaction()
https://bugs.webkit.org/show_bug.cgi?id=259607
rdar://32076163
Reviewed by Tim Horton.
In some scenarios, we can end up with a PlatformCALayerRemote which remains in a sublayer list after
being deleted.
The testcase has a <video> which toggles from composited to non-composited and back. This video has
a mask, and a reflection. The reflection RendeLayer (the RenderReplica's layer) remains composited.
When this happens, the masks layer's clone remains in the sublayer list of the "replica flattening"
layer, but it's owning reference, in the LayerClones struct owned by the video layer, went away when
the video stopped being composited temporarily. The real issue is that we failed to rebuild the
sublayer list of the "replica flattening" layer in this case, so make sure we trigger that.
* LayoutTests/compositing/reflections/video-mask-reflection-crash-expected.txt: Added.
* LayoutTests/compositing/reflections/video-mask-reflection-crash.html: Added.
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::setReplicatedLayer):
Canonical link: https://commits.webkit.org/265870.224@safari-7616-branch
Commit: e2098361872d11a0a6bd95b9cc259c549236330f
https://github.com/WebKit/WebKit/commit/e2098361872d11a0a6bd95b9cc259c549236330f
Author: Keith Miller <keith_miller at apple.com>
Date: 2023-07-30 (Sun, 30 Jul 2023)
Changed paths:
M Source/JavaScriptCore/bytecode/SpeculatedType.cpp
Log Message:
-----------
Try workaround top-crasher by not inspecting structures that point into obviously bad memory
https://bugs.webkit.org/show_bug.cgi?id=259615
rdar://112429409
Reviewed by Yusuke Suzuki and Mark Lam.
We see a lot of crashes here where the structure appears to be in the Gigacage. This is obviously wrong, so for now let's try not to look at those structures.
* Source/JavaScriptCore/bytecode/SpeculatedType.cpp:
(JSC::speculationFromCell):
Canonical link: https://commits.webkit.org/265870.225@safari-7616-branch
Commit: 32de82e2afddd1ffd624d5b2863e8ea7160b3873
https://github.com/WebKit/WebKit/commit/32de82e2afddd1ffd624d5b2863e8ea7160b3873
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-07-30 (Sun, 30 Jul 2023)
Changed paths:
M Source/WebCore/Configurations/WebCore.xcconfig
Log Message:
-----------
Cherry-pick 4ef6f54430f8. rdar://problem/113041105
[macOS] Temporarily disable JPEG XL on older OSes until we can get https://bugs.webkit.org/show_bug.cgi?id=259587 ironed out
https://bugs.webkit.org/show_bug.cgi?id=259603
rdar://113041105
Reviewed by Tim Horton.
This path is producing images that are garbled. Temporarily disable the feature until we can fix that.
* Source/WebCore/Configurations/WebCore.xcconfig:
Canonical link: https://commits.webkit.org/266408@main
Canonical link: https://commits.webkit.org/265870.226@safari-7616-branch
Commit: c347ada97e2e22e30341dce5e418d752c77867ff
https://github.com/WebKit/WebKit/commit/c347ada97e2e22e30341dce5e418d752c77867ff
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-07-31 (Mon, 31 Jul 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: 265870.227 at safari-7616-branch
Commit: dfad84e0d9b120c0b41093f6f93d7931ef6ab6c4
https://github.com/WebKit/WebKit/commit/dfad84e0d9b120c0b41093f6f93d7931ef6ab6c4
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-07-31 (Mon, 31 Jul 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.1
Identifier: 265870.228 at safari-7616-branch
Commit: e633a9de382d9521d6a77232d1a30ee658f6578d
https://github.com/WebKit/WebKit/commit/e633a9de382d9521d6a77232d1a30ee658f6578d
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
A LayoutTests/http/tests/images/repaint-garbled-expected.html
A LayoutTests/http/tests/images/repaint-garbled.html
A LayoutTests/http/tests/images/resources/green-313x313.jxl
M Source/WebCore/platform/graphics/cg/ImageBackingStoreCG.cpp
Log Message:
-----------
[macOS Downlevels] AVIF and JPEG XL images can get corrupted
https://bugs.webkit.org/show_bug.cgi?id=259698
<rdar://problem/113007909>
Reviewed by Said Abou-Hallawa.
When we create a `NativeImage`, we call `ImageSource::frameAtIndexCacheIfNeeded()` with
a caching mode of `MetadataAndImage`. This does 2 things:
1. `auto platformImage = m_decoder->createFrameImageAtIndex(index, subsamplingLevelValue, decodingOptions);`
2. `cachePlatformImageAtIndex(WTFMove(platformImage), index, subsamplingLevelValue, DecodingOptions(DecodingMode::Synchronous));`
ImageSource owns its own cache of `Vector<ImageFrame, 1> m_frames;` whereas
`ScalableImageDecoder` owns its own
`Vector<ScalableImageDecoderFrame, 1> m_frameBufferCache`. Therefore, the output of
`createFrameImageAtIndex()` may be expected to outlive the `ImageDecoder` it came from.
However, `createFrameImageAtIndex()` indirectly calls into `ImageBackingStore::image()`
which creates the `CGImage` with a `CGDataProvider` that points into the
`ImageBackingStore`, which is owned by the `m_frameBufferCache` which is owned by the
`ScalableImageDecoder`. So, when the `ImageSource` destroys its `ImageDecoder`, it blows
away the contents of the `CGImage`s being cached, but the images themselves live on
inside the `ImageSource` itself. That leads to this kind of corruption.
The solution is to make the `CGImage` retain its backing data.
* LayoutTests/http/tests/images/repaint-garbled-expected.html: Added.
* LayoutTests/http/tests/images/repaint-garbled.html: Added.
* LayoutTests/http/tests/images/resources/green-313x313.jxl: Added.
* Source/WebCore/platform/graphics/cg/ImageBackingStoreCG.cpp:
(WebCore::ImageBackingStore::image const):
Canonical link: https://commits.webkit.org/265870.229@safari-7616-branch
Commit: c6e93e4405155b7e156cae76bab89851ce570641
https://github.com/WebKit/WebKit/commit/c6e93e4405155b7e156cae76bab89851ce570641
Author: Russell Epstein <repstein at apple.com>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/WebCore/Configurations/WebCore.xcconfig
Log Message:
-----------
Revert "Cherry-pick 4ef6f54430f8. rdar://problem/113041105"
This reverts commit 32de82e2afddd1ffd624d5b2863e8ea7160b3873,
re-enabling JPEGXL on older macOS versions.
Canonical link: https://commits.webkit.org/265870.230@safari-7616-branch
Commit: bb9c7e0fd205967d92f32687c72577a81f977eef
https://github.com/WebKit/WebKit/commit/bb9c7e0fd205967d92f32687c72577a81f977eef
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2023-08-03 (Thu, 03 Aug 2023)
Changed paths:
M Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp
M Source/WebCore/Modules/applepay/ApplePaySetup.cpp
M Source/WebCore/Modules/applepay/PaymentCoordinator.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
Log Message:
-----------
Ensure -[PKPaymentRequest originatingURL] is always set to the top-level document URL
https://bugs.webkit.org/show_bug.cgi?id=259667
rdar://113143083
Reviewed by Andy Estes.
We support Apple Pay on cross-origin iframes following 262616 at main, but
since we are plumbing the iframe domain rather than that of the parent
document embedding said iframe, we lose some Apple Pay domain validation
and abuse detection mitigations.
In this patch, we preserve our existing security mitigations by passing
the top-level domain to `-[PKPaymentRequest setOriginatingURL:]`.
This change also aligns ourselves to the existing shipping model for
payment session domain reporting in iOS 16.
Note that this patch necessitates that a website provide the top level
domain in its merchant session, i.e. "you can iFrame in Apple Pay, but
your merchant session must use the top-level domain". This is a
pre-existing invariant in PassKit, and this commit aligns WebKit in the
same direction.
* Source/WebCore/Modules/applepay-ams-ui/ApplePayAMSUIPaymentHandler.cpp:
(WebCore::ApplePayAMSUIPaymentHandler::show):
* Source/WebCore/Modules/applepay/ApplePaySetup.cpp:
(WebCore::ApplePaySetup::begin):
* Source/WebCore/Modules/applepay/PaymentCoordinator.cpp:
(WebCore::PaymentCoordinator::beginPaymentSession):
* Source/WebCore/page/Page.cpp:
(WebCore::Page::startApplePayAMSUISession):
* Source/WebCore/page/Page.h:
Canonical link: https://commits.webkit.org/265870.231@safari-7616-branch
Commit: 24db827e0429f1a2729d4e7c1905d94af0c33b5d
https://github.com/WebKit/WebKit/commit/24db827e0429f1a2729d4e7c1905d94af0c33b5d
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Source/WTF/wtf/dtoa/utils.h
Log Message:
-----------
Cherry-pick 9bd05bda44cc. rdar://problem/113341253
dtoa/utils.h doesn't parse after recent SDK changes
https://bugs.webkit.org/show_bug.cgi?id=259789
rdar://113341253
Reviewed by Wenson Hsieh.
* Source/WTF/wtf/dtoa/utils.h:
Recent SDK changes resulted in CoreUtils headers getting imported into
translation units (OutputContext.mm) that also import `dtoa/utils.h`.
The aforementioned CoreUtils headers have long had macros Min() and Max(),
which conflict with our template functions' definitions, and make utils.h
fail to parse.
As a quick workaround, undefine the rogue macros before our Min() and Max().
Canonical link: https://commits.webkit.org/266550@main
Canonical link: https://commits.webkit.org/265870.232@safari-7616-branch
Commit: 0b840390bc5209efeb85108cc03510dc4cbda8f5
https://github.com/WebKit/WebKit/commit/0b840390bc5209efeb85108cc03510dc4cbda8f5
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Source/WTF/wtf/SHA1.h
Log Message:
-----------
Cherry-pick 9809c1a27c82. rdar://problem/113360320
SHA1.h doesn't parse after recent SDK changes
https://bugs.webkit.org/show_bug.cgi?id=259800
rdar://113360320
Reviewed by Megan Gardner and Wenson Hsieh.
* Source/WTF/wtf/SHA1.h:
Recent SDK changes resulted in CoreUtils headers getting imported into
translation units (MediaPlayerPrivateWebM.mm) that also import `SHA1.h`.
The aforementioned CoreUtils headers have long had a macro SHA1(),
which conflict with our template functions' definitions, and make SHA1.h
fail to parse.
As a quick workaround, undefine the rogue macros before our SHA1 class.
Canonical link: https://commits.webkit.org/266559@main
Canonical link: https://commits.webkit.org/265870.233@safari-7616-branch
Commit: 9052a0395b9b28a90c6c1df153f262a04e1952e9
https://github.com/WebKit/WebKit/commit/9052a0395b9b28a90c6c1df153f262a04e1952e9
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm
Log Message:
-----------
heap-use-after-free in WebKit::AudioSessionRoutingArbitratorProxy::logger
https://bugs.webkit.org/show_bug.cgi?id=259836
rdar://112774591
Reviewed by Simon Fraser.
Move the ALWAYS_LOG() inside the `if (weakThis)` scope since this macro will
call `this->logger()`.
* Source/WebKit/UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm:
(WebKit::AudioSessionRoutingArbitratorProxy::beginRoutingArbitrationWithCategory):
Canonical link: https://commits.webkit.org/265870.234@safari-7616-branch
Commit: bfc6efd0dc4e255c5df23be029608a4bbac75cbe
https://github.com/WebKit/WebKit/commit/bfc6efd0dc4e255c5df23be029608a4bbac75cbe
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M Source/WebKit/Shared/EditorState.cpp
Log Message:
-----------
REGRESSION: WebKit provides rectilinear selection rects for rotated text in images
https://bugs.webkit.org/show_bug.cgi?id=259888
rdar://113287677
Reviewed by Wenson Hsieh.
`EditorState::clipOwnedRectExtentsToNumericLimits` was erroneously converting some selection
geometries from quads to rects.
Fix by removing these conversions. Since `FloatQuad`s have no notion of validity, there is no
need to clip them to numeric limits.
* Source/WebKit/Shared/EditorState.cpp:
(WebKit::EditorState::clipOwnedRectExtentsToNumericLimits):
Canonical link: https://commits.webkit.org/265870.235@safari-7616-branch
Commit: bf54ee3c4df69257e2f88e40cf391a1d4323c550
https://github.com/WebKit/WebKit/commit/bf54ee3c4df69257e2f88e40cf391a1d4323c550
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M Source/WebCore/platform/mac/ScrollbarsControllerMac.mm
Log Message:
-----------
Use-after-free under WebCore::Scrollbar::supportsUpdateOnSecondaryThread()
https://bugs.webkit.org/show_bug.cgi?id=259890
rdar://113037440
Reviewed by Ryosuke Niwa.
Use a WeakPtr for _scrollbar instead of a raw pointer and add a null-check
in [WebScrollbarPartAnimation setCurrentProgress:].
* Source/WebCore/platform/mac/ScrollbarsControllerMac.mm:
(-[WebScrollbarPartAnimation setCurrentProgress:]):
(-[WebScrollerImpDelegate setUpAlphaAnimation:scrollerPainter:part:animateAlphaTo:duration:]):
(-[WebScrollerImpDelegate scrollerImp:animateUIStateTransitionWithDuration:]):
(-[WebScrollerImpDelegate scrollerImp:animateExpansionTransitionWithDuration:]):
Canonical link: https://commits.webkit.org/265870.236@safari-7616-branch
Commit: 76715edd316dd5825f4652180e6d0e0c93a4bae6
https://github.com/WebKit/WebKit/commit/76715edd316dd5825f4652180e6d0e0c93a4bae6
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp
M Source/WebCore/workers/service/ServiceWorkerGlobalScope.h
Log Message:
-----------
Potential use-after-free of the VM under ~FetchEvent()
https://bugs.webkit.org/show_bug.cgi?id=259896
rdar://113148936
Reviewed by Brent Fulgham.
The VM gets destroyed in between the call for WorkerGlobalScope::prepareForDestruction()
and the call for the WorkerGlobalScope destructor. The crash trace indicates that
the ServiceWorkerGlobalScope destructor destroys FetchEvent objects which end up needing
the VM in their destructor.
This is a speculative fix as I cannot reproduce the issue. Brady already imported the
test case at 266608 at main.
* Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:
(WebCore::ServiceWorkerGlobalScope::prepareForDestruction):
* Source/WebCore/workers/service/ServiceWorkerGlobalScope.h:
Canonical link: https://commits.webkit.org/265870.237@safari-7616-branch
Commit: 10b9fa4c73fa206dd1ed1cf52162a32fc49a6181
https://github.com/WebKit/WebKit/commit/10b9fa4c73fa206dd1ed1cf52162a32fc49a6181
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/platform/ios/WebAVPlayerController.h
M Source/WebCore/platform/ios/WebAVPlayerController.mm
Log Message:
-----------
Cherry-pick 078e59c40257. rdar://problem/113227148
[visionOS] Crash when entering fullscreen on vimeo.com
https://bugs.webkit.org/show_bug.cgi?id=259785
rdar://113227148
Reviewed by Richard Robinson.
Recent changes in AVKit result in an underlying framework relying on
`-[AVMediaSelectionOption displayName]`, which is in the public interface.
Fix the crash by implementing `-displayName` on our "proxy" object, `WebAVMediaSelectionOption`.
* Source/WebCore/platform/ios/WebAVPlayerController.h:
* Source/WebCore/platform/ios/WebAVPlayerController.mm:
(-[WebAVMediaSelectionOption displayName]):
`displayName` is intended to be localized, so simply return the existing localized property.
Canonical link: https://commits.webkit.org/266548@main
Canonical link: https://commits.webkit.org/265870.238@safari-7616-branch
Commit: afe4be33ba523a947e64d9d651f023acc59ceb2a
https://github.com/WebKit/WebKit/commit/afe4be33ba523a947e64d9d651f023acc59ceb2a
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformLegacy.h
M Source/WTF/wtf/PlatformOS.h
Log Message:
-----------
Cherry-pick 4fdd040c5aaf. rdar://problem/113232427
Migrate from TARGET_OS_XR to TARGET_OS_VISION
https://bugs.webkit.org/show_bug.cgi?id=259782
<radar://113232427>
Reviewed by Richard Robinson and Tim Horton.
TARGET_OS_VISION is preferred over TARGET_OS_XR and automated
tooling is requesting we change to the new name.
* Source/WTF/wtf/PlatformLegacy.h:
* Source/WTF/wtf/PlatformOS.h:
Canonical link: https://commits.webkit.org/266554@main
Canonical link: https://commits.webkit.org/265870.239@safari-7616-branch
Commit: 178feb70a0e1b3c0ac3f0d2f0e3fab4489fb0ed8
https://github.com/WebKit/WebKit/commit/178feb70a0e1b3c0ac3f0d2f0e3fab4489fb0ed8
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/DerivedSources-input.xcfilelist
M Source/WebCore/DerivedSources.make
M Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.css
M Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.js
A Source/WebCore/Modules/modern-media-controls/controls/vision-volume-container.js
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick e4772fad1ca2. rdar://problem/113243353
Media Controls: Volume slider should always show if we have enough room
https://bugs.webkit.org/show_bug.cgi?id=259721
rdar://113243353
Reviewed by Dean Jackson.
On visionOS, the volume slider should always show within inline video, if there is enough room.
* Source/WebCore/DerivedSources-input.xcfilelist:
* Source/WebCore/DerivedSources.make:
* Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.css:
(.media-controls.vision > .controls-bar.top-right,):
(.media-controls.vision > .controls-bar.top-right):
(.media-controls.vision .controls-bar.simple-layout .volume-container > .slider.vision.volume,):
(.media-controls.vision .controls-bar.simple-layout.top-right > .overflow):
(.media-controls.vision .volume-container):
(.media-controls.vision .volume-container > .mute.bar):
(.media-controls.vision:not(.audio) .volume-container > .background-tint > .blur,):
(.media-controls.vision.fullscreen > .controls-bar.top-right,): Deleted.
(.media-controls.vision.fullscreen > .controls-bar.top-right): Deleted.
(.media-controls.vision .controls-bar.simple-layout > *:not(.background-tint)): Deleted.
(.media-controls.vision:not(.audio) button > .background-tint > .blur): Deleted.
* Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.js:
(VisionMediaControls.prototype._createControls):
(VisionMediaControls.prototype._performVolumeContainerLayout):
(VisionMediaControls.prototype._performTopRightControlsBarLayout):
(VisionInlineMediaControls.prototype._createControls):
(VisionInlineMediaControls.prototype._performLayout):
(VisionInlineMediaControls.prototype._topRightControlsBarChildren):
(VisionInlineMediaControls.prototype._performVolumeContainerLayout):
(VisionFullscreenMediaControls.prototype._createControls):
(VisionFullscreenMediaControls.prototype._performVolumeContainerLayout):
(VisionFullscreenMediaControls.prototype._topRightControlsBarChildren):
* Source/WebCore/Modules/modern-media-controls/controls/vision-volume-container.js: Added.
(VolumeContainer.prototype.get children):
(VolumeContainer.prototype.set children):
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/266566@main
Canonical link: https://commits.webkit.org/265870.240@safari-7616-branch
Commit: 62720b4b0cbca7e23658f809d3e70426c5839c4e
https://github.com/WebKit/WebKit/commit/62720b4b0cbca7e23658f809d3e70426c5839c4e
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick 17723aacd5f5. rdar://problem/112866983
Media: Update fullscreen controls for 1360 PPM
https://bugs.webkit.org/show_bug.cgi?id=259845
rdar://112866983
Reviewed by Eric Carlson.
The visionOS media controls are too small when in
fullscreen.
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
Canonical link: https://commits.webkit.org/266607@main
Canonical link: https://commits.webkit.org/265870.241@safari-7616-branch
Commit: 2d4f1dbe34ae60d876c0e9c0e1d4f2a6e96f7783
https://github.com/WebKit/WebKit/commit/2d4f1dbe34ae60d876c0e9c0e1d4f2a6e96f7783
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/platform/ios/UserAgentIOS.mm
Log Message:
-----------
Cherry-pick 15c863e9164b. rdar://problem/111123598
Canva doesn't launch with STATIC_IPAD_USER_AGENT_VALUE enabled
https://bugs.webkit.org/show_bug.cgi?id=259891
rdar://111123598
Reviewed by Dean Jackson.
* Source/WebCore/platform/ios/UserAgentIOS.mm:
(WebCore::standardUserAgentWithApplicationName):
Canva depends on their application user agent string being respected; without it,
the app will not launch.
260450 at main introduced a mode where we hard-code more of the user agent string,
in order to allow visionOS in mobile mode to look like an iPad, but went a
little too far, and hardcoded the application-specific portion of the UA as well.
Bring back the custom application name while maintaining the hard-coded portion
in the beginning of the string.
Canonical link: https://commits.webkit.org/266657@main
Canonical link: https://commits.webkit.org/265870.242@safari-7616-branch
Commit: 2a63b17efd52e9d99c369d40d0bd727eb26104e8
https://github.com/WebKit/WebKit/commit/2a63b17efd52e9d99c369d40d0bd727eb26104e8
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
Log Message:
-----------
Cherry-pick ac6294fe9e54. rdar://problem/112044261
[visionOS] AudioSession interruptions do not stop playback
https://bugs.webkit.org/show_bug.cgi?id=259887
rdar://112044261
Reviewed by Eric Carlson.
Timing differences on visionOS result in `AVSampleBufferRenderSynchronizer`'s
rate being set to zero, prior to the interruption notification being dispatched
when an interruption occurs. This difference ordering in ordering results in a
sequence of events that causes WebKit to automatically resume playback following
an interruption.
Specifically:
1. `CMTimebaseEffectiveRateChangedCallback` is fired as AVSBRS has its rate changed, by the system.
2. Through the callback, the rate is observed as zero, resulting in playback being considered paused in the GPU process.
3. The GPU process state is reflected in the web process with a call to `MediaPlayerPrivateRemote::updateCachedState`.
4. `AVAudioSessionInterruptionNotification` is dispatched in the GPU process, by the system.
5. `HTMLMediaElement::updatePlayState()` is called in the web process.
6. The web process believes that playback is already paused, due to (3).
7. Consequently, the GPU process is never told to pause content; specifically, `MediaPlayerPrivateMediaSourceAVFObjC::pauseInternal()` is elided.
8. Importantly, that method sets a flag variable, `m_playing` to false.
9. Since `m_playing` is not set to false, `MediaPlayerPrivateMediaSourceAVFObjC::shouldBePlaying()` will return true.
10. `MediaPlayerPrivateMediaSourceAVFObjC::updateAllRenderersHaveAvailableSamples()` eventually restarts playback, since `shouldBePlaying()` is true.
On iOS, steps 1-3 do not occur before `AVAudioSessionInterruptionNotification`,
and `MediaPlayerPrivateMediaSourceAVFObjC::pauseInternal()` drives the pausing
of playback.
To fix, ensure the value of `m_playing` reflects the rate change.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::effectiveRateChanged):
Canonical link: https://commits.webkit.org/266665@main
Canonical link: https://commits.webkit.org/265870.243@safari-7616-branch
Commit: 6979b9c6e041233c1091a7ebb0d02571a0d44d36
https://github.com/WebKit/WebKit/commit/6979b9c6e041233c1091a7ebb0d02571a0d44d36
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M LayoutTests/interaction-region/overlay-expected.txt
M LayoutTests/interaction-region/overlay.html
M Source/WebCore/page/InteractionRegion.cpp
Log Message:
-----------
Cherry-pick c73297d43882. rdar://problem/113602778
REGRESSION(264990 at main) some occlusion regions are incorrect
https://bugs.webkit.org/show_bug.cgi?id=259402
<rdar://112668310>
Reviewed by Tim Horton.
We already only looked at ancestors with the same absolute content box
during the `position: fixed` search. But we also need to make sure we
won't occlude siblings.
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::isOverlay):
Update the overlay detection logic.
* LayoutTests/interaction-region/overlay-expected.txt:
* LayoutTests/interaction-region/overlay.html:
Add a test covering the change.
Canonical link: https://commits.webkit.org/266227@main
Canonical link: https://commits.webkit.org/265870.244@safari-7616-branch
Commit: ccf3abbe19d9bc8963306be3526f599bb91a0a4f
https://github.com/WebKit/WebKit/commit/ccf3abbe19d9bc8963306be3526f599bb91a0a4f
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M LayoutTests/interaction-region/consolidated-nested-regions-expected.txt
M LayoutTests/interaction-region/consolidated-nested-regions.html
M Source/WebCore/page/InteractionRegion.cpp
M Source/WebCore/page/InteractionRegion.h
M Source/WebCore/rendering/EventRegion.cpp
Log Message:
-----------
Cherry-pick 969122115609. rdar://problem/113602799
Use the presence of hover styles as a signal for InteractionRegion consolidation
https://bugs.webkit.org/show_bug.cgi?id=259398
<rdar://111551476>
Reviewed by Tim Horton.
Relax the consolidation rule when the ancestor has hover styles, so
that "buttons" with child spans get a single InteractionRegion.
* Source/WebCore/page/InteractionRegion.h:
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::elementMatchesHoverRules):
Export `elementMatchesHoverRules`.
* Source/WebCore/rendering/EventRegion.cpp:
(WebCore::EventRegionContext::shouldConsolidateInteractionRegion):
Allow consolidation if the ancestor has hover rules and the element is
centered in either axis.
* LayoutTests/interaction-region/consolidated-nested-regions-expected.txt:
* LayoutTests/interaction-region/consolidated-nested-regions.html:
Add a test covering the change.
Canonical link: https://commits.webkit.org/266230@main
Canonical link: https://commits.webkit.org/265870.245@safari-7616-branch
Commit: ba6128c53d7bb439d614d54738dc66fd784ae5f2
https://github.com/WebKit/WebKit/commit/ba6128c53d7bb439d614d54738dc66fd784ae5f2
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/ios/WKWebViewResize.mm
Log Message:
-----------
Cherry-pick d7f28b8f18d6. rdar://problem/113602886
Resizing a fullscreen element doesn't always resize children to the correct size
https://bugs.webkit.org/show_bug.cgi?id=258847
<radar://110880116>
Reviewed by Tim Horton.
During a window resize, [_contentView bounds] will not be up to date during the precommit
handler so it is incorrect to intersect it with the web view's bounds.
Additionally it makes fullscreen resizing look much smoother.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _updateVisibleContentRects]):
Skip intersection if we just resized the WKWebView.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/ios/WKWebViewResize.mm: Added.
(-[NSObject swizzled_didUpdateVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:viewStability:enclosedInScrollableAncestorView:sendEvenIfUnchanged:]):
(setupWKContentViewSwizzle):
(operator==):
Required for EXPECT_EQ on CGRect.
(webViewHasExpectedBounds):
(TEST):
Add API test which ensures a content view with no other insets will have an
unobscuredRect which matches the enclosing WKWebView's bounds after setFrame: is called.
Tests both resizing the web view larger and smaller.
Canonical link: https://commits.webkit.org/266257@main
Canonical link: https://commits.webkit.org/265870.246@safari-7616-branch
Commit: d6fe274b21105de05372efcb66c14295683f3dce
https://github.com/WebKit/WebKit/commit/d6fe274b21105de05372efcb66c14295683f3dce
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/rendering/RenderVideo.cpp
M Source/WebCore/rendering/RenderVideo.h
Log Message:
-----------
Cherry-pick b60e4db278ef. rdar://problem/113602899
Resizing video on YouTube can result in aliasing
https://bugs.webkit.org/show_bug.cgi?id=259171
<radar://112172798>
Reviewed by Tim Horton.
Apply the same change as 265672 at main but support it for videos playing
in a fullscreen element as well.
* Source/WebCore/rendering/RenderVideo.cpp:
(WebCore::RenderVideo::videoBox const):
(WebCore::RenderVideo::inElementOrVideoFullscree const):
(WebCore::RenderVideo::updatePlayer):
* Source/WebCore/rendering/RenderVideo.h:
Canonical link: https://commits.webkit.org/266284@main
Canonical link: https://commits.webkit.org/265870.247@safari-7616-branch
Commit: 72965924e07aa2cd7d4e75c278d7528d8bb183af
https://github.com/WebKit/WebKit/commit/72965924e07aa2cd7d4e75c278d7528d8bb183af
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/Modules/modern-media-controls/media/scrubbing-support.js
Log Message:
-----------
Cherry-pick 1d898475f9be. rdar://problem/113602855
Media Controls: Time stamps should update as you slide
https://bugs.webkit.org/show_bug.cgi?id=259516
rdar://112875698
Reviewed by Tim Horton.
Timestamps in the media controls should be updated as soon as the control value changes,
instead of waiting for the `timeupdate` event to be dispatched.
* Source/WebCore/Modules/modern-media-controls/media/scrubbing-support.js:
(ScrubbingSupport.prototype.controlValueDidChange):
Canonical link: https://commits.webkit.org/266339@main
Canonical link: https://commits.webkit.org/265870.248@safari-7616-branch
Commit: 8125184c8bd59221a478d87cc9e0e7ccd5038225
https://github.com/WebKit/WebKit/commit/8125184c8bd59221a478d87cc9e0e7ccd5038225
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/Shared/WebProcessCreationParameters.h
M Source/WebKit/Shared/WebProcessCreationParameters.serialization.in
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
Log Message:
-----------
Cherry-pick a6ab20ed7b64. rdar://problem/113602829
WebXR: Content is not loading in Private Browsing
https://bugs.webkit.org/show_bug.cgi?id=259462
rdar://108818635
Reviewed by Tim Horton and Mike Wyrzykowski.
The sandbox on iOS Private Browsing blocks WebXR from accessing its
cache directory on visionOS. Specifically add those directories
to the sandbox extension.
* Source/WebKit/Shared/WebProcessCreationParameters.h:
* Source/WebKit/Shared/WebProcessCreationParameters.serialization.in:
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
Canonical link: https://commits.webkit.org/266346@main
Canonical link: https://commits.webkit.org/265870.249@safari-7616-branch
Commit: de19555b3afe04058a8571850377e35133e204f8
https://github.com/WebKit/WebKit/commit/de19555b3afe04058a8571850377e35133e204f8
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
M Source/WebKit/Configurations/WebKit.xcconfig
A Source/WebKit/Platform/spi/visionos/RealitySystemSupportSPI.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 5cc3d396317e. rdar://problem/113602863
[InteractionRegions] Remove the RSS soft link and move to an SPI header
https://bugs.webkit.org/show_bug.cgi?id=259556
<rdar://105775731>
Reviewed by Tim Horton.
Introduce a new RealitySystemSupport SPI for visionOS.
* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
Clean-up the previous (outdated) definitions.
* Source/WebKit/Configurations/WebKit.xcconfig:
Link against RealitySystemSupport on visionOS.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/Platform/spi/visionos/RealitySystemSupportSPI.h: Added.
Add new SPI header.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::interactionRegionLayerClass):
(WebKit::interactionRegionEffectUserInfo):
Remove the RSS soft link and use the new SPI header instead.
(WebKit::configureLayerForInteractionRegion):
Remove the unused `LayerSizeMultiplier` user default.
Cast to `RCPGlowEffectLayer` to set the effect group configurator.
Canonical link: https://commits.webkit.org/266363@main
Canonical link: https://commits.webkit.org/265870.250@safari-7616-branch
Commit: 940a100af6ad0f029a95e97bb820833a469b1f47
https://github.com/WebKit/WebKit/commit/940a100af6ad0f029a95e97bb820833a469b1f47
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/visionos/RealitySystemSupportSPI.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
Log Message:
-----------
Cherry-pick eab190cac6db. rdar://problem/113602787
Tweak the Interaction Region effect
https://bugs.webkit.org/show_bug.cgi?id=259574
<rdar://111230277>
Reviewed by Tim Horton.
Set the custom brightness multiplier and make it configurable for future
adjustments.
* Source/WebKit/Platform/spi/visionos/RealitySystemSupportSPI.h:
Introduce the new SPI method.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::brightnessMultiplier):
(WebKit::configureLayerForInteractionRegion):
Set the brightness multiplier on interaction effect layers, default to
1.5 but read potential overrides from a user default.
Canonical link: https://commits.webkit.org/266381@main
Canonical link: https://commits.webkit.org/265870.251@safari-7616-branch
Commit: b8cdf91b81bef84a030a8cfc8c7170e0d64fc2ab
https://github.com/WebKit/WebKit/commit/b8cdf91b81bef84a030a8cfc8c7170e0d64fc2ab
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/page/InteractionRegion.cpp
Log Message:
-----------
Cherry-pick b39b69a2ef1b. rdar://problem/113602821
Fix assertion failure in InteractionRegion::isOverlay
https://bugs.webkit.org/show_bug.cgi?id=259598
<rdar://113037867>
Reviewed by Tim Horton.
We're not supposed to use `firstChildBox()` if the first child might be
of another type. Using `firstChild()` directly instead.
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::isOverlay):
Canonical link: https://commits.webkit.org/266395@main
Canonical link: https://commits.webkit.org/265870.252@safari-7616-branch
Commit: ccb839b3b1502239cc97862a9df2dacdfa7b03ea
https://github.com/WebKit/WebKit/commit/ccb839b3b1502239cc97862a9df2dacdfa7b03ea
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/Configurations/WebKit.xcconfig
R Source/WebKit/Platform/spi/visionos/RealitySystemSupportSPI.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 2e65fd05d660. rdar://problem/113602840
Bring back the RealitySystemSupport SoftLink
https://bugs.webkit.org/show_bug.cgi?id=259610
<rdar://113038445>
Reviewed by Tim Horton.
Keeping the RealitySystemSupport link soft and optional for now.
* Source/WebKit/Configurations/WebKit.xcconfig:
Remove the linker flags.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/Platform/spi/visionos/RealitySystemSupportSPI.h: Removed.
Remove the SPI header.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::interactionRegionLayerClass):
(WebKit::interactionRegionEffectUserInfo):
(WebKit::configureLayerForInteractionRegion):
Use the re-introduced optional soft link.
Canonical link: https://commits.webkit.org/266404@main
Canonical link: https://commits.webkit.org/265870.253@safari-7616-branch
Commit: 2c24661bd0fbbbdb18a4af5c5ae678afc3bc66c5
https://github.com/WebKit/WebKit/commit/2c24661bd0fbbbdb18a4af5c5ae678afc3bc66c5
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebCore/loader/mac/LoaderNSURLExtras.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
R Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLCanonicalization.mm
A Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLExtras.mm
Log Message:
-----------
Cherry-pick d94ee98c7619. rdar://problem/113602762
Safari crashes when showing the downloads menu for a download with no MIME type
https://bugs.webkit.org/show_bug.cgi?id=259622
rdar://113058721
Reviewed by Wenson Hsieh.
* Source/WebCore/loader/mac/LoaderNSURLExtras.mm:
Add a null check.
* Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLExtras.mm: Renamed from Tools/TestWebKitAPI/Tests/WebKitLegacy/mac/URLCanonicalization.mm.
(TestWebKitAPI::TEST):
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
Rename URLCanonicalization to URLExtras and add a (very simple) positive and
negative test for _webkit_suggestedFilenameWithMIMEType, which was what
was triggering this crash.
Canonical link: https://commits.webkit.org/266414@main
Canonical link: https://commits.webkit.org/265870.254@safari-7616-branch
Commit: f5a2b8fe54c5f9d9b55de1102faab522dfa4a9ce
https://github.com/WebKit/WebKit/commit/f5a2b8fe54c5f9d9b55de1102faab522dfa4a9ce
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/visionos/MRUIKitSPI.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick 4776571d7bd6. rdar://problem/113602878
[visionOS] Media: “…” options menu doesn’t present (when in full screen)
https://bugs.webkit.org/show_bug.cgi?id=259589
rdar://112867127
Reviewed by Tim Horton and Aditya Keerthi.
Instead of preventing any ornament from showing at all when in full screen, only hide/show the
ornaments that are present in the window when entering/exiting full screen.
* Source/WebKit/Platform/spi/visionos/MRUIKitSPI.h:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKMRUIPlatterOrnamentProperties initWithDepthDisplacement:windowAlpha:]):
(-[WKFullScreenParentWindowState initWithWindow:]):
(-[WKFullScreenParentWindowState ornamentProperties]):
(-[WKFullScreenWindowController _setOrnamentsHidden:]):
(-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
(-[WKFullScreenParentWindowState ornamentDepths]): Deleted.
Canonical link: https://commits.webkit.org/266454@main
Canonical link: https://commits.webkit.org/265870.255@safari-7616-branch
Commit: abcbec5f1bbadc5a13d775ec410853f7bec8ff7b
https://github.com/WebKit/WebKit/commit/abcbec5f1bbadc5a13d775ec410853f7bec8ff7b
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
Log Message:
-----------
Cherry-pick df20f33b80c9. rdar://problem/113278323
[visionOS] WebGL content is empty in private browsing
https://bugs.webkit.org/show_bug.cgi?id=259780
<radar://113278323>
Reviewed by Dean Jackson.
WebGL is still in the WebContent process on visionOS, so we need
to add a sandbox exception in private browsing so Metal can write
to one if its cache directories.
Similar to the change made for WebXR in 266346 at main
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformInitializeWebProcess):
Canonical link: https://commits.webkit.org/266565@main
Canonical link: https://commits.webkit.org/265870.256@safari-7616-branch
Commit: b31a9b116eac91be46a31c7340c3950bea532f1a
https://github.com/WebKit/WebKit/commit/b31a9b116eac91be46a31c7340c3950bea532f1a
Author: Russell Epstein <repstein at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebCore/platform/graphics/ca/PlatformCALayer.h
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTree.serialization.in
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreeTransaction.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreeTransaction.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeNode.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm
Log Message:
-----------
Cherry-pick bb2814850996. rdar://problem/113094884
Dropping frames on visionOS while scrolling due to number of glow layers on some websites
https://bugs.webkit.org/show_bug.cgi?id=259739
<radar://113094884>
Reviewed by Dean Jackson.
Cull glow regions outside of visible areas as the user will not be able
to interact with them.
* LayoutTests/interaction-region/interaction-layers-culling-expected.txt:
Update test expectation.
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::updateCoverage):
* Source/WebCore/platform/graphics/ca/PlatformCALayer.h:
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h:
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::setVisibleRect):
(WebCore::PlatformCALayerCocoa::setCoverageRect): Deleted.
* Source/WebKit/Shared/RemoteLayerTree/LayerProperties.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTree.serialization.in:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm:
(WebKit::RemoteLayerTreePropertyApplier::applyProperties):
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreeTransaction.mm:
(WebKit::LayerProperties::encode const):
(WebKit::LayerProperties::decode):
(WebKit::dumpChangedLayers):
Change use of coverageRect to visibleRect.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::updateLayersForInteractionRegions):
Layer was being inserted twice, correct this.
Also instead of testing if the rect exists and it did not intersect to return early,
test that either the rect does not exist or it does not interesect to return early.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeNode.h:
(WebKit::RemoteLayerTreeNode::visibleRect const):
(WebKit::RemoteLayerTreeNode::setVisibleRect):
(WebKit::RemoteLayerTreeNode::CoverageRectMarkableTraits::isEmptyValue): Deleted.
(WebKit::RemoteLayerTreeNode::CoverageRectMarkableTraits::emptyValue): Deleted.
(WebKit::RemoteLayerTreeNode::coverageRect const): Deleted.
(WebKit::RemoteLayerTreeNode::setCoverageRect): Deleted.
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm:
(WebKit::PlatformCALayerRemote::setVisibleRect):
(WebKit::PlatformCALayerRemote::setCoverageRect): Deleted.
Change use of coverageRect to visibleRect.
Canonical link: https://commits.webkit.org/266604@main
Canonical link: https://commits.webkit.org/265870.257@safari-7616-branch
Commit: ccc014a6068ad69d2fbaf3ed51342fdbe4c306dd
https://github.com/WebKit/WebKit/commit/ccc014a6068ad69d2fbaf3ed51342fdbe4c306dd
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M LayoutTests/accessibility/mac/basic-embed-pdf-accessibility-expected.txt
M LayoutTests/accessibility/mac/basic-embed-pdf-accessibility.html
M LayoutTests/accessibility/mac/iframe-pdf.html
Log Message:
-----------
Cherry-pick 00389e4e1673. rdar://problem/113604923
REGRESSION: Two accessibility/mac/ tests are a consistent failure
https://bugs.webkit.org/show_bug.cgi?id=259452
rdar://110029481
Reviewed by Chris Fleizach.
These tests needed to be re-based and the value of the static text needs to be trimEnd() to accomodate differences in trailing \n between OS versions.
* LayoutTests/accessibility/mac/basic-embed-pdf-accessibility-expected.txt:
* LayoutTests/accessibility/mac/basic-embed-pdf-accessibility.html:
* LayoutTests/accessibility/mac/iframe-pdf-expected.txt:
Canonical link: https://commits.webkit.org/266296@main
Identifier: 265870.258 at safari-7616-branch
Commit: 606af9cc6a287234859e2897ac521c096f526234
https://github.com/WebKit/WebKit/commit/606af9cc6a287234859e2897ac521c096f526234
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.h
Log Message:
-----------
Cherry-pick 43bb506b88bc. rdar://problem/113605423
Cherry-pick 2d0174d8fad3. rdar://problem/112413309
[macOS] Block runningboard access in the Network Process sandbox again
https://bugs.webkit.org/show_bug.cgi?id=259274
Reviewed by Per Arne Vollan.
Block runningboard access in the Network Process sandbox again on macOS and
address Bug 259229 by always holding a background assertion on the network
process (so that it never suspends).
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::setIsHoldingLockedFiles):
* Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::NetworkProcessProxy):
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:
Canonical link: https://commits.webkit.org/266101@main
Identifier: 265870.259 at safari-7616-branch
Commit: 72aa84db2bb27129dd340838862ed25d2887b47a
https://github.com/WebKit/WebKit/commit/72aa84db2bb27129dd340838862ed25d2887b47a
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm
M Source/WebCore/platform/graphics/cocoa/NullVideoFullscreenInterface.h
M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.h
M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm
M Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm
M Source/WebKit/WebProcess/cocoa/VideoFullscreenManager.mm
Log Message:
-----------
Cherry-pick fb27258267ac. rdar://problem/113605284
Cherry-pick a428fb0a4209. rdar://problem/112448871
[iOS] Exiting PiP by navigation then restoring page from back/forward cache results in missing video content
https://bugs.webkit.org/show_bug.cgi?id=259377
rdar://112448871
Reviewed by Eric Carlson.
A few interrelated fixes are needed to resolve this behavior:
- Add a new method to VideoFullscreenInterfaceAVKit, exitFullscreenWithoutAnimationToMode(),
which will tear down fullscreen and PiP without invalidating the interface itself.
- In MediaPlayerPrivateAVFoundationObjC, reset m_haveBeenAskedToCreateLayer to false when
destroying the video layer so that the next creation request won't bail out early.
- A refcount mismatch occurs when moving from video fullscreen to pip, as the WebContent
process calls setupFullscreenWithID() again in this case, but does not call
removeClientForContext(). Only add an additional refcount if the interface is not already
in fullscreen mode.
- Remove the iOS-only direct call of removeClientForContext() from
exitVideoFullscreenToModeWithoutAnimation(). This call will now correctly result in
the interface calling removeClientForContext() on both macOS and iOS.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::destroyVideoLayer):
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.h:
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm:
(VideoFullscreenInterfaceAVKit::exitFullscreen):
(VideoFullscreenInterfaceAVKit::exitFullscreenWithoutAnimationToMode):
* Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm:
(WebKit::VideoFullscreenManagerProxy::setupFullscreenWithID):
(WebKit::VideoFullscreenManagerProxy::exitFullscreenWithoutAnimationToMode):
* Source/WebKit/WebProcess/cocoa/VideoFullscreenManager.mm:
(WebKit::VideoFullscreenManager::exitVideoFullscreenToModeWithoutAnimation):
Canonical link: https://commits.webkit.org/266239@main
Identifier: 265870.260 at safari-7616-branch
Commit: c006aed74ef31e813d8f7a243fabf43e07c646c1
https://github.com/WebKit/WebKit/commit/c006aed74ef31e813d8f7a243fabf43e07c646c1
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick 43a390dd03ea. rdar://problem/113605033
Cherry-pick 681597b43c00. rdar://problem/112718525
Reduce logging volume
https://bugs.webkit.org/show_bug.cgi?id=259421
rdar://112718525
Reviewed by Eric Carlson and Brent Fulgham.
Reduce logging volume, since WebKit is sometimes quarantined by the logging system due to high volume.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::scheduleUpdateMediaState):
(WebCore::HTMLMediaElement::updateMediaPlayer):
Canonical link: https://commits.webkit.org/266254@main
Identifier: 265870.261 at safari-7616-branch
Commit: e2979502625e52ed68bae918b66183d6e3237145
https://github.com/WebKit/WebKit/commit/e2979502625e52ed68bae918b66183d6e3237145
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
Log Message:
-----------
Cherry-pick 93146d9aa26e. rdar://problem/113605404
Cherry-pick a7685646bede. rdar://problem/112777207
Prewarm Web process when load starts
https://bugs.webkit.org/show_bug.cgi?id=259447
rdar://112777207
Reviewed by Brent Fulgham.
We currently prewarm a Web process when the main frame load has finished. Instead, prewarm a Web process
when the provisional load starts, which has been measured to be a 1-2% speedup in page load time.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::notifyProcessPoolToPrewarm):
(WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
(WebKit::WebPageProxy::didFinishLoadForFrame):
* Source/WebKit/UIProcess/WebProcessPool.h:
Canonical link: https://commits.webkit.org/266255@main
Identifier: 265870.262 at safari-7616-branch
Commit: 2cefba280b1c19d2dd3dddf6dc5b6e407de9abf1
https://github.com/WebKit/WebKit/commit/2cefba280b1c19d2dd3dddf6dc5b6e407de9abf1
Author: Nikolaos Mouchtaris <nmouchtaris at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.h
M Source/WebCore/page/scrolling/ScrollingCoordinator.h
M Source/WebCore/page/scrolling/ScrollingStateNode.h
M Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h
M Source/WebCore/page/scrolling/mac/ScrollerMac.h
M Source/WebCore/page/scrolling/mac/ScrollerMac.mm
M Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm
M Source/WebCore/platform/Scrollbar.cpp
M Source/WebCore/platform/ScrollbarsController.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.mm
Log Message:
-----------
Cherry-pick 58a2cf8bc464. rdar://problem/113605121
Cherry-pick e41f5679593f. rdar://problem/110872395
[UI-side compositing] REGRESSION: empty Mail compose window always shows a scrollbar
https://bugs.webkit.org/show_bug.cgi?id=259323
rdar://110872395
Reviewed by Simon Fraser.
To properly set NSScrollerImps as enabled in the UI-process, send accross the web
process state from the Scrollbar class. It is also necessary to set the state in
setScrollingNodeScrollableAreaGeometry because the first time setting this state
on the Scrollbar class can happen before the corresponding scrollable area has been
added to the scrolling tree.
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::setScrollbarEnabled):
(WebCore::AsyncScrollingCoordinator::setScrollingNodeScrollableAreaGeometry):
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.h:
* Source/WebCore/page/scrolling/ScrollingCoordinator.h:
(WebCore::ScrollingCoordinator::setScrollbarEnabled):
* Source/WebCore/page/scrolling/ScrollingStateNode.h:
* Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp:
(WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode):
(WebCore::ScrollingStateScrollingNode::setScrollbarEnabledState):
* Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h:
(WebCore::ScrollingStateScrollingNode::scrollbarEnabledState const):
* Source/WebCore/page/scrolling/mac/ScrollerMac.h:
(WebCore::ScrollerMac::setEnabled):
* Source/WebCore/page/scrolling/mac/ScrollerMac.mm:
(WebCore::ScrollerMac::updateValues):
* Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm:
(WebCore::ScrollingTreeScrollingNodeDelegateMac::updateFromStateNode):
* Source/WebCore/platform/Scrollbar.cpp:
(WebCore::Scrollbar::setEnabled):
* Source/WebCore/platform/ScrollbarsController.h:
(WebCore::ScrollbarsController::setScrollbarEnabledSate):
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
(ArgumentCoder<ScrollingStateScrollingNode>::encode):
(ArgumentCoder<ScrollingStateScrollingNode>::decode):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollbarsController.mm:
(WebKit::RemoteScrollbarsController::setScrollbarEnabledSate):
Canonical link: https://commits.webkit.org/266261@main
Identifier: 265870.263 at safari-7616-branch
Commit: 29eb782743194690432de29069669ff6c6b20f46
https://github.com/WebKit/WebKit/commit/29eb782743194690432de29069669ff6c6b20f46
Author: Justin Michaud <justin_michaud at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Tools/TestWebKitAPI/Tests/WTF/Packed.cpp
Log Message:
-----------
Cherry-pick 5d0ead6b85fc. rdar://problem/113605346
Cherry-pick 00c679a9ae1b. rdar://problem/112620141
REGRESSION(265930 at main): [ iOS 16 ] TestWTF.WTF_Packed.PackedAlignedPtr is a constant failure
https://bugs.webkit.org/show_bug.cgi?id=259366
rdar://112620141
Reviewed by Brent Fulgham.
I missed a compile guard.
* Tools/TestWebKitAPI/Tests/WTF/Packed.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/266263@main
Identifier: 265870.264 at safari-7616-branch
Commit: 5d7fe0414f8a70dc12660eb2227859c4e460089c
https://github.com/WebKit/WebKit/commit/5d7fe0414f8a70dc12660eb2227859c4e460089c
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/PathSegment.cpp
M Source/WebCore/platform/graphics/PathSegment.h
M Source/WebCore/platform/graphics/PathSegmentData.cpp
M Source/WebCore/platform/graphics/PathSegmentData.h
M Source/WebCore/platform/graphics/PathStream.cpp
M Source/WebCore/platform/graphics/cairo/PathCairo.cpp
M Source/WebCore/platform/graphics/cg/PathCG.cpp
M Source/WebKit/GPUProcess/graphics/PathSegment.serialization.in
Log Message:
-----------
Cherry-pick a21f72a1fae8. rdar://problem/113604836
Cherry-pick fe314ea4b982. rdar://problem/112741404
Use a new type PathCloseSubpath instead of std::monostate to represent a close command in PathSegment
https://bugs.webkit.org/show_bug.cgi?id=259430
rdar://problem/112741404
Reviewed by Simon Fraser.
Adding an empty struct lets us treat this command like all the others,
and not special case it in the WTF::switchOn calls in PathSegment.cpp.
* Source/WebCore/platform/graphics/PathSegment.cpp:
(WebCore::PathSegment::calculateEndPoint const):
(WebCore::PathSegment::extendFastBoundingRect const):
(WebCore::PathSegment::extendBoundingRect const):
(WebCore::PathSegment::addToImpl const):
(WebCore::PathSegment::applyElements const):
(WebCore::operator<<):
* Source/WebCore/platform/graphics/PathSegment.h:
(WebCore::PathSegment::isCloseSubPath const):
* Source/WebCore/platform/graphics/PathSegmentData.cpp:
(WebCore::PathCloseSubpath::calculateEndPoint const):
(WebCore::PathCloseSubpath::extendFastBoundingRect const):
(WebCore::PathCloseSubpath::extendBoundingRect const):
(WebCore::PathCloseSubpath::addToImpl const):
(WebCore::PathCloseSubpath::applyElements const):
(WebCore::operator<<):
* Source/WebCore/platform/graphics/PathSegmentData.h:
* Source/WebCore/platform/graphics/PathStream.cpp:
(WebCore::PathStream::closeSubpath):
* Source/WebCore/platform/graphics/cg/PathCG.cpp:
(WebCore::pathSegmentApplierCallback):
* Source/WebKit/GPUProcess/graphics/PathSegment.serialization.in:
Canonical link: https://commits.webkit.org/266264@main
Identifier: 265870.265 at safari-7616-branch
Commit: 7924fb5101e950812492915389ca6f0f8d2e58d9
https://github.com/WebKit/WebKit/commit/7924fb5101e950812492915389ca6f0f8d2e58d9
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.cpp
Log Message:
-----------
Cherry-pick 9e5c9baf8c68. rdar://problem/113605412
Cherry-pick 80f6e24ca1d1. rdar://problem/112743547
Allocating a new IPC::Semaphore for each RemoteImageBufferProxy::flushDrawingContextAsync adds significant overhead.
https://bugs.webkit.org/show_bug.cgi?id=259433
<rdar://112743547>
Reviewed by Dean Jackson.
Frequently we have an existing pending flush object, where the semaphore has already been signaled.
This makes the m_signaled bool atomic, so that we can check for completed flush objects without taking
the lock and blocking. This will still be false if the existing use of the semaphore hasn't yet been signaled,
or if the waitFor call failed.
If we find a completed flush objects, then moves the semaphore across into the new one to prevent a new allocation.
* Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.cpp:
(WebKit::RemoteImageBufferProxyFlushFence::tryTakeSemaphore):
(WebKit::RemoteImageBufferProxy::flushDrawingContextAsync):
(WebKit::RemoteImageBufferProxyFlushFence::WTF_GUARDED_BY_LOCK): Deleted.
Canonical link: https://commits.webkit.org/266265@main
Identifier: 265870.266 at safari-7616-branch
Commit: f527cb4a12f868f721a1fb1ec3b1fa687be08cec
https://github.com/WebKit/WebKit/commit/f527cb4a12f868f721a1fb1ec3b1fa687be08cec
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/ApplicationStateTracker.h
M Source/WebKit/UIProcess/ApplicationStateTracker.mm
M Source/WebKit/UIProcess/ios/WKApplicationStateTrackingView.mm
Log Message:
-----------
Cherry-pick 36dc0f48886d. rdar://problem/113604686
Cherry-pick 5ae7317c43cd. rdar://problem/107673739
[iOS] Safari window sometimes flashes black when app switching or tab switching
https://bugs.webkit.org/show_bug.cgi?id=259455
rdar://107673739
Reviewed by Tim Horton.
WebKit relies on the _UIApplicationDidFinishSuspensionSnapshotNotification notification to do two things
in WebPageProxy::applicationDidFinishSnapshottingAfterEnteringBackground(): if layers contain Mach port
contents, map in IOSurfaces for those so that we don't hold an in-use count which prevents the layers from
becoming volatile (no longer applicable now that layers hold CAIOSurfaceRefs), and storing a TransactionID
in RemoteLayerTreeDrawingAreaProxy::hideContentUntilPendingUpdate() to keep content hidden until we get
a new transaction on resume.
UIKit stopped sending that notification a few years ago (rdar://112569013) so just hook up our call to
`applicationDidFinishSnapshottingAfterEnteringBackground()` at the end of `_didCompleteSnapshotSequence`.
Also add some release logging for background snapshotting.
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/UIProcess/ApplicationStateTracker.h:
* Source/WebKit/UIProcess/ApplicationStateTracker.mm:
(WebKit::ApplicationStateTracker::ApplicationStateTracker):
(WebKit::ApplicationStateTracker::~ApplicationStateTracker):
(WebKit::ApplicationStateTracker::applicationDidFinishSnapshottingAfterEnteringBackground): Deleted.
* Source/WebKit/UIProcess/ios/WKApplicationStateTrackingView.mm:
(-[WKApplicationStateTrackingView didMoveToWindow]):
(-[WKApplicationStateTrackingView _applicationDidFinishSnapshottingAfterEnteringBackground]):
(-[WKApplicationStateTrackingView _willBeginSnapshotSequence]):
(-[WKApplicationStateTrackingView _didCompleteSnapshotSequence]):
Canonical link: https://commits.webkit.org/266274@main
Identifier: 265870.267 at safari-7616-branch
Commit: 7263d3f223845589903c2a7abc244981a38e5d06
https://github.com/WebKit/WebKit/commit/7263d3f223845589903c2a7abc244981a38e5d06
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/GPUProcess/media/RemoteAudioSessionProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteAudioSessionProxy.h
M Source/WebKit/GPUProcess/media/RemoteAudioSessionProxyManager.cpp
Log Message:
-----------
Cherry-pick 36abf9397c1b. rdar://problem/113605064
Cherry-pick 727f9c1406c6. rdar://problem/112636992
REGRESSION (iOS 17 Beta): The call is not unmuted automatically after the use of Siri in the middle of the WebRTC call, sometimes incoming audio is lost
https://bugs.webkit.org/show_bug.cgi?id=259368
rdar://112636992
Reviewed by Eric Carlson.
WebProcess might want to try active its audio session when being interrupted.
In case GPUProcess tells it succeeded activating, it will uninterrupt and restart capturing microphone.
RemoteAudioSessionProxyManager::tryToSetActiveForProcess may return true to activation even though the underlying shared session was not properly activated.
This happens in case there is one RemoteAudioSessionProxy which is active but interrupted.
In that case, RemoteAudioSessionProxyManager::tryToSetActiveForProcess would think everything is fine.
To prevent this, RemoteAudioSessionProxy is now tracking whether it is interrupted or not.
If it is active but interrupted, RemoteAudioSessionProxyManager will not consider it is actually active and will try to activate the underlying audio session.
If activation succeeds, uninterruption will follow.
If activation fails, uninterruption will be further delayed.
Manually tested.
* Source/WebKit/GPUProcess/media/RemoteAudioSessionProxy.cpp:
* Source/WebKit/GPUProcess/media/RemoteAudioSessionProxy.h:
(WebKit::RemoteAudioSessionProxy::isInterrupted const):
* Source/WebKit/GPUProcess/media/RemoteAudioSessionProxyManager.cpp:
(WebKit::RemoteAudioSessionProxyManager::tryToSetActiveForProcess):
Canonical link: https://commits.webkit.org/266293@main
Identifier: 265870.268 at safari-7616-branch
Commit: 6ab0374021e944f9d7aa7ea799e9c7d3940281bb
https://github.com/WebKit/WebKit/commit/6ab0374021e944f9d7aa7ea799e9c7d3940281bb
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/fullscreen/fullscreen-containing-block-change-expected.txt
A LayoutTests/fullscreen/fullscreen-containing-block-change-with-continuation-expected.txt
A LayoutTests/fullscreen/fullscreen-containing-block-change-with-continuation.html
A LayoutTests/fullscreen/fullscreen-containing-block-change.html
M Source/WebCore/dom/FullscreenManager.cpp
Log Message:
-----------
Cherry-pick 67fa4bb05a12. rdar://problem/113604719
Cherry-pick f82dc74981d8. rdar://problem/111095697
REGRESSION(265043 at main): Fullscreen mode only shows video in some part of the screen on Twitter
https://bugs.webkit.org/show_bug.cgi?id=258907
rdar://111095697>
Reviewed by Simon Fraser and Tim Nguyen.
Add-to-top-layer changes containing block state which may affect geometry and requires layout to run.
This patch ensures that all the relevant pieces are marked for layout when transitioning to fullscreen including cases when a child frame initiates it.
It is essentially mimicking what out-of-flow type of containing block change triggers through styleDid/WillChange
e.g. when going from absolute to fix with a relative positioned ancestor.
(Test case credit goes to Tim Nguyen)
* LayoutTests/fullscreen/fullscreen-containing-block-change-expected.txt: Added.
* LayoutTests/fullscreen/fullscreen-containing-block-change-with-continuation-expected.txt: Added.
* LayoutTests/fullscreen/fullscreen-containing-block-change-with-continuation.html: Added.
* LayoutTests/fullscreen/fullscreen-containing-block-change.html: Added.
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::markRendererDirtyAfterTopLayerChange):
(WebCore::FullscreenManager::willEnterFullscreen):
Canonical link: https://commits.webkit.org/266309@main
Identifier: 265870.269 at safari-7616-branch
Commit: 268006885af375b8a23171fa235dae4a2c0a2827
https://github.com/WebKit/WebKit/commit/268006885af375b8a23171fa235dae4a2c0a2827
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/AXTextMarker.cpp
M Source/WebCore/accessibility/cocoa/AXTextMarkerCocoa.mm
Log Message:
-----------
Cherry-pick 49d0fd9d61c4. rdar://problem/113605067
Cherry-pick c556dfa7678b. rdar://problem/112870208
AX: Crash in AXTextMarkerRange constructor when passed a null AXTextMarkerRangeRef.
https://bugs.webkit.org/show_bug.cgi?id=259512
<rdar://problem/112870208>
Reviewed by Chris Fleizach.
Added null-checks in the conversion between AXTextMarkerRange objects and AXTextMarkerRangeRefs and VisiblePositionRanges.
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::AXTextMarkerRange::operator VisiblePositionRange const):
* Source/WebCore/accessibility/cocoa/AXTextMarkerCocoa.mm:
(WebCore::AXTextMarker::AXTextMarker):
(WebCore::AXTextMarkerRange::AXTextMarkerRange):
Canonical link: https://commits.webkit.org/266313@main
Identifier: 265870.270 at safari-7616-branch
Commit: baf9aba3a75cafcb03e1917bebc432c147f5c797
https://github.com/WebKit/WebKit/commit/baf9aba3a75cafcb03e1917bebc432c147f5c797
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructorInlines.h
Log Message:
-----------
Cherry-pick 48e5bfdadbd6. rdar://problem/113605372
Cherry-pick e8629ce0fda3. rdar://problem/113142897
[JSC] Avoid costly length etc. access for `new TypedArray(array)` case
https://bugs.webkit.org/show_bug.cgi?id=259240
rdar://problem/112310821
Reviewed by Ross Kirsling.
Let's use the fast path and array iterator protocol status to skip "length" and Symbol.iterator access
for `new TypedArray(array)` case.
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
Canonical link: https://commits.webkit.org/266082@main
Identifier: 265870.271 at safari-7616-branch
Commit: 1855c9861a43305c5f216de76909a01340b5b363
https://github.com/WebKit/WebKit/commit/1855c9861a43305c5f216de76909a01340b5b363
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/editing/TextIterator.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm
Log Message:
-----------
Cherry-pick f2ad3449fa01. rdar://problem/113605244
Cherry-pick b422a1c3f07c. rdar://problem/112908387
[iOS] Tap to revert does not work for multi-word autocorrections
https://bugs.webkit.org/show_bug.cgi?id=259522
rdar://112908387
Reviewed by Wenson Hsieh.
There are two issues preventing multi-word autocorrection UI from working correctly:
1. The correction indicator is only applied to the last word.
2. `-[WKContentView selectWordForReplacement]` does not extend the selection to cover multiple autocorrected words.
To fix (1), apply the correction indicator marker to the entire autocorrected
range. This is achieved by searching backwords for the inserted text to obtain
a range.
Then (2) is fixed by leveraging the same logic to extend the selection for
dictation alternatives, by extending the selection to cover the entire
DocumentMarker::CorrectionIndicator.
* Source/WebCore/editing/TextIterator.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::adjustCandidateAutocorrectionInFrame):
Search for the autocorrected range, beginning at the start of the editable
content and ending at the current selection. Search backwards since we know the
range will be at the end. Mark the entire range with
`DocumentMarker::CorrectionIndicator`.
(WebKit::WebPage::extendSelectionForReplacement):
Extend the selection to encompass the entire `DocumentMarker::CorrectionIndicator`.
(WebKit::WebPage::applyAutocorrectionInternal):
* Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
(TEST):
Canonical link: https://commits.webkit.org/266336@main
Identifier: 265870.272 at safari-7616-branch
Commit: 4477c9c3e0a5e780eed45fb7d226bf1f6d412f3b
https://github.com/WebKit/WebKit/commit/4477c9c3e0a5e780eed45fb7d226bf1f6d412f3b
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/fullscreen/fullscreen-containing-block-change-with-iframe-expected.txt
A LayoutTests/fullscreen/fullscreen-containing-block-change-with-iframe.html
Log Message:
-----------
Cherry-pick 2822b34a4373. rdar://problem/113605321
Cherry-pick 72f6ace047bf. rdar://problem/112934625
[fullscreen] Add iframe testcase for 266309 at main
https://bugs.webkit.org/show_bug.cgi?id=259533
rdar://112934625
Reviewed by Simon Fraser.
Add test for a case that was initially missed for the fix in 266309 at main, to avoid regressing it.
* LayoutTests/fullscreen/fullscreen-containing-block-change-with-iframe-expected.txt: Added.
* LayoutTests/fullscreen/fullscreen-containing-block-change-with-iframe.html: Added.
Canonical link: https://commits.webkit.org/266342@main
Identifier: 265870.273 at safari-7616-branch
Commit: a273d36c910f47baee4cea79731f9ede30cfd333
https://github.com/WebKit/WebKit/commit/a273d36c910f47baee4cea79731f9ede30cfd333
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCTCPSocketCocoa.mm
Log Message:
-----------
Cherry-pick 35f5c45e5f92. rdar://problem/113605247
Cherry-pick 7c4c435f65ec. rdar://problem/112931044
NetworkRTCTCPSocketCocoa should send the interface name to its WebProcess if not null
https://bugs.webkit.org/show_bug.cgi?id=259554
rdar://112931044
Reviewed by Alex Christensen.
nw_interface_get_name can return null, in which case sending a null string to the WebProcess is neither good nor useful.
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCTCPSocketCocoa.mm:
(WebKit::NetworkRTCTCPSocketCocoa::NetworkRTCTCPSocketCocoa):
Canonical link: https://commits.webkit.org/266360@main
Identifier: 265870.274 at safari-7616-branch
Commit: 5566f82333d9a2bc339231f59833694694ac5d9b
https://github.com/WebKit/WebKit/commit/5566f82333d9a2bc339231f59833694694ac5d9b
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/Configurations/WebKit.xcconfig
R Source/WebKit/Resources/Signposts/LoggingPreferences.plist
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 788748739c1c. rdar://problem/113605430
Cherry-pick 4232eab5d0d4. rdar://problem/112840318
Reading logging preference file takes time on launch
https://bugs.webkit.org/show_bug.cgi?id=259483
rdar://112840318
Reviewed by Brent Fulgham.
Reading the logging preference file is using 30-40ms of CPU time when launching the WebContent process on iOS.
This patch proposes that we remove the file, and instead set the preferences manually when needed.
* Source/WebKit/Configurations/WebKit.xcconfig:
* Source/WebKit/Resources/Signposts/LoggingPreferences.plist: Removed.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/266362@main
Identifier: 265870.275 at safari-7616-branch
Commit: 92761ac28948b6962c1769713d1ffc6aa34a8b4f
https://github.com/WebKit/WebKit/commit/92761ac28948b6962c1769713d1ffc6aa34a8b4f
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssembler.h
M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h
M Source/JavaScriptCore/assembler/MacroAssemblerX86_64.h
M Source/JavaScriptCore/jit/JITBitAndGenerator.cpp
M Source/JavaScriptCore/jit/JITBitOrGenerator.cpp
M Source/JavaScriptCore/jit/JITBitXorGenerator.cpp
Log Message:
-----------
Cherry-pick e650cf2e34ce. rdar://problem/113605387
Cherry-pick ab2034db4691. rdar://problem/112956788
[JSC] Micro optimize bitops in IC
https://bugs.webkit.org/show_bug.cgi?id=259547
rdar://112956788
Reviewed by Mark Lam.
This patch micro-optimizes bitops in IC in Baseline by using three-operand machine codes.
* Source/JavaScriptCore/assembler/MacroAssembler.h:
(JSC::MacroAssembler::and64):
* Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::and64):
* Source/JavaScriptCore/assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::and64):
* Source/JavaScriptCore/jit/JITBitAndGenerator.cpp:
(JSC::JITBitAndGenerator::generateFastPath):
* Source/JavaScriptCore/jit/JITBitOrGenerator.cpp:
(JSC::JITBitOrGenerator::generateFastPath):
* Source/JavaScriptCore/jit/JITBitXorGenerator.cpp:
(JSC::JITBitXorGenerator::generateFastPath):
Canonical link: https://commits.webkit.org/266367@main
Identifier: 265870.276 at safari-7616-branch
Commit: 71f0bdb46b874b98046ee8e60ccf88a76d174b09
https://github.com/WebKit/WebKit/commit/71f0bdb46b874b98046ee8e60ccf88a76d174b09
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.h
M Source/WebCore/accessibility/atspi/AXObjectCacheAtspi.cpp
M Source/WebCore/accessibility/ios/AXObjectCacheIOS.mm
M Source/WebCore/accessibility/mac/AXObjectCacheMac.mm
Log Message:
-----------
Cherry-pick 1e6a76e5426a. rdar://problem/113605096
Cherry-pick 1e1fc4fec300. rdar://problem/113007046
AX: AXObjectCache platform post notification methods should keep alive target objects.
https://bugs.webkit.org/show_bug.cgi?id=259583
<rdar://problem/113007046>
Reviewed by Chris Fleizach.
AXObjectCache platform post notification methods may cause an update of the object cache and the removal of the target object of the notification. This patch ensures that the target object of the notification stays alive for the scope of the notification method.
* Source/WebCore/accessibility/AXObjectCache.h:
* Source/WebCore/accessibility/mac/AXObjectCacheMac.mm:
(WebCore::AXObjectCache::postPlatformNotification):
(WebCore::AXObjectCache::postTextStateChangePlatformNotification):
(WebCore::AXObjectCache::postTextReplacementPlatformNotification):
(WebCore::AXObjectCache::postTextReplacementPlatformNotificationForTextControl):
* Source/WebCore/accessibility/atspi/AXObjectCacheAtspi.cpp:
(WebCore::AXObjectCache::postTextStateChangePlatformNotification):
(WebCore::AXObjectCache::postTextReplacementPlatformNotificationForTextControl):
(WebCore::AXObjectCache::postTextReplacementPlatformNotification):
* Source/WebCore/accessibility/ios/AXObjectCacheIOS.mm:
(WebCore::AXObjectCache::postTextStateChangePlatformNotification):
(WebCore::AXObjectCache::postTextReplacementPlatformNotification):
(WebCore::AXObjectCache::postTextReplacementPlatformNotificationForTextControl):
Canonical link: https://commits.webkit.org/266385@main
Identifier: 265870.277 at safari-7616-branch
Commit: f08ad414a0b5954a796d460ce869a5f35d32ff7b
https://github.com/WebKit/WebKit/commit/f08ad414a0b5954a796d460ce869a5f35d32ff7b
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
Log Message:
-----------
Cherry-pick 157bb2a53664. rdar://problem/113605278
Cherry-pick fdd0bc163f50. rdar://problem/112901862
Canvas does not show results of CanvasRenderingContext2D.putImageData until forced re-render.
https://bugs.webkit.org/show_bug.cgi?id=259584
rdar://112901862
Reviewed by Tim Nguyen.
The commit in 263694 at main caused a regression when calculating the dirty region
of a putImageDataUpdate. It accidentally removed a reference marker on a parameter.
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::computeImageDataRect): Make sure the destRect parameter is a reference because it is updated.
(WebCore::CanvasRenderingContext2DBase::putImageData): Leave a fixme!
Canonical link: https://commits.webkit.org/266397@main
Identifier: 265870.278 at safari-7616-branch
Commit: 362c1d07adfe9d2cef47b0839e47b9e21116b193
https://github.com/WebKit/WebKit/commit/362c1d07adfe9d2cef47b0839e47b9e21116b193
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/dom/DocumentMarkerController.cpp
M Source/WebCore/dom/DocumentMarkerController.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/Shared/DocumentEditingContext.h
M Source/WebKit/Shared/DocumentEditingContext.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm
M Tools/TestWebKitAPI/ios/UIKitSPI.h
Log Message:
-----------
Cherry-pick a01be23022ec. rdar://problem/113604696
Cherry-pick 65175743b659. rdar://problem/113036177
[iOS] Tap to revert does not always display an accurate prompt for multi-word autocorrections
https://bugs.webkit.org/show_bug.cgi?id=259595
rdar://113036177
Reviewed by Wenson Hsieh.
UIKit requires additional information in order to detect that a tapped word is
part of a multi-word correction. Specifically, they require the entire
corrected string given a single tapped word, in order to look up the right
autocorrection record.
To support this requirement, add support for obtaining autocorrected ranges in
a document editing context. WebKit will provide `autocorrectedRanges` on
`UIWKDocumentContext`, when the `UIWKDocumentRequest` has
`UIWKDocumentRequestAutocorrectedRanges` specified in its flags. Then, with the
existing properties on `UIWKDocumentContext`, UIKit can determine the corrected
string nearest to the current selection.
* Source/WebCore/dom/DocumentMarkerController.cpp:
(WebCore::DocumentMarkerController::forEach):
Pass the node into the callback function so that it may be used to obtain a
`SimpleRange` from the `DocumentMarker`.
(WebCore::DocumentMarkerController::rangesForMarkersInRange):
Return a `SimpleRange` for each `DocumentMarker`.
(WebCore::DocumentMarkerController::hasMarkers):
(WebCore::DocumentMarkerController::clearDescriptionOnMarkersIntersectingRange):
* Source/WebCore/dom/DocumentMarkerController.h:
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/Shared/DocumentEditingContext.h:
* Source/WebKit/Shared/DocumentEditingContext.mm:
(WebKit::DocumentEditingContext::toPlatformContext):
(IPC::ArgumentCoder<WebKit::DocumentEditingContext>::encode):
(IPC::ArgumentCoder<WebKit::DocumentEditingContext>::decode):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(toWebDocumentRequestOptions):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
Resolve the `SimpleRange` from each marker as a character range, using a
`SimpleRange` representing the current context.
Populate `context.autocorrectedRanges` to be sent back to the UI process and UIKit.
(WebKit::WebPage::requestDocumentEditingContext):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:
(TEST):
* Tools/TestWebKitAPI/ios/UIKitSPI.h:
Canonical link: https://commits.webkit.org/266398@main
Identifier: 265870.279 at safari-7616-branch
Commit: 9418a0bc1fa544848f135d804793655a3d5c04c6
https://github.com/WebKit/WebKit/commit/9418a0bc1fa544848f135d804793655a3d5c04c6
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm
Log Message:
-----------
Cherry-pick 29bdd50cb2d7. rdar://problem/113604753
Cherry-pick 92ab43385d57. rdar://problem/113036183
[WebKit] [iOS] Respect `NSUnderlineStyleAttributeName` when setting attributed marked text
https://bugs.webkit.org/show_bug.cgi?id=259604
rdar://113036183
Reviewed by Richard Robinson.
After the changes in rdar://108610748, UIKit will use `NSUnderlineStyle` with an attribute value of
`NSUnderlineStyleThick` to indicate "highlighted" segments of marked text when live conversion is
active. Currently, our code only checks against `NSBackgroundColor`, so without the changes in this
patch, it would no longer be possible to know which segment in marked text is the selected segment
when using live conversion.
Fix this by checking for this case, alongside the existing `NSBackgroundColor` check.
Test: KeyboardInputTests.MarkedTextSegmentsWithUnderlines
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(extractUnderlines):
* Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
Canonical link: https://commits.webkit.org/266401@main
Identifier: 265870.280 at safari-7616-branch
Commit: 0e87e437924da284ed58b3e945bc9fc795fa4d60
https://github.com/WebKit/WebKit/commit/0e87e437924da284ed58b3e945bc9fc795fa4d60
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/accessibility/display-contents/table-dynamic-expected.txt
A LayoutTests/accessibility/display-contents/table-dynamic.html
A LayoutTests/platform/glib/accessibility/display-contents/table-dynamic-expected.txt
A LayoutTests/platform/ios/accessibility/display-contents/table-dynamic-expected.txt
M Source/WebCore/accessibility/AccessibilityObject.cpp
Log Message:
-----------
Cherry-pick 4ea8758e2e4b. rdar://problem/113605361
Cherry-pick 45ff67ff20ee. rdar://problem/113044333
AX: display:contents elements are sometimes missing their children
https://bugs.webkit.org/show_bug.cgi?id=259608
rdar://problem/113044333
Reviewed by Chris Fleizach.
This happened because AccessibilityObject::insertChild detects and bails when an object is trying to insert a child
that belongs to a display:contents object that is not `this`. But if the correct parent of that child does not have
it’s dirty-children bit set, we never actually insert the child, resulting in it being missing from the accessibility
tree. With this patch, we set that bit, ensuring the accessibility tree is updated correctly.
* LayoutTests/accessibility/display-contents/table-dynamic-expected.txt: Added.
* LayoutTests/accessibility/display-contents/table-dynamic.html: Added.
* LayoutTests/platform/ios/accessibility/display-contents/table-dynamic-expected.txt: Added.
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::insertChild):
Canonical link: https://commits.webkit.org/266407@main
Identifier: 265870.281 at safari-7616-branch
Commit: dcbf5227d31675b1405cdfbe99222489d24d4e5c
https://github.com/WebKit/WebKit/commit/dcbf5227d31675b1405cdfbe99222489d24d4e5c
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/heap/GCMemoryOperations.h
Log Message:
-----------
Cherry-pick 512a8960873f. rdar://problem/113605206
Cherry-pick 8e00fd0e6445. rdar://problem/112284761
[JSC] Use 32byte stride for ARM64 gcSafe ops
https://bugs.webkit.org/show_bug.cgi?id=259226
rdar://112284761
Reviewed by Mark Lam.
This patch extends gcSafe mem ops stride from 16 to 32 bytes.
We do not use SIMD v128 etc. here for now, which could be beneficial
for more larger sized ones. We clean up these ops with prefix / postfix
increment addressing in ARM64.
* Source/JavaScriptCore/heap/GCMemoryOperations.h:
(JSC::gcSafeMemcpy):
(JSC::gcSafeMemmove):
Canonical link: https://commits.webkit.org/266079@main
Identifier: 265870.251 at safari-7616.1.27-branch
Identifier: 265870.282 at safari-7616-branch
Commit: 4ff90128cb2bd4141a28ae7822f82c99951b9edb
https://github.com/WebKit/WebKit/commit/4ff90128cb2bd4141a28ae7822f82c99951b9edb
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/runtime/ArrayPrototype.cpp
Log Message:
-----------
Cherry-pick 5815a7354215. rdar://problem/113605020
Cherry-pick 2c57997e4a9b. rdar://problem/112804277
[JSC] Use SIMD fast find64 even in normal Array#indexOf runtime function
https://bugs.webkit.org/show_bug.cgi?id=259463
rdar://112804277
Reviewed by Keith Miller and Mark Lam.
Let's just use find64 even in runtime function of Array#indexOf.
We already used this in DFG operations. We can improve startup time for lower tiers
by expanding this coverage.
* Source/JavaScriptCore/runtime/ArrayPrototype.cpp:
(JSC::fastIndexOf):
Canonical link: https://commits.webkit.org/266280@main
Identifier: 265870.253 at safari-7616.1.27-branch
Identifier: 265870.283 at safari-7616-branch
Commit: 74b6cf54b1767704f574374d526ed8f43c519b53
https://github.com/WebKit/WebKit/commit/74b6cf54b1767704f574374d526ed8f43c519b53
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick 01f29f108160. rdar://problem/113605033
Cherry-pick 78b32835554a. rdar://problem/112718525
Reduce logging volume v2
https://bugs.webkit.org/show_bug.cgi?id=259563
rdar://112978605
Reviewed by Brent Fulgham.
Further reduce logging to avoid being quarantined by the system.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::scheduleUpdatePlayState):
Canonical link: https://commits.webkit.org/266365@main
Identifier: 265870.255 at safari-7616.1.27-branch
Identifier: 265870.284 at safari-7616-branch
Commit: afc0a5742c90f823dad58320873b1f202e6b9e79
https://github.com/WebKit/WebKit/commit/afc0a5742c90f823dad58320873b1f202e6b9e79
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WTF/wtf/text/icu/TextBreakIteratorICU.h
Log Message:
-----------
Cherry-pick 96c30102ac05. rdar://problem/113604945
Cherry-pick 45a531fbee9a. rdar://problem/112426537
utext_setup() can fail
https://bugs.webkit.org/show_bug.cgi?id=259468
rdar://112426537
Reviewed by Brent Fulgham.
Simply add a null check.
We don't know of any content that can cause this, but
we are getting reports of crashes at this stack trace.
So I don't know how to make a test :(
* Source/WTF/wtf/text/icu/TextBreakIteratorICU.h:
(WTF::TextBreakIteratorICU::TextBreakIteratorICU):
(WTF::TextBreakIteratorICU::operator=):
(WTF::TextBreakIteratorICU::setText):
Canonical link: https://commits.webkit.org/266388@main
Identifier: 265870.256 at safari-7616.1.27-branch
Identifier: 265870.285 at safari-7616-branch
Commit: 6697a49ad9008a7e44a020115e4d4857e7e9c6b0
https://github.com/WebKit/WebKit/commit/6697a49ad9008a7e44a020115e4d4857e7e9c6b0
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M LayoutTests/accessibility/text-marker/text-marker-range-with-unordered-markers-expected.txt
M LayoutTests/accessibility/text-marker/text-marker-range-with-unordered-markers.html
A LayoutTests/platform/glib/accessibility/text-marker/text-marker-range-with-unordered-markers-expected.txt
A LayoutTests/platform/ios/accessibility/text-marker/text-marker-range-with-unordered-markers-expected.txt
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/accessibility/AXTextMarker.cpp
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
M Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp
M Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h
M Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl
M Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm
Log Message:
-----------
Cherry-pick 9adbd7779e9c. rdar://problem/113605371
Cherry-pick 52903644b8d3. rdar://problem/112193520
VO interacts with the element containing the app selection instead of with VO's current element.
https://bugs.webkit.org/show_bug.cgi?id=259629
rdar://112193520
Reviewed by Chris Fleizach.
VoiceOver uses the AXTextMarkerRangeForUnorderedTextMarkersAttribute to decide which element to interact with when the user presses VO Shift Down Arrow. This API failed when one of the TextMarker parameters was created off the main thread and thus has a null Node*. This patch fixes the issue by having a single implementation for both AXTextMarkerRangeForUnorderedTextMarkers and AXTextMarkerRangeForTextMarkers that supports unordered TextMarkers.
Added WTR::AccessibilityUIElement::textMarkerRangeForUnorderedMarkers and a test case for this API.
* LayoutTests/accessibility/text-marker/text-marker-range-with-unordered-markers-expected.txt:
* LayoutTests/accessibility/text-marker/text-marker-range-with-unordered-markers.html:
* LayoutTests/platform/glib/accessibility/text-marker/text-marker-range-with-unordered-markers-expected.txt: Added.
* LayoutTests/platform/ios/accessibility/text-marker/text-marker-range-with-unordered-markers-expected.txt: Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::partialOrder):
* Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):
* Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:
(WTR::AccessibilityUIElement::textMarkerRangeForUnorderedMarkers):
* Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
* Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
* Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:
(WTR::AccessibilityUIElement::textMarkerRangeForUnorderedMarkers):
Canonical link: https://commits.webkit.org/266417@main
Identifier: 265870.257 at safari-7616.1.27-branch
Identifier: 265870.286 at safari-7616-branch
Commit: 106a0f25f6abb86bdb74365544d2cc2cf68fead5
https://github.com/WebKit/WebKit/commit/106a0f25f6abb86bdb74365544d2cc2cf68fead5
Author: Brady Eidson <beidson at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.cpp
M Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.h
Log Message:
-----------
Cherry-pick 795de3f24f92. rdar://problem/113604913
Cherry-pick e50b54c0585e. rdar://problem/112721318
DNSServiceRef can outlive its socket connection to mDNS, causing blocked threads in Networking
rdar://112721318
https://bugs.webkit.org/show_bug.cgi?id=259636
Reviewed by Youenn Fablet.
Be sure to tear down the DNSServiceRef and remove it from our set when error conditions occur.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
(WebKit::NetworkConnectionToWebProcess::mdnsRegister):
* Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.cpp:
(WebKit::PendingRegistrationRequest::PendingRegistrationRequest):
(WebKit::NetworkMDNSRegister::closeAndForgetService):
(WebKit::registerMDNSNameCallback):
(WebKit::NetworkMDNSRegister::registerMDNSName):
* Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.h:
Canonical link: https://commits.webkit.org/266420@main
Identifier: 265870.259 at safari-7616.1.27-branch
Identifier: 265870.287 at safari-7616-branch
Commit: 38fe27295c6b281c9511d34690c3756748dcedd5
https://github.com/WebKit/WebKit/commit/38fe27295c6b281c9511d34690c3756748dcedd5
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp
Log Message:
-----------
Cherry-pick dd54273cbf09. rdar://problem/113605288
Cherry-pick 10dac7db6a0e. rdar://problem/112186984
[JSC] Convert MakeRope to MakeAtomString for HasOwnProperty key in DFG
https://bugs.webkit.org/show_bug.cgi?id=259182
rdar://112186984
Reviewed by Michael Saboff.
As the same to GetById etc., we should convert MakeRope to MakeAtomString for HasOwnProperty key
since it always gets atomization.
* Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
Canonical link: https://commits.webkit.org/266042@main
Identifier: 265870.260 at safari-7616.1.27-branch
Identifier: 265870.288 at safari-7616-branch
Commit: 898a2afff44b156fbe9cb3783d630519909277e0
https://github.com/WebKit/WebKit/commit/898a2afff44b156fbe9cb3783d630519909277e0
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/fullscreen/fullscreen-no-scrollbars-on-ancestor-root-expected.html
A LayoutTests/fullscreen/fullscreen-no-scrollbars-on-ancestor-root.html
M Source/WebCore/css/SelectorCheckerTestFunctions.h
Log Message:
-----------
Cherry-pick 61c9c3d67b47. rdar://problem/113605155
Cherry-pick 0d8538115ee0. rdar://problem/108096981
REGRESSION(257456 at main): Scrollbar shows up on sites that initiate fullscreen from an iframe
https://bugs.webkit.org/show_bug.cgi?id=255197
rdar://108096981
Reviewed by Simon Fraser.
The following UA stylesheet rule was not applying:
```
:root:-webkit-full-screen-document:not(:fullscreen) {
overflow: hidden !important;
}
```
because :-webkit-full-screen-document used isFullscreen() (exposed as a legacy API), did not take in account documents fullscreened implicitly by their child frame.
Switch to fullscreenElement() which queries from the top layer, and includes implicitly fullscreened elements.
* LayoutTests/fullscreen/fullscreen-no-scrollbars-on-ancestor-root-expected.html: Added.
* LayoutTests/fullscreen/fullscreen-no-scrollbars-on-ancestor-root.html: Added.
* Source/WebCore/css/SelectorCheckerTestFunctions.h:
(WebCore::matchesFullScreenDocumentPseudoClass):
Canonical link: https://commits.webkit.org/266340@main
Identifier: 265870.261 at safari-7616.1.27-branch
Identifier: 265870.289 at safari-7616-branch
Commit: 1da5d22953c19d6416d71ccbc35ffcce0eee88d5
https://github.com/WebKit/WebKit/commit/1da5d22953c19d6416d71ccbc35ffcce0eee88d5
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M LayoutTests/fast/selectors/style-invalidation-hover-change-descendants-expected.txt
M LayoutTests/fast/selectors/style-invalidation-hover-change-descendants.html
M LayoutTests/fast/selectors/style-invalidation-hover-change-siblings-expected.txt
M LayoutTests/fast/selectors/style-invalidation-hover-change-siblings.html
M Source/WebKit/Shared/WebEvent.h
A Source/WebKit/Shared/WebEventType.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm
M Tools/WebKitTestRunner/InjectedBundle/EventSendingController.cpp
M Tools/WebKitTestRunner/TestController.cpp
Log Message:
-----------
Cherry-pick 25d9ab78850a. rdar://problem/113605263
Cherry-pick a10c4813fe62. rdar://problem/110921187
Throttle `mousemove` events to one per rendering update
https://bugs.webkit.org/show_bug.cgi?id=259408
rdar://110921187
Reviewed by Tim Horton and Simon Fraser.
Throttle the mousemove event dispatch rate to a maximum of 1 per rendering update, if the user isn't
clicking or dragging. See below for more details.
Test: MouseEventTests.CoalesceMouseMoveEvents
MouseEventTests.ProcessSwapWithDeferredMouseMoveEventCompletion
* LayoutTests/fast/selectors/style-invalidation-hover-change-descendants-expected.txt:
* LayoutTests/fast/selectors/style-invalidation-hover-change-descendants.html:
* LayoutTests/fast/selectors/style-invalidation-hover-change-siblings-expected.txt:
* LayoutTests/fast/selectors/style-invalidation-hover-change-siblings.html:
Adjust a couple of layout tests that need to run checks for style invalidation state immediately
after handling the mousemove event, without waiting for any further IPC messages to be dispatched.
Ensure this by moving the test logic into one-shot `mousemove` event listeners; we also take the
opportunity to modernize the test a bit by using `js-test.js` and `testPassed` / `testFailed`.
* Source/WebKit/Shared/WebEvent.h:
* Source/WebKit/Shared/WebEventType.h: Copied from Source/WebKit/Shared/WebEvent.h.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::handleMouseEvent):
See comments under `WebPage::mouseEvent`.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKBundlePageFlushDeferredDidReceiveMouseEventForTesting):
Add a testing-only SPI hook to flush the `DidReceiveEvent` message corresponding to any `mousemove`
events that have already been handled in the web process. WebKitTestRunner uses this to ensure that
`window.eventSender` API to simulate mouse events behaves the same way as it currently does.
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close):
(WebKit::WebPage::suspendForProcessSwap):
Flush any deferred `mousemove` IPC responses here when suspending right before a process swap, so
that we won't end up trying to send a `DidReceiveEvent` message back to the UI process when the
`WebPageProxy`'s `mouseEventQueue` has already been emptied, due to process swapping.
(WebKit::WebPage::mouseEvent):
When handling a `mousemove` event, rather than invoke the IPC completion handler immediately, we
instead defer the call to `WebPageProxy::DidReceiveEvent` until the end of the current rendering
update. This means that existing UI-side logic for coalescing `mousemove` events when the web
process is still handling mouse events will coalesce mousemove events until the end of the rendering
update, after which the web process will be done with current mousemove.
If a non-`mousemove` event enters the mouse event queue), we'll also tell the web process to
dispatch the deferred mousemove completion handler early so that we can process the incoming click
right away.
(WebKit::WebPage::flushDeferredDidReceiveMouseEvent):
(WebKit::WebPage::finalizeRenderingUpdate):
Clear out `m_deferredDidReceiveMouseEvent` if it was set, and dispatch the `DidReceiveEvent` message
back to the UI process for this deferred event.
(WebKit::WebPage::didCommitLoad):
Similarly, flush any deferred `DidReceiveEvent` response when committing a load.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm: Added.
Add an API test to exercise `mousemove` event coalescing (both this new completion deferral, as well
as the preexisting mechanism for coalescing events in the UI process). This test simulates moving a
mouse cursor over (300, 300) in the window, clicking, and then verifies that:
1. There are at least 4 mouse events observed: a `mousemove` for the starting location, another
`mousemove` for the final destination, and `mousedown` and `mouseup` events for the click.
2. There are no more than 200 events in total (in other words, some `mousemove` events were
coalesced).
Also, add an API test to verify that we don't hit a `MESSAGE_CHECK` due to sending a deferred
`mousemove` event completion message during a process swap.
* Tools/WebKitTestRunner/InjectedBundle/EventSendingController.cpp:
(WTR::EventSendingController::mouseMoveTo):
Use the above testing hook. We also wait for one extra web <-> UI process round trip here in order
to ensure that the UI process has received the message from the web process indicating that we've
handled the `mousemove` event.
* Tools/WebKitTestRunner/TestController.cpp:
(WTR::TestController::didReceiveSynchronousMessageFromInjectedBundle):
Canonical link: https://commits.webkit.org/266341@main
Identifier: 265870.262 at safari-7616.1.27-branch
Identifier: 265870.290 at safari-7616-branch
Commit: 7d3c21906d8179ee87fd67befda7caf8e45beb03
https://github.com/WebKit/WebKit/commit/7d3c21906d8179ee87fd67befda7caf8e45beb03
Author: Dan Glastonbury <djg at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/ThirdParty/ANGLE/changes.diff
M Source/ThirdParty/ANGLE/src/libANGLE/features.h
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ContextMtl.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/DisplayMtl.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.h
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.mm
Log Message:
-----------
Cherry-pick 3820b42a1a38. rdar://problem/113604792
Cherry-pick ef391b1f467b. rdar://problem/109176858
[ANGLE] Lose Metal-backed contexts
https://bugs.webkit.org/show_bug.cgi?id=257584
rdar://109176858
Reviewed by Dean Jackson.
ANGLE provides a mechanism for determing if there has been a error with the
renderer backend via the DisplayImpl::testDeviceLost() and
ContextImpl::getResetStatus() APIs. The Metal renderer backend never signals an
error.
Metal provides a status on command buffer completion to signal if there has been
an error when processing a MTLCommandBuffer. This patch adds experimental
support for losing the context when this status signals there was an error. The
context can't be recovered once it is lost and needs to be recreated.
The feature is available when ANGLE_METAL_LOSE_CONTEXT_ON_ERROR is defined when
compiling ANGLE.
* Source/ThirdParty/ANGLE/src/libANGLE/features.h:
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/DisplayMtl.mm:
(rx::DisplayMtl::testDeviceLost):
(rx::DisplayMtl::restoreLostDevice):
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.h:
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.mm:
(rx::mtl::CommandQueue::onCommandBufferCompleted):
Canonical link: https://commits.webkit.org/266377@main
Identifier: 265870.264 at safari-7616.1.27-branch
Identifier: 265870.291 at safari-7616-branch
Commit: 4774b4989320f898570d7b81bbcb625a1c516ec1
https://github.com/WebKit/WebKit/commit/4774b4989320f898570d7b81bbcb625a1c516ec1
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/accessibility/mac/text-marker-range-selection-in-list-items-expected.txt
A LayoutTests/accessibility/mac/text-marker-range-selection-in-list-items.html
M Source/WebCore/accessibility/AccessibilityObject.cpp
Log Message:
-----------
Cherry-pick 3569143c6cc4. rdar://problem/113604890
Cherry-pick 61c2f70daad1. rdar://problem/112085797
AX: Unexpected speech synthesis behavior for unordered lists
https://bugs.webkit.org/show_bug.cgi?id=259030
rdar://112085797
Reviewed by Chris Fleizach.
As noted in the FIXME comment in AccessibilityObject::stringForRange, passing the original range.start to listMarkerTextForNodeAndPosition() is incorrect and it.range.start() should be passed instead. This solves the problem of list markers getting inserted in the middle of list item text when the <li> element contains children like in item3 of the layout test.
The new layout test exercises setting and retrieving selection in list items, coverage that was missing in the test suite.
In addition, listMarkerTextForNodeAndPosition(...) was optimized to avoid walking up the RenderObject hierarchy twice unnecessarily for list items. Some code cleanup.
* LayoutTests/accessibility/mac/text-marker-range-selection-in-list-items-expected.txt: Added.
* LayoutTests/accessibility/mac/text-marker-range-selection-in-list-items.html: Added.
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::renderListItemContainerForNode):
(WebCore::AccessibilityObject::listMarkerTextForNodeAndPosition):
(WebCore::AccessibilityObject::stringForRange const):
(WebCore::listMarkerTextForNode): Deleted.
Canonical link: https://commits.webkit.org/266383@main
Identifier: 265870.265 at safari-7616.1.27-branch
Identifier: 265870.292 at safari-7616-branch
Commit: 8be8f84814e4ab7ed4aef6dce6fbce74cd4ff6d2
https://github.com/WebKit/WebKit/commit/8be8f84814e4ab7ed4aef6dce6fbce74cd4ff6d2
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A JSTests/microbenchmarks/string-index-of-simple.js
A JSTests/stress/string-index-of.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/dfg/DFGClobberize.h
M Source/JavaScriptCore/dfg/DFGDoesGC.cpp
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/dfg/DFGGraph.cpp
M Source/JavaScriptCore/dfg/DFGGraph.h
M Source/JavaScriptCore/dfg/DFGNodeType.h
M Source/JavaScriptCore/dfg/DFGOperations.cpp
M Source/JavaScriptCore/dfg/DFGOperations.h
M Source/JavaScriptCore/dfg/DFGPredictionPropagationPhase.cpp
M Source/JavaScriptCore/dfg/DFGSafeToExecute.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLCapabilities.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/runtime/ArrayPrototype.cpp
M Source/JavaScriptCore/runtime/Intrinsic.h
M Source/JavaScriptCore/runtime/StringPrototype.cpp
Log Message:
-----------
Cherry-pick ef22baba0026. rdar://problem/113604998
Cherry-pick e11f24560f60. rdar://problem/112168244
[JSC] DFG should handle String#indexOf
https://bugs.webkit.org/show_bug.cgi?id=259169
rdar://112168244
Reviewed by Mark Lam.
This patch adds StringIndexOf direct handling in DFG and FTL by introducing StringIndexOf DFG node.
ToT Patched
string-index-of-simple 314.0151+-1.6873 ^ 292.0551+-1.7146 ^ definitely 1.0752x faster
* JSTests/microbenchmarks/string-index-of-simple.js: Added.
(shouldBe):
(test0):
(test1):
(test2):
(test3):
(test4):
(test5):
* JSTests/stress/string-index-of.js: Added.
(shouldBe):
(test0):
(test1):
(test2):
(test3):
(test4):
(test5):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* Source/JavaScriptCore/dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* Source/JavaScriptCore/dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryAddStringSearchTable8):
* Source/JavaScriptCore/dfg/DFGGraph.h:
* Source/JavaScriptCore/dfg/DFGNodeType.h:
* Source/JavaScriptCore/dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* Source/JavaScriptCore/dfg/DFGOperations.h:
* Source/JavaScriptCore/dfg/DFGPredictionPropagationPhase.cpp:
* Source/JavaScriptCore/dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* Source/JavaScriptCore/ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileStringIndexOf):
* Source/JavaScriptCore/runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* Source/JavaScriptCore/runtime/Intrinsic.h:
* Source/JavaScriptCore/runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
Canonical link: https://commits.webkit.org/266027@main
Identifier: 265870.269 at safari-7616.1.27-branch
Identifier: 265870.293 at safari-7616-branch
Commit: 4c6046fc92c3f7c21b6b150b19e2f97363a91c1d
https://github.com/WebKit/WebKit/commit/4c6046fc92c3f7c21b6b150b19e2f97363a91c1d
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/jit/AssemblyHelpers.cpp
M Source/JavaScriptCore/jit/AssemblyHelpers.h
M Source/JavaScriptCore/jit/JITOpcodes.cpp
Log Message:
-----------
Cherry-pick 19a205366d53. rdar://problem/113605330
Cherry-pick 00e61ef559b5. rdar://problem/113143403
[JSC] Squeeze object allocation JIT code
https://bugs.webkit.org/show_bug.cgi?id=259151
rdar://112145626
Reviewed by Mark Lam.
1. Use stp to update FreeList's data.
2. Avoid unnecessary instructions (null clear) for most of cases by passing SlowAllocationResult enum.
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
(JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileNewBoundFunction):
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
(JSC::AssemblyHelpers::emitAllocate):
(JSC::AssemblyHelpers::emitAllocateVariableSized):
* Source/JavaScriptCore/jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateJSCell):
(JSC::AssemblyHelpers::emitAllocateJSObject):
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
(JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
* Source/JavaScriptCore/jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emit_op_create_this):
Canonical link: https://commits.webkit.org/266010@main
Identifier: 265870.277 at safari-7616.1.27.10-branch
Identifier: 265870.294 at safari-7616-branch
Commit: dab15bb32e97ce452ddd69a2e2cb326e8706bd7f
https://github.com/WebKit/WebKit/commit/dab15bb32e97ce452ddd69a2e2cb326e8706bd7f
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A JSTests/stress/rope-resolve-recursive-non-ascii.js
A JSTests/stress/rope-resolve-recursive.js
A JSTests/stress/three-rope-non-ascii.js
A JSTests/stress/three-rope.js
A JSTests/stress/two-rope-non-ascii.js
A JSTests/stress/two-rope.js
M Source/JavaScriptCore/runtime/JSString.cpp
M Source/JavaScriptCore/runtime/JSString.h
M Source/JavaScriptCore/runtime/JSStringInlines.h
Log Message:
-----------
Cherry-pick 26adcb4a709b. rdar://problem/113605325
Cherry-pick 9c5c2c9fc89f. rdar://problem/113143401
[JSC] JSRopeString::resolveToBuffer should have fast path for two rope+non-rope case
https://bugs.webkit.org/show_bug.cgi?id=259176
rdar://112178098
Reviewed by Michael Saboff.
JSRopeString can have three fibers. But we observed two fibers case, where only one is a rope, very commonly.
This happens when you write code like this,
var string = '';
for (var i = 0; i < 1e6; ++i)
string += char
Then, the resulted string becomes two fibers rope, only left hand side gets super deep.
We can handle this string, just recursively handle the left side (via tail-call), but just spreading the right side.
This patch changes JSRopeString::resolveToBuffer to handle this kind of patterns efficiently. We carefully crafted this
code so that the above pattern becomes repeated tail call to JSRopeString::resolveToBuffer. We also have sp checker so that
this code works perfectly well even if the compiler is not supporting tail-calls (at some level, we stop and use slow-but-works mode).
* Source/JavaScriptCore/runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeInternalNoSubstring const):
(JSC::JSRopeString::resolveRopeToAtomString const):
(JSC::JSRopeString::resolveRopeToExistingAtomString const):
(JSC::JSRopeString::resolveRopeWithFunction const):
* Source/JavaScriptCore/runtime/JSString.h:
* Source/JavaScriptCore/runtime/JSStringInlines.h:
(JSC::JSRopeString::resolveToBuffer):
(JSC::jsAtomString):
Canonical link: https://commits.webkit.org/266028@main
Identifier: 265870.278 at safari-7616.1.27.10-branch
Identifier: 265870.295 at safari-7616-branch
Commit: db904bb9de3d6bdd98b0f99b076366af99ed88d9
https://github.com/WebKit/WebKit/commit/db904bb9de3d6bdd98b0f99b076366af99ed88d9
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A JSTests/stress/string-from-char-code-double.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGClobberize.h
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 73b00a17177f. rdar://problem/113605195
Cherry-pick 5d994adeb6a3. rdar://problem/113143381
[JSC] Handle String.fromCharCode(double) in DFG
https://bugs.webkit.org/show_bug.cgi?id=259207
rdar://112245867
Reviewed by Mark Lam.
String.fromCharCode will perform toUInt32 onto the input. So we can just use existing mechanism (DFG's ValueToInt32)
to accept it even if the input is double.
* JSTests/stress/string-from-char-code-double.js: Added.
(shouldBe):
(test):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
Canonical link: https://commits.webkit.org/266056@main
Identifier: 265870.279 at safari-7616.1.27.10-branch
Identifier: 265870.296 at safari-7616-branch
Commit: 7f30af5f4dfb3e247cb97f9172940595f545f521
https://github.com/WebKit/WebKit/commit/7f30af5f4dfb3e247cb97f9172940595f545f521
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A JSTests/microbenchmarks/rope-resolve-recursive.js
M Source/JavaScriptCore/runtime/JSString.cpp
M Source/JavaScriptCore/runtime/JSString.h
M Source/JavaScriptCore/runtime/JSStringInlines.h
M Source/WTF/wtf/Compiler.h
Log Message:
-----------
Cherry-pick 7d8ffa57102b. rdar://problem/113605053
Cherry-pick 4d816460b765. rdar://problem/113143358
[JSC] Further optimize JSRopeString::resolveRope
https://bugs.webkit.org/show_bug.cgi?id=259203
rdar://112241674
Reviewed by Mark Lam.
This patch furhter improves JSRopeString::resolveRope and jsAtomString.
1. We crafted JSRopeString::resolveToBuffer very carefully so that it becomes tail calls well.
This allows clang to make it loop instead of calls for recursive resolveToBuffer calls, which
is significantly efficient. We ensure this condition is met by using MUST_TAIL_CALL C++ attribute,
which is available in clang.
2. We tweak jsAtomString to make it better in terms of performance. It turned out these duplicate part
is mandatory to make it super efficient, which is observed by JetStream2/WSL.
Simple rope resolution gets 3-4% improvement.
ToT Patched
rope-resolve-recursive 21.3292+-0.6975 ^ 20.5524+-0.0687 ^ definitely 1.0378x faster
* Source/JavaScriptCore/runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeInternalNoSubstring const):
* Source/JavaScriptCore/runtime/JSString.h:
* Source/JavaScriptCore/runtime/JSStringInlines.h:
(JSC::JSRopeString::resolveToBufferSlow):
(JSC::JSRopeString::resolveToBuffer):
(JSC::jsAtomString):
(JSC::JSStringFibers::JSStringFibers): Deleted.
(JSC::JSStringFibers::fiber const): Deleted.
(JSC::JSStringFibers::fiber0 const): Deleted.
(JSC::JSStringFibers::fiber1 const): Deleted.
(JSC::JSStringFibers::fiber2 const): Deleted.
(): Deleted.
* Source/WTF/wtf/Compiler.h:
Canonical link: https://commits.webkit.org/266060@main
Identifier: 265870.280 at safari-7616.1.27.10-branch
Identifier: 265870.297 at safari-7616-branch
Commit: 061c7ff918aea2a1762b2a059b829a527da58512
https://github.com/WebKit/WebKit/commit/061c7ff918aea2a1762b2a059b829a527da58512
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/JavaScriptCore/runtime/PropertyName.h
Log Message:
-----------
Cherry-pick 00ae0650b862. rdar://problem/113605152
Cherry-pick 7b6f95072a21. rdar://problem/113143380
[JSC] Early return from isCanonicalNumericIndexString when it is definitely not a number
https://bugs.webkit.org/show_bug.cgi?id=259230
rdar://112292849
Reviewed by Alexey Shvayka.
This patch makes isCanonicalNumericIndexString early return for obvious non number cases
so that we avoid super costly number-to-string & string-to-number path.
* Source/JavaScriptCore/runtime/PropertyName.h:
(JSC::isCanonicalNumericIndexString):
Canonical link: https://commits.webkit.org/266080@main
Identifier: 265870.281 at safari-7616.1.27.10-branch
Identifier: 265870.298 at safari-7616-branch
Commit: f14b7f6039370632ade167c79b6951cb360a95f5
https://github.com/WebKit/WebKit/commit/f14b7f6039370632ade167c79b6951cb360a95f5
Author: Razvan Caliman <rcaliman at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js
Log Message:
-----------
Cherry-pick abeabe233180. rdar://problem/113604959
Cherry-pick 48da5f9506d1. rdar://problem/112984488
Uncaught Exception: TypeError: undefined is not an object (evaluating 'this.contentBrowser.currentContentView')
https://bugs.webkit.org/show_bug.cgi?id=259566
rdar://112984488
Reviewed by Devin Rousso.
* Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js:
(WI.SourcesNavigationSidebarPanel.prototype._handleResourceGroupingModeChanged):
Canonical link: https://commits.webkit.org/266428@main
Identifier: 265870.283 at safari-7616.1.27.11-branch
Identifier: 265870.299 at safari-7616-branch
Commit: c22e3907a27b9f67a381d907d46a724f136eeff4
https://github.com/WebKit/WebKit/commit/c22e3907a27b9f67a381d907d46a724f136eeff4
Author: Kyle Piddington <kpiddington at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 781cdefc43c2. rdar://problem/113605138
Cherry-pick b258292b1506. rdar://problem/112819533
Dont build default.metallib when building ANGLE
https://bugs.webkit.org/show_bug.cgi?id=259509
<rdar://112819533>
Reviewed by Alex Christensen.
The autogenerated metal file was accidently included as a
build target in ANGLE's default shared library. It's previously
been compiled in a seperate project that builds to
"ANGLEMetalLib.metallib". After the last ANGLE roll,
it was building to both "default.metallib" and 'ANGLEMetalLib.metallib'
This change restores the previous behavior for this library.
* Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/266307@main
Identifier: 265870.300 at safari-7616-branch
Commit: cf447bc63f7cd15e98c76daaeca341da3986d36e
https://github.com/WebKit/WebKit/commit/cf447bc63f7cd15e98c76daaeca341da3986d36e
Author: Commit Queue <commit-queue at webkit.org>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
R LayoutTests/fast/forms/label/label-selection-expected.txt
R LayoutTests/fast/forms/label/label-selection.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/html/HTMLLabelElement.cpp
Log Message:
-----------
Cherry-pick 6595f7362fd5. rdar://problem/113605167
Cherry-pick a799925247d5. rdar://problem/112973142
Unreviewed, reverting 263420 at main.
https://bugs.webkit.org/show_bug.cgi?id=259558
'caused WPT regression in test *proxy-modifier-click-to-associated-element.tentative.html'*
Reverted changeset:
"Cannot select text within a label element that is linked to an input field"
https://bugs.webkit.org/show_bug.cgi?id=96734
https://commits.webkit.org/263420@main
Canonical link: https://commits.webkit.org/266356@main
Identifier: 265870.281 at safari-7616.1.27.13-branch
Identifier: 265870.301 at safari-7616-branch
Commit: bc89993f97472cae335dc78c477557287f918053
https://github.com/WebKit/WebKit/commit/bc89993f97472cae335dc78c477557287f918053
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm
Log Message:
-----------
Cherry-pick 651b005b2ef7. rdar://problem/113605100
Cherry-pick 4f26424a4687. rdar://problem/113060681
REGRESSION (266341 at main): mousemove no longer dispatched when UI-side compositing is disabled
https://bugs.webkit.org/show_bug.cgi?id=259618
Reviewed by Aditya Keerthi.
After the changes in 266341 at main, when UI-side compositing is disabled, we can end up in a state where mouse events are
indefinitely queued in the UI process, as the web process never flushes the deferred DidReceiveEvent message for a
mousemove event that has already been handled. This is because `TiledCoreAnimationDrawingArea::scheduleRenderingUpdate`
is unimplemented, and so nothing guarantees that we'll eventually send the deferred `DidReceiveEvent` back to the UI
process.
Fix this by avoiding the deferred `DidReceiveEvent` if `scheduleRenderingUpdate()` returns `false` (indicating that no
rendering update is scheduled). In practice, this effectively disables the changes in 266341 at main unless we're using a
remote layer tree drawing area, which is now the default on both macOS Sonoma (in most device models) and iOS 17, which
enable UI-side compositing.
Test: MouseEventTests.SendMouseMoveEventStream
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::mouseEvent):
* Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm:
Canonical link: https://commits.webkit.org/266411@main
Identifier: 265870.285 at safari-7616.1.27.13-branch
Identifier: 265870.302 at safari-7616-branch
Commit: 80520146c02df3948a94cce521598e817248eb38
https://github.com/WebKit/WebKit/commit/80520146c02df3948a94cce521598e817248eb38
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/html/HTMLCanvasElement.h
M Source/WebCore/html/canvas/CanvasStyle.cpp
Log Message:
-----------
Cherry-pick 3fc65eb2fc83. rdar://problem/113605017
Cherry-pick 5ec234192a2e. rdar://problem/112439220
Avoid creating a new CSSParserContext each time a color is assigned to fillStyle/strokeStyle on a canvas context
https://bugs.webkit.org/show_bug.cgi?id=259431
rdar://112439220
Reviewed by Tim Nguyen.
Creating the CSSParserContext is slightly expensive, since it fetches all of the relevant document Settings.
* Source/WebCore/html/HTMLCanvasElement.h:
(WebCore::HTMLCanvasElement::cssParserContext):
* Source/WebCore/html/canvas/CanvasStyle.cpp:
(WebCore::parseColor):
Canonical link: https://commits.webkit.org/266238@main
Identifier: 265423.734 at safari-7616.1.27.12-branch
Identifier: 265870.303 at safari-7616-branch
Commit: fbb6e1a151c877f28dbbc5eabd5939fce121b22d
https://github.com/WebKit/WebKit/commit/fbb6e1a151c877f28dbbc5eabd5939fce121b22d
Author: Ryan Reno <rreno at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WTF/wtf/MemoryPressureHandler.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick da6e0c826ac7. rdar://problem/113604761
Cherry-pick 8299d7639dd9. rdar://problem/109875865
Change compositing policy in response to memory pressure status
https://bugs.webkit.org/show_bug.cgi?id=259580
rdar://109875865
Reviewed by Simon Fraser.
We switch to a more conservative compositing policy when the
MemoryPressureHandler has a change in memory usage policy at most every
2 seconds. In some cases we can enter memory warning and critical memory
pressure situations and get a foreground jetsam before this 2s has
expired. This change will respond to recent memory warning and memory
pressure notifications in order to change the compositing policy. While we
can't guarantee to not jetsam, this does improve our chances of
reducing layer counts before the system gets critically low on
memory.
* Source/WTF/wtf/MemoryPressureHandler.h:
(WTF::MemoryPressureHandler::isUnderMemoryWarning const):
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateCompositingPolicy):
Canonical link: https://commits.webkit.org/266497@main
Identifier: 265870.289 at safari-7616.1.27.10-branch
Identifier: 265870.304 at safari-7616-branch
Commit: 1173f353b4568cefe0e10c08bb5df9c6a7ead76a
https://github.com/WebKit/WebKit/commit/1173f353b4568cefe0e10c08bb5df9c6a7ead76a
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/WebFullScreenManagerProxy.cpp
M Source/WebKit/UIProcess/WebFullScreenManagerProxy.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp
M Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
Log Message:
-----------
Cherry-pick d9a11999a3bb. rdar://problem/113604739
Cherry-pick 20b21450ef4d. rdar://problem/113308053
[Cocoa] Add logging for Element Fullscreen path inside WebKit
https://bugs.webkit.org/show_bug.cgi?id=259761
rdar://113308053
Reviewed by Simon Fraser.
Add LoggerHelper-style logging to WebFullScreenManager, WebFullScreenManagerProxy,
and WKFullScreenWindowController (iOS).
Drive-by Fix: Ensure the WebPage parameter to the WebFullScreenManagerProxy::create()
method is non-null by making it a reference (&) rather than pointer (*).
* Source/WebKit/UIProcess/WebFullScreenManagerProxy.cpp:
(WebKit::WebFullScreenManagerProxy::WebFullScreenManagerProxy):
(WebKit::WebFullScreenManagerProxy::willEnterFullScreen):
(WebKit::WebFullScreenManagerProxy::didEnterFullScreen):
(WebKit::WebFullScreenManagerProxy::willExitFullScreen):
(WebKit::WebFullScreenManagerProxy::didExitFullScreen):
(WebKit::WebFullScreenManagerProxy::requestRestoreFullScreen):
(WebKit::WebFullScreenManagerProxy::requestExitFullScreen):
(WebKit::WebFullScreenManagerProxy::logChannel const):
* Source/WebKit/UIProcess/WebFullScreenManagerProxy.h:
(WebKit::WebFullScreenManagerProxy::logger const):
(WebKit::WebFullScreenManagerProxy::logIdentifier const):
(WebKit::WebFullScreenManagerProxy::logClassName const):
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(WTF::LogArgument<WebKit::FullScreenState>::toString):
(-[WKFullScreenWindowController initWithWebView:]):
(-[WKFullScreenWindowController enterFullScreen:]):
(-[WKFullScreenWindowController beganEnterFullScreenWithInitialFrame:finalFrame:]):
(-[WKFullScreenWindowController requestRestoreFullScreen]):
(-[WKFullScreenWindowController requestExitFullScreen]):
(-[WKFullScreenWindowController exitFullScreen]):
(-[WKFullScreenWindowController beganExitFullScreenWithInitialFrame:finalFrame:]):
(-[WKFullScreenWindowController _completedExitFullScreen]):
(-[WKFullScreenWindowController close]):
(-[WKFullScreenWindowController webViewDidRemoveFromSuperviewWhileInFullscreen]):
(-[WKFullScreenWindowController didEnterPictureInPicture]):
(-[WKFullScreenWindowController didExitPictureInPicture]):
(-[WKFullScreenWindowController _exitFullscreenImmediately]):
(-[WKFullScreenWindowController _startToDismissFullscreenChanged:]):
(-[WKFullScreenWindowController _dismissFullscreenViewController]):
(-[WKFullScreenWindowController _interactiveDismissChanged:]):
(-[WKFullScreenWindowController _interactivePinchDismissChanged:]):
(-[WKFullScreenWindowController _configureSpatialFullScreenTransition]):
(-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
(-[WKFullScreenWindowController logIdentifier]):
(-[WKFullScreenWindowController loggerPtr]):
(-[WKFullScreenWindowController logChannel]):
* Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.cpp:
(WebKit::WebFullScreenManager::create):
(WebKit::WebFullScreenManager::WebFullScreenManager):
(WebKit::WebFullScreenManager::invalidate):
(WebKit::WebFullScreenManager::videoControlsManagerDidChange):
(WebKit::WebFullScreenManager::setPIPStandbyElement):
(WebKit::WebFullScreenManager::supportsFullScreen):
(WebKit::WebFullScreenManager::enterFullScreenForElement):
(WebKit::WebFullScreenManager::exitFullScreenForElement):
(WebKit::WebFullScreenManager::willEnterFullScreen):
(WebKit::WebFullScreenManager::didEnterFullScreen):
(WebKit::WebFullScreenManager::willExitFullScreen):
(WebKit::WebFullScreenManager::didExitFullScreen):
(WebKit::WebFullScreenManager::requestRestoreFullScreen):
(WebKit::WebFullScreenManager::requestExitFullScreen):
(WebKit::WebFullScreenManager::close):
(WebKit::WebFullScreenManager::logChannel const):
* Source/WebKit/WebProcess/FullScreen/WebFullScreenManager.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::fullScreenManager):
Canonical link: https://commits.webkit.org/266541@main
Identifier: 265870.290 at safari-7616.1.27.10-branch
Identifier: 265870.305 at safari-7616-branch
Commit: 4d5d1fc85839e84f056d3009cedd2ac2e5145db2
https://github.com/WebKit/WebKit/commit/4d5d1fc85839e84f056d3009cedd2ac2e5145db2
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemPreview.mm
Log Message:
-----------
Cherry-pick 248f893713f3. rdar://problem/113604853
Cherry-pick 416f2342d7bf. rdar://problem/110978209
AR issues. Right after opening the USDZ and GLB file in the browser, it closes itself
https://bugs.webkit.org/show_bug.cgi?id=259670
rdar://110978209
Reviewed by Tim Horton.
We tightened the list of MIME types we accepted in ARQL during
the past year. Unfortunately still many servers are not configured
to send USD with the correct type, so we need to relax the list
a bit. For now, we'll add "application/octet-stream".
Added a new API test for this case.
* Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemPreview.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/266462@main
Identifier: 265870.291 at safari-7616.1.27.10-branch
Identifier: 265870.306 at safari-7616-branch
Commit: a58093a545495bfe36de69a672d57ae4eb0e5269
https://github.com/WebKit/WebKit/commit/a58093a545495bfe36de69a672d57ae4eb0e5269
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/AXLogger.cpp
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/AXObjectCache.h
M Source/WebCore/accessibility/AccessibilityMenuListOption.h
M Source/WebCore/accessibility/AccessibilitySpinButton.h
Log Message:
-----------
Cherry-pick 14a42d83e12e. rdar://problem/113605153
Cherry-pick 5b4bb30a99e4. rdar://problem/113042000
AX: Finish converting all WebCore/accessibility member variables to use smart pointers
https://bugs.webkit.org/show_bug.cgi?id=259606
rdar://113042000
Reviewed by Chris Fleizach.
Continued work towards complying with https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines.
* Source/WebCore/accessibility/AXLogger.cpp:
(WebCore::AXLogger::log):
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::AXObjectCache):
(WebCore::AXObjectCache::rootObject):
(WebCore::AXObjectCache::setIsolatedTreeRoot):
(WebCore::AXObjectCache::remove):
(WebCore::AXObjectCache::deferNodeAddedOrRemoved):
(WebCore::AXObjectCache::notificationPostTimerFired):
(WebCore::AXObjectCache::focusCurrentModal):
(WebCore::AXObjectCache::characterOffsetForPoint):
(WebCore::filterWeakListHashSetForRemoval):
(WebCore::filterWeakHashMapForRemoval):
(WebCore::AXObjectCache::prepareForDocumentDestruction):
(WebCore::AXObjectCache::performDeferredCacheUpdate):
(WebCore::AXObjectCache::deferTextChangedIfNeeded):
(WebCore::AXObjectCache::deferTextReplacementNotificationForTextControl):
(WebCore::AXObjectCache::rootWebArea):
(WebCore::AXObjectCache::updateRelationsIfNeeded):
(WebCore::AXObjectCache::addRelations):
* Source/WebCore/accessibility/AXObjectCache.h:
(WebCore::AXObjectCache::document const):
* Source/WebCore/accessibility/AccessibilityMenuListOption.h:
* Source/WebCore/accessibility/AccessibilitySpinButton.h:
Canonical link: https://commits.webkit.org/266406@main
Identifier: 265870.292 at safari-7616.1.27.10-branch
Identifier: 265870.307 at safari-7616-branch
Commit: 4286a61ab65e3c4c65547e27667844f419390b68
https://github.com/WebKit/WebKit/commit/4286a61ab65e3c4c65547e27667844f419390b68
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Cherry-pick ccb976224ab6. rdar://problem/113604929
Cherry-pick 43da1fd1587a. rdar://problem/111534888
WebKit Media: Toggling fullscreen fails to work
https://bugs.webkit.org/show_bug.cgi?id=259760
rdar://111534888
Reviewed by Aditya Keerthi.
The window resize handler is created when receiving the `will{Enter|Exit}FullScreen` notification,
and is then invalidated as a result of `setFrameSize` being called. However, when transiting to/from
element full screen, `setFrameSize` is called before the notification is posted, instead of after.
This causes the handler to never be invalidated.
Fix by creating the handler directly inside `setFrameSize`, and not rely on the full screen
notifications at all. This is ok since `_holdResizeSnapshotWithReason` only returns a non-nil block
when entering or exiting full screen, so it has no effect in other cases.
No new tests, since all tests in `FullscreenVideoTextRecognition` already test this behavior in some
configurations.
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _holdWindowResizeSnapshotWithReason:]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Canonical link: https://commits.webkit.org/266558@main
Identifier: 265870.295 at safari-7616.1.27.10-branch
Identifier: 265870.308 at safari-7616-branch
Commit: d6bc993be2b0006ac229300d1b775dd116c4665c
https://github.com/WebKit/WebKit/commit/d6bc993be2b0006ac229300d1b775dd116c4665c
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/Platform/spi/mac/AppKitSPI.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/mac/WKView.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Cherry-pick 6e40b4c5f442. rdar://problem/113604929
Cherry-pick 3d721c09585b. rdar://problem/111534888
REGRESSION (UI-side compositing): Jumpy full screen transition animation
https://bugs.webkit.org/show_bug.cgi?id=259375
rdar://111534888
Reviewed by Wenson Hsieh.
With UI-side compositing, when entering or exiting window fullscreen mode, the transition is
sometimes jumpy. This happens in cases where the UI process resizes before the web content has a
chance to resize. The web content and the UI Process should always resize in the same CA commit.
Fix by adopting an AppKit SPI to defer entering or exiting window fullscreen mode until the web
content has actually been resized to the new size. This is done by using a "window snapshot readiness handler".
* Source/WTF/wtf/PlatformHave.h:
Add a new `HAVE` definition to only enable this on macOS, and only on versions where the SPI exists.
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]):
Invokes the readiness handler and then resets it, indicating to AppKit that the full screen should
be allowed to resume.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]):
(-[WKView _web_windowWillExitFullScreen]):
Stub methods required to compile legacy WebKit.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
When `setFrameSize` gets called with the new frame size, the UI process waits for the next presentation
update of the web prcoess. Once in the completion handler, we know that the web content has properly
resized, and so we should now invalidate the readiness handler.
(-[WKWebView _web_windowWillEnterFullScreen]):
(-[WKWebView _web_windowWillExitFullScreen]):
Upon receiving one of these notifications, we take out a window snapshot readiness handler and store
it. This tells AppKit to defer the final stage of the enter and exit full screen animations until
the handler is invoked.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
In some cases, `setFrameSize` would early return inside of `didChangeFrameSize` due to these set of
methods. This caused the bug to still reproduce, since the new drawing area size was no longer being set.
These methods have long been not actually needed, so their implementations are now removed and there is
no longer a need for an early return.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]):
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]):
(WebKit::WebViewImpl::windowWillEnterFullScreen):
(WebKit::WebViewImpl::windowWillExitFullScreen):
When entering or exiting full screen, we now listen to their respective notifications.
Canonical link: https://commits.webkit.org/266273@main
Identifier: 265870.296 at safari-7616.1.27.10-branch
Identifier: 265870.309 at safari-7616-branch
Commit: 747204c25431e84c513d3cbee19b94ee24fbe34d
https://github.com/WebKit/WebKit/commit/747204c25431e84c513d3cbee19b94ee24fbe34d
Author: Charlie Wolfe <charliew at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/loader/PingLoader.cpp
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/Shared/AuxiliaryProcess.cpp
M Source/WebKit/Shared/AuxiliaryProcess.h
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/WebProcess.cpp
Log Message:
-----------
Cherry-pick 05ea369007a0. rdar://problem/113605180
Cherry-pick 274a67057562. rdar://problem/113364311
Cherry-pick 266561 at main (274a67057562). rdar://113364311
Revert (266074 at main): Arbitrary cookie access via NetworkConnectionToWebProcess::cookiesForDOM
https://bugs.webkit.org/show_bug.cgi?id=259806
rdar://113364311
Reviewed by J Pascoe.
Causes multiple web process crashes.
* Source/WebCore/loader/PingLoader.cpp:
(WebCore::PingLoader::sendViolationReport):
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::createSocketChannel):
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync):
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync):
(WebKit::NetworkConnectionToWebProcess::domCookiesForHost):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::allowsFirstPartyForCookies):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/Shared/AuxiliaryProcess.cpp:
(WebKit::AuxiliaryProcess::allowsFirstPartyForCookies):
* Source/WebKit/Shared/AuxiliaryProcess.h:
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::getResourceBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::Stream::start):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::allowsFirstPartyForCookies):
Canonical link: https://commits.webkit.org/266561@main
Identifier: 265870.310 at safari-7616-branch
Commit: 5242167caf6e818f4e4aa4b8d29fe0e7738d8dcc
https://github.com/WebKit/WebKit/commit/5242167caf6e818f4e4aa4b8d29fe0e7738d8dcc
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WTF/wtf/ThreadSafeWeakHashSet.h
M Source/WTF/wtf/WeakHashMap.h
M Source/WTF/wtf/WeakHashSet.h
M Source/WTF/wtf/WeakListHashSet.h
M Source/WebKit/NetworkProcess/NetworkDataTask.cpp
M Source/WebKit/NetworkProcess/NetworkDataTaskBlob.cpp
M Source/WebKit/NetworkProcess/NetworkDataTaskDataURL.cpp
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/NetworkSession.h
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
M Source/WebKit/NetworkProcess/curl/NetworkDataTaskCurl.cpp
M Source/WebKit/NetworkProcess/soup/NetworkDataTaskSoup.cpp
M Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp
Log Message:
-----------
Cherry-pick ff4f94cab566. rdar://problem/113605295
Cherry-pick 177d6881d88d. rdar://problem/112162921
Regression: NetworkDataTask's ThreadSafeWeakPtrControlBlock are leaking
https://bugs.webkit.org/show_bug.cgi?id=259808
rdar://112162921
Reviewed by Alex Christensen.
The NetworkProcess memory was growing unboundedly during long-running browsing
benchmarks, which the number of NetworkDataTask's ThreadSafeWeakPtrControlBlock
objects growing very large.
The issue was with the `ThreadSafeWeakHashSet<NetworkDataTask> m_dataTaskSet`
container on the NetworkSession. We would add NetworkDataTask objects to this
WeakHashSet and never explicitly remove them. We had a comment in the code
indicating that the ThreadSafeWeakHashSet's amortized clean up would take care
of removing them. The issue though is that amortized clean up would never happen
and m_dataTaskSet's internal Set would just grow unboundedly, keeping control
blocks alive.
The reason amortized clean up never triggered is that we only add to m_dataTaskSet,
we never remove from it, never clear it and we only very rarely call forEach() on
it. As a result, ThreadSafeWeakHashSet::m_operationCountSinceLastCleanup would only
increment due to the add() calls. The condition for amortized clean up was:
`++m_operationCountSinceLastCleanup / 2 > m_set.size()`.
Since m_operationCountSinceLastCleanup would only increase due to the add() calls
and since nothing would ever get removed from the set, `m_operationCountSinceLastCleanup / 2`
could never reach the size of the set.
I am making several fixes in this patch:
1. I added a `|| m_operationCountSinceLastCleanup > m_maxOperationCountWithoutCleanup`
check to amortized clean up to guarantee that amortized clean up eventually happens
and that such weak containers can never grow unboundedly, no matter how they are used.
m_maxOperationCountWithoutCleanup gets multiplied by 2 whenever the clean up finds
nothing for proper amortization.
2. I made it so that NetworkDataTask objects remove themselves from the ThreadSafeWeakHashSet
in their destructor. This is good practice no matter what and makes such the set stays
small.
3. I actually found a bug in `ThreadSafeWeakHashSet::remove()` when implementing the fix in
(2). ThreadSafeWeakHashSet::remove() would fail to remove the object from the set if the
call if made after the object destructor has started running! The reason for this is that
the ThreadSafeWeakHashSet was using a `std::pair<ControlBlockRefPtr, const T*>` as set
key internally. This means that we needed to create a ControlBlockRefPtr of the object's
control block in remove() in order to remove the object from the map. However, 265344 at main
made it so that ref'ing a control block returns nullptr after the object has started
destruction. As a result, the first item in the key pair would be nullptr and we'd fail
to remove. To address the issue, I am dropping the ControlBlockRefPtr from the key and
using a `HashMap<const T*, ControlBlockRefPtr>` instead of a HashSet.
* Source/WTF/wtf/ThreadSafeWeakHashSet.h:
* Source/WTF/wtf/WeakHashMap.h:
* Source/WTF/wtf/WeakHashSet.h:
* Source/WTF/wtf/WeakListHashSet.h:
* Source/WebKit/NetworkProcess/NetworkDataTask.cpp:
(WebKit::NetworkDataTask::~NetworkDataTask):
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::registerNetworkDataTask):
(WebKit::NetworkSession::unregisterNetworkDataTask):
* Source/WebKit/NetworkProcess/NetworkSession.h:
* Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp:
(TestWebKitAPI::ObjectAddingAndRemovingItself::create):
(TestWebKitAPI::ObjectAddingAndRemovingItself::~ObjectAddingAndRemovingItself):
(TestWebKitAPI::ObjectAddingAndRemovingItself::ObjectAddingAndRemovingItself):
(TestWebKitAPI::TEST):
(TestWebKitAPI::ObjectAddingItselfOnly::create):
(TestWebKitAPI::ObjectAddingItselfOnly::ObjectAddingItselfOnly):
Canonical link: https://commits.webkit.org/266594@main
Identifier: 265870.298 at safari-7616.1.27.10-branch
Identifier: 265870.311 at safari-7616-branch
Commit: f942f55e4c48056df99754333a20662c99ba0f39
https://github.com/WebKit/WebKit/commit/f942f55e4c48056df99754333a20662c99ba0f39
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp
Log Message:
-----------
Cherry-pick 5b0eda999aeb. rdar://problem/113604970
Cherry-pick a41543cba4bf. rdar://problem/113271473
InputDevice capabilities are not required until capture is active
https://bugs.webkit.org/show_bug.cgi?id=259814
rdar://113271473
Reviewed by Jer Noble.
InputDevice capabilities are not exposed until after the user has given consent to
capture, so don't bother asking for them unless they will be revealed as activating the
AVAudioSession may change the characteristics of the audio rendering in other processes.
* Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
(WebKit::UserMediaPermissionRequestManagerProxy::platformGetMediaStreamDevices):
Canonical link: https://commits.webkit.org/266581@main
Identifier: 265870.299 at safari-7616.1.27.10-branch
Identifier: 265870.312 at safari-7616-branch
Commit: 9d0fcc4437439ec96e2e1515a33743b359fcb94c
https://github.com/WebKit/WebKit/commit/9d0fcc4437439ec96e2e1515a33743b359fcb94c
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
Log Message:
-----------
Cherry-pick 54ed588a4ca8. rdar://problem/113604869
Cherry-pick ab6f0338a00f. rdar://problem/111986083
REGRESSION (265825 at main): Safari CPU usage in SurferJoannaProxy increased by 5.8%
https://bugs.webkit.org/show_bug.cgi?id=259805
rdar://111986083
Reviewed by Matt Woodrow.
The fix in 265825 at main caused a slight performance regression. We can
now back out most of it, thanks to a change in CoreAnimation.
The thing we don't restore is the CATransaction.
* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
Canonical link: https://commits.webkit.org/266557@main
Identifier: 265870.303 at safari-7616.1.27.10-branch
Identifier: 265870.313 at safari-7616-branch
Commit: b54edd6f841f7a7aafa35ba2d8ba92f391f28453
https://github.com/WebKit/WebKit/commit/b54edd6f841f7a7aafa35ba2d8ba92f391f28453
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/compositing/canvas/accelerated-small-canvas-compositing-expected.txt
A LayoutTests/compositing/canvas/accelerated-small-canvas-compositing.html
A LayoutTests/platform/gtk/compositing/canvas/accelerated-small-canvas-compositing-expected.txt
A LayoutTests/platform/ios/compositing/canvas/accelerated-small-canvas-compositing-expected.txt
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 165c344898b3. rdar://problem/113605231
Cherry-pick 3dfb58beb215. rdar://problem/112439265
[Cocoa] Small canvases, which aren't supposed to get compositing layers, get compositing layers if they have a 3D-but-could-be-2D transform
https://bugs.webkit.org/show_bug.cgi?id=259297
rdar://112439265
Reviewed by Simon Fraser.
We already have existing code which will avoid compositing small canvases. However, if
the small canvas has a 3D-but-could-be-2D transform, we'll composite it regardless. This
patch extends the current logic to not composite small canvases in this case.
This patch causes a 41% - 48% progression on the Images subtest in MotionMark. Layers
have cost, y'all.
* LayoutTests/compositing/canvas/accelerated-small-canvas-compositing-expected.txt
* LayoutTests/compositing/canvas/accelerated-small-canvas-compositing.html
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresCompositingForTransform const): This patch doesn't
modify m_compositingPolicy, because that's global for the whole RenderLayerCompositor. We
only want to change the policy in this specific case.
Canonical link: https://commits.webkit.org/266135@main
Identifier: 265870.309 at safari-7616.1.27.11-branch
Identifier: 265870.314 at safari-7616-branch
Commit: f669a01e0034700a9ef836273144f4b7af33878d
https://github.com/WebKit/WebKit/commit/f669a01e0034700a9ef836273144f4b7af33878d
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
A LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution-expected.txt
A LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution.html
A LayoutTests/compositing/layer-creation/overlap-transform-filter-expected.txt
A LayoutTests/compositing/layer-creation/overlap-transform-filter.html
A LayoutTests/platform/ios-wk2/compositing/layer-creation/overlap-transform-filter-contribution-expected.txt
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayerBacking.cpp
Log Message:
-----------
Cherry-pick 2e1ca5ac8e80. rdar://problem/113420795
Compositing overlap testing is broken with filters in some configurations
https://bugs.webkit.org/show_bug.cgi?id=259848
rdar://113420795
Reviewed by Alan Baradlay.
`RenderLayer::overlapBounds()` needs to return a rectangle which doesn't include the layer's own transform,
since the caller applies the transform. However, if the layer has a filter that moves pixels (causing
`overlapBoundsIncludeChildren()` to return true), then it used `defaultCalculateLayerBoundsFlags()`
which includes `IncludeSelfTransform`.
So pass a set of flags that cause the transform to be ignored.
The tests exercise a filtered layer overlapping another layer, and other layers overlapping a filtered
layer.
This is part of a set of issues that affect reddit.com (rdar://112807737).
* LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution-expected.txt: Added.
* LayoutTests/compositing/layer-creation/overlap-transform-filter-contribution.html: Added.
* LayoutTests/compositing/layer-creation/overlap-transform-filter-expected.txt: Added.
* LayoutTests/compositing/layer-creation/overlap-transform-filter.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects const):
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::operator<<):
Canonical link: https://commits.webkit.org/266669@main
Identifier: 265870.315 at safari-7616-branch
Commit: a130ec7fbe8ea856e2ec0c498391f74cb48e6feb
https://github.com/WebKit/WebKit/commit/a130ec7fbe8ea856e2ec0c498391f74cb48e6feb
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm
Log Message:
-----------
Cherry-pick ff720c419802. rdar://problem/113280724
AX: Voice Control cannot access any web content
https://bugs.webkit.org/show_bug.cgi?id=259951
rdar://113280724
Reviewed by Chris Fleizach.
This is a regression from https://bugs.webkit.org/show_bug.cgi?id=256238, which changed
`-[WKAccessibilityWebPageObjectMac accessibilityAttributeNames]` to return `m_attributeNames`
via `.autorelease()` rather than `.get()`. Returning via autorelease causes the backing NSArray
to be released after the next iteration of the runloop, meaning subsequent requests to
`accessibilityAttributeNames` return nil. Voice Control relies on this output being correct to function.
With this patch, both `m_attributeNames` and `m_parameterizedAttributeNames` are returned via
`RetainPtr::get()`, preventing their early deletion. This matches the getters for other
`RetainPtr<NSArray> m_foo` types throughout WebKit.
* Source/WebKit/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm:
(-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]):
Canonical link: https://commits.webkit.org/266714@main
Identifier: 265870.316 at safari-7616-branch
Commit: 195b9388c62cc65b15670063be37406df325243d
https://github.com/WebKit/WebKit/commit/195b9388c62cc65b15670063be37406df325243d
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformEnableCocoa.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 3ef8682eac94. rdar://problem/113557767
Low end devices should not prewarm Web process on provisional load
https://bugs.webkit.org/show_bug.cgi?id=259927
rdar://113557767
Reviewed by Chris Dumez.
After 266255 at main, a Web process is prewarmed on provisional load instead of when the main frame load has finished.
This is a page load time progression on most iOS devices, except for the low end ones. For these devices, we should
still be prewarming when the main frame load has finished. The change in 266255 at main is also performance neutral on
macOS, so we can also keep the original behavior there.
* Source/WTF/wtf/PlatformEnableCocoa.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::shouldPrewarmWebProcessOnProvisionalLoad):
(WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
(WebKit::WebPageProxy::didFinishLoadForFrame):
Canonical link: https://commits.webkit.org/266717@main
Identifier: 265870.317 at safari-7616-branch
Commit: dc69f74f8585fceedd8ad58ba9764e33e2dfa91c
https://github.com/WebKit/WebKit/commit/dc69f74f8585fceedd8ad58ba9764e33e2dfa91c
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/loader/PingLoader.cpp
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/Shared/AuxiliaryProcess.cpp
M Source/WebKit/Shared/AuxiliaryProcess.h
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/WebProcess.cpp
Log Message:
-----------
Revert "747204c25431 Cherry-pick 05ea369007a0. rdar://problem/113605180"
* Source/WebCore/loader/PingLoader.cpp:
(WebCore::PingLoader::sendViolationReport):
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::createSocketChannel):
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::domCookiesForHost):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync): Deleted.
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync): Deleted.
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::allowsFirstPartyForCookies):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/Shared/AuxiliaryProcess.cpp:
(WebKit::AuxiliaryProcess::allowsFirstPartyForCookies):
* Source/WebKit/Shared/AuxiliaryProcess.h:
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::getResourceBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::Stream::start):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::allowsFirstPartyForCookies):
Identifier: 265870.318 at safari-7616-branch
Commit: 0ca63bff0b639b6ccd97548e937e4fa23543f85d
https://github.com/WebKit/WebKit/commit/0ca63bff0b639b6ccd97548e937e4fa23543f85d
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebCore/loader/PingLoader.cpp
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/Shared/AuxiliaryProcess.cpp
M Source/WebKit/Shared/AuxiliaryProcess.h
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
M Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm
M Source/WebKit/WebProcess/Plugins/PluginView.cpp
M Source/WebKit/WebProcess/WebProcess.cpp
Log Message:
-----------
Revert 53706abee76c "Cherry-pick 266074 at main (cb29a8742b53). rdar://112497411"
* Source/WebCore/loader/PingLoader.cpp:
(WebCore::PingLoader::sendViolationReport):
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::requestResource):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::createSocketChannel):
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::domCookiesForHost):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::allowsFirstPartyForCookies):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/Shared/AuxiliaryProcess.cpp:
(WebKit::AuxiliaryProcess::allowsFirstPartyForCookies):
* Source/WebKit/Shared/AuxiliaryProcess.h:
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::PDFPlugin::getResourceBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::Stream::start):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::allowsFirstPartyForCookies):
Identifier: 265870.319 at safari-7616-branch
Commit: 452025a50c62cfe0671ee04e8e9706e5295866f9
https://github.com/WebKit/WebKit/commit/452025a50c62cfe0671ee04e8e9706e5295866f9
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/Platform/spi/mac/AppKitSPI.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/mac/WKView.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Revert d6bc993be2b0 "Cherry-pick 6e40b4c5f442. rdar://problem/113604929"
* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _holdWindowResizeSnapshotIfNeeded]):
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _holdWindowResizeSnapshotWithReason:]): Deleted.
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Identifier: 265870.320 at safari-7616-branch
Commit: 3d8a903fa3fb455b9f226aeea8948d1c266d1e39
https://github.com/WebKit/WebKit/commit/3d8a903fa3fb455b9f226aeea8948d1c266d1e39
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-09 (Wed, 09 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Revert "4286a61ab65e Cherry-pick ccb976224ab6. rdar://problem/113604929"
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView setFrameSize:]):
(-[WKWebView _holdWindowResizeSnapshotIfNeeded]): Deleted.
(-[WKWebView _doWindowSnapshotReadinessUpdate]): Deleted.
Identifier: 265870.321 at safari-7616-branch
Commit: c74570e69d6bb17f98b35041d7f69a64545363e7
https://github.com/WebKit/WebKit/commit/c74570e69d6bb17f98b35041d7f69a64545363e7
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/Platform/spi/mac/AppKitSPI.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/mac/WKView.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Cherry-pick 6e40b4c5f442. rdar://problem/113604929
Cherry-pick 265870.296 at safari-7616.1.27.10-branch (6e40b4c5f442). rdar://111534888
Cherry-pick 3d721c09585b. rdar://problem/111534888
REGRESSION (UI-side compositing): Jumpy full screen transition animation
https://bugs.webkit.org/show_bug.cgi?id=259375
rdar://111534888
Reviewed by Wenson Hsieh.
With UI-side compositing, when entering or exiting window fullscreen mode, the transition is
sometimes jumpy. This happens in cases where the UI process resizes before the web content has a
chance to resize. The web content and the UI Process should always resize in the same CA commit.
Fix by adopting an AppKit SPI to defer entering or exiting window fullscreen mode until the web
content has actually been resized to the new size. This is done by using a "window snapshot readiness handler".
* Source/WTF/wtf/PlatformHave.h:
Add a new `HAVE` definition to only enable this on macOS, and only on versions where the SPI exists.
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]):
Invokes the readiness handler and then resets it, indicating to AppKit that the full screen should
be allowed to resume.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]):
(-[WKView _web_windowWillExitFullScreen]):
Stub methods required to compile legacy WebKit.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
When `setFrameSize` gets called with the new frame size, the UI process waits for the next presentation
update of the web prcoess. Once in the completion handler, we know that the web content has properly
resized, and so we should now invalidate the readiness handler.
(-[WKWebView _web_windowWillEnterFullScreen]):
(-[WKWebView _web_windowWillExitFullScreen]):
Upon receiving one of these notifications, we take out a window snapshot readiness handler and store
it. This tells AppKit to defer the final stage of the enter and exit full screen animations until
the handler is invoked.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
In some cases, `setFrameSize` would early return inside of `didChangeFrameSize` due to these set of
methods. This caused the bug to still reproduce, since the new drawing area size was no longer being set.
These methods have long been not actually needed, so their implementations are now removed and there is
no longer a need for an early return.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]):
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]):
(WebKit::WebViewImpl::windowWillEnterFullScreen):
(WebKit::WebViewImpl::windowWillExitFullScreen):
When entering or exiting full screen, we now listen to their respective notifications.
Canonical link: https://commits.webkit.org/266273@main
Identifier: 265870.296 at safari-7616.1.27.10-branch
Identifier: 265870.322 at safari-7616-branch
Commit: 19c6100927f138068b9bd9e33af9361daed03e84
https://github.com/WebKit/WebKit/commit/19c6100927f138068b9bd9e33af9361daed03e84
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Cherry-pick ccb976224ab6. rdar://problem/113604929
Cherry-pick 265870.295 at safari-7616.1.27.10-branch (ccb976224ab6). rdar://111534888
Cherry-pick 43da1fd1587a. rdar://problem/111534888
WebKit Media: Toggling fullscreen fails to work
https://bugs.webkit.org/show_bug.cgi?id=259760
rdar://111534888
Reviewed by Aditya Keerthi.
The window resize handler is created when receiving the `will{Enter|Exit}FullScreen` notification,
and is then invalidated as a result of `setFrameSize` being called. However, when transiting to/from
element full screen, `setFrameSize` is called before the notification is posted, instead of after.
This causes the handler to never be invalidated.
Fix by creating the handler directly inside `setFrameSize`, and not rely on the full screen
notifications at all. This is ok since `_holdResizeSnapshotWithReason` only returns a non-nil block
when entering or exiting full screen, so it has no effect in other cases.
No new tests, since all tests in `FullscreenVideoTextRecognition` already test this behavior in some
configurations.
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _holdWindowResizeSnapshotWithReason:]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Canonical link: https://commits.webkit.org/266558@main
Identifier: 265870.295 at safari-7616.1.27.10-branch
Identifier: 265870.323 at safari-7616-branch
Commit: a94eb47144db4e766898ac9080a01749a12fe762
https://github.com/WebKit/WebKit/commit/a94eb47144db4e766898ac9080a01749a12fe762
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M LayoutTests/resources/ui-helper.js
M Source/WebKit/UIProcess/ios/WKTextSelectionRect.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
Cherry-pick 69d07a6b99c8. rdar://problem/111793617
When selecting Live Text in Safari on iOS, the selection handles move away from the selection when zooming
https://bugs.webkit.org/show_bug.cgi?id=259964
rdar://111793617
Reviewed by Wenson Hsieh.
UIKit now scales the selection handles when zooming and updates their position accordingly.
Since WebKit is also scaling them ourselves, this results in a position that's offset from the
selection proportional to the zoom amount.
Fix by no longer scaling the selection handles in WebKit.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.getSelectionEndGrabberViewShapePathDescription.return.new.Promise.):
(window.UIHelper.getSelectionEndGrabberViewShapePathDescription.return.new.Promise):
(window.UIHelper.getSelectionEndGrabberViewShapePathDescription):
* Source/WebKit/UIProcess/ios/WKTextSelectionRect.mm:
(-[WKTextSelectionRect _customHandleInfo]):
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::selectionEndGrabberViewShapePathDescription const):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::selectionEndGrabberViewShapePathDescription const):
Canonical link: https://commits.webkit.org/266753@main
Identifier: 265870.324 at safari-7616-branch
Commit: aac06234f2feb483b7d9eb58b1a75cb89fd2ee11
https://github.com/WebKit/WebKit/commit/aac06234f2feb483b7d9eb58b1a75cb89fd2ee11
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm
Log Message:
-----------
Cherry-pick 223cdceb7637. rdar://problem/112875397
In some macOS VM configurations, layer content is sometimes missing
https://bugs.webkit.org/show_bug.cgi?id=260003
<rdar://112875397>
Reviewed by Tim Horton.
In some macOS VM configs without accelerated graphics, IOSurfaceGetPropertyMaximum()
returns INT_MAX. This resulted in `TileController::computeTileSize()` sometimes computing
negative tile widths, which resulted in missing content.
Fix by clamping to fallbackMaxSurfaceDimension(), which is something we already did on iOS;
on macOS this will clamp to a max of 32K, which prevents the INT_MAX causing math errors.
* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::computeMaximumSurfaceSize):
Canonical link: https://commits.webkit.org/266767@main
Identifier: 265870.325 at safari-7616-branch
Commit: 6b8e3b9209448f74538054c1f31c411c380fede6
https://github.com/WebKit/WebKit/commit/6b8e3b9209448f74538054c1f31c411c380fede6
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp
M Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePagePrivate.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm
M Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityControllerMac.mm
Log Message:
-----------
Cherry-pick 4e977f1f8fe1. rdar://problem/113605089
REGRESSION(264706 at main): [ macOS ] TestWebKitAPI.WebKit.AutoFillAvailable is a constant timeout.
https://bugs.webkit.org/show_bug.cgi?id=257756
rdar://110336197
Reviewed by Chris Fleizach.
This test was timing out because it invokes [AutoFillAvailable webProcessPlugIn:didCreateBrowserContextController:] that calls WKAccessibilityFocusedObject, that in turn calls WebKit::WebProcess::accessibilityUIElement. The latter cannot be called this early in creating the page and crashes, thus causing the test to time out.
To avoid this problem and still use WebProcess::accessibilityFocusedUIElement in the accessibility layout tests, this patch reverts the change in 264706 at main to WKAccessibilityFocusedObject. Instead, added WKAccessibilityFocusedUIElement to be used by WTR::AccessibilityController on Mac.
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePage.cpp:
(WKAccessibilityFocusedObject):
(WKAccessibilityFocusedUIElement):
* Source/WebKit/WebProcess/InjectedBundle/API/c/WKBundlePagePrivate.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/UIDelegate.mm:
* Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityControllerMac.mm:
(WTR::AccessibilityController::focusedElement):
Canonical link: https://commits.webkit.org/266179@main
Identifier: 265870.326 at safari-7616-branch
Commit: 66b0c6e5ccd4db9c95ce6da50b59e4d308bbe227
https://github.com/WebKit/WebKit/commit/66b0c6e5ccd4db9c95ce6da50b59e4d308bbe227
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.2
Canonical link: https://commits.webkit.org/265870.327@safari-7616-branch
Commit: 2acf0f16e1a6c933fc6b8a9921470f721ce4da21
https://github.com/WebKit/WebKit/commit/2acf0f16e1a6c933fc6b8a9921470f721ce4da21
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/MediaPlayer.cpp
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp
Log Message:
-----------
Cherry-pick 9e0532d73ce4. rdar://problem/109074255
MediaPlayerPrivate resource owner is not always correctly set through RemoteMediaPlayerProxy
https://bugs.webkit.org/show_bug.cgi?id=258977
rdar://111908366
Reviewed by Eric Carlson.
When loading a URL, the MediaPlayerPrivate may change and we should reset the resource owner.
Update MediaPlayer to do this handling and update RemoteMediaPlayerProxy::RemoteMediaPlayerProxy accordingly.
* Source/WebCore/platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::loadWithNextMediaEngine):
(WebCore::MediaPlayer::setResourceOwner):
* Source/WebCore/platform/graphics/MediaPlayer.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp:
(WebKit::RemoteMediaPlayerProxy::RemoteMediaPlayerProxy):
Canonical link: https://commits.webkit.org/265901@main
Canonical link: https://commits.webkit.org/265870.328@safari-7616-branch
Commit: 26a568ef37f804bc2db9675824d299be65a9b49f
https://github.com/WebKit/WebKit/commit/26a568ef37f804bc2db9675824d299be65a9b49f
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm
Log Message:
-----------
Cherry-pick 88351aff0eb2. rdar://problem/113607432
[iPhone] 39miles.com link is rendered at single-column layout in private browsing mode
https://bugs.webkit.org/show_bug.cgi?id=259129
rdar://112105451
Reviewed by Aditya Keerthi.
Add a missing 390pt screen dimension breakpoint when advanced privacy protections are enabled;
currently, this causes some websites that rely on the screen width for layout to assume that the
width of the page is larger than it actually is.
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::screenSizeForFingerprintingProtections const):
* Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
Also, augment an existing API test to verify that the new screen size breakpoint behaves as
expected.
Canonical link: https://commits.webkit.org/265979@main
Canonical link: https://commits.webkit.org/265870.329@safari-7616-branch
Commit: a9f1bec1c4b494820248d6c571b186e65e493c3d
https://github.com/WebKit/WebKit/commit/a9f1bec1c4b494820248d6c571b186e65e493c3d
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/JavaScriptCore/runtime/Structure.cpp
M Source/JavaScriptCore/runtime/Structure.h
M Source/JavaScriptCore/runtime/StructureInlines.h
Log Message:
-----------
Cherry-pick 9d3aa204e699. rdar://problem/113604275
[JSC] holesMustForwardToPrototype should be fast for normal arrays
https://bugs.webkit.org/show_bug.cgi?id=259239
rdar://112308103
Reviewed by Alexey Shvayka.
We should quickly say `false` from Structure::holesMustForwardToPrototype if the target structure
is original array and we are having array prototype sane chain (this means we have no indexed properties,
and array prototype chain is solid).
* Source/JavaScriptCore/runtime/Structure.cpp:
(JSC::Structure::holesMustForwardToPrototypeSlow const):
(JSC::Structure::holesMustForwardToPrototype const): Deleted.
* Source/JavaScriptCore/runtime/Structure.h:
* Source/JavaScriptCore/runtime/StructureInlines.h:
(JSC::Structure::holesMustForwardToPrototype const):
Canonical link: https://commits.webkit.org/266183@main
Canonical link: https://commits.webkit.org/265870.330@safari-7616-branch
Commit: 2aab63184199010724a1bc0689adeb3ab7ba91f2
https://github.com/WebKit/WebKit/commit/2aab63184199010724a1bc0689adeb3ab7ba91f2
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebCore/workers/service/server/SWServerJobQueue.cpp
Log Message:
-----------
Cherry-pick 3cb928bc8c15. rdar://problem/112997411
SWServerJobQueue::scriptContextStarted might have a null registration
https://bugs.webkit.org/show_bug.cgi?id=259591
rdar://112997411
Reviewed by Alex Christensen.
From logs, it appears SWServerJobQueue::scriptContextStarted might have a nullptr registration.
One possibility is the following:
- A main thread service worker page is created.
- The service worker is being installed (in main thread) and succeeds. This triggers a callOnMainThread to execute the callback that will notify network process to continue its processing
- Before the callback is executed, the service worker page is closed and the network process is notified about this.
- The network process removes the registration from its map in SWServer::unregisterServiceWorkerClient.
- The network process processes the message to continue installing the service worker and continue with the current job.
To prevent this, we are now making sure to cancel the job of a preinstalling service worker whose registration is removed in SWServer::unregisterServiceWorkerClient.
Since this is a speculative fix, we transform the ASSERT(registration) in an if+ASSERT.
We add logging to make sure to keep track of this, in case this might trigger job queue hangs.
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::unregisterServiceWorkerClient):
* Source/WebCore/workers/service/server/SWServerJobQueue.cpp:
(WebCore::SWServerJobQueue::scriptContextFailedToStart):
(WebCore::SWServerJobQueue::scriptContextStarted):
Canonical link: https://commits.webkit.org/266419@main
Canonical link: https://commits.webkit.org/265870.331@safari-7616-branch
Commit: fd138477c3f9850e17463cfc4dfd94bc2ff99dd4
https://github.com/WebKit/WebKit/commit/fd138477c3f9850e17463cfc4dfd94bc2ff99dd4
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
A LayoutTests/fast/scrolling/mac/keyboard-scroll-stops-with-keyup-prevented-expected.txt
A LayoutTests/fast/scrolling/mac/keyboard-scroll-stops-with-keyup-prevented.html
M Source/WebCore/page/EventHandler.cpp
Log Message:
-----------
Cherry-pick 768a90b9b462. rdar://problem/112396756
Keyboard scroll doesn't stop after pressing down arrow if `keyup` is default prevented
https://bugs.webkit.org/show_bug.cgi?id=259623
rdar://112396756
Reviewed by Tim Horton.
If a page prevents the default handling of the `keyup` event, but not `keydown`, a keyboard
scroll will be able to be started, but will never end because `EventHandler::defaultKeyboardEventHandler`
will never get called.
Fix by preemptively handling `keyup` in `EventHandler::internalKeyEvent` so that keyboard scrolls
will always be properly terminated even if the event is default-prevented.
* LayoutTests/fast/scrolling/mac/keyboard-scroll-stops-with-keyup-prevented-expected.txt: Added.
* LayoutTests/fast/scrolling/mac/keyboard-scroll-stops-with-keyup-prevented.html: Added.
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::internalKeyEvent):
(WebCore::EventHandler::defaultKeyboardEventHandler):
Canonical link: https://commits.webkit.org/266425@main
Canonical link: https://commits.webkit.org/265870.332@safari-7616-branch
Commit: 45f7e817aa9c6ca5f72d5c3a8d3fb632b15933dc
https://github.com/WebKit/WebKit/commit/45f7e817aa9c6ca5f72d5c3a8d3fb632b15933dc
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M LayoutTests/fullscreen/full-screen-restrictions-expected.txt
M LayoutTests/fullscreen/full-screen-restrictions.html
M LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/element-ready-check-fullscreen-element-sibling-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/element-request-fullscreen-non-top-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/element-request-fullscreen-two-elements-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/fullscreen-reordering-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/fullscreen-reordering.html
M LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-top-layer-interactions-expected.txt
A LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/html/semantics/popovers/popover-top-layer-interactions-expected.txt
M Source/WebCore/dom/FullscreenManager.cpp
Log Message:
-----------
Cherry-pick 675766f74505. rdar://problem/110004138
[fullscreen] Remove hierarchy requirement from fullscreen ready check
https://bugs.webkit.org/show_bug.cgi?id=257199
rdar://110004138
Reviewed by Darin Adler.
The hierarchy requirement was part of the old W3C spec, but is no longer part of the current WHATWG spec. It has also been removed from Blink & Gecko.
Also fix a nullptr deref to make popover-top-layer-interactions.html pass, by adding step 11 of exit fullscreen algorithm to both ExitMode codepaths.
* LayoutTests/fullscreen/full-screen-restrictions-expected.txt:
* LayoutTests/fullscreen/full-screen-restrictions.html:
* LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/element-ready-check-fullscreen-element-sibling-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/element-request-fullscreen-non-top-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/element-request-fullscreen-two-elements-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/fullscreen-reordering-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/fullscreen/api/fullscreen-reordering.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-top-layer-interactions-expected.txt:
* LayoutTests/platform/mac-wk1/imported/w3c/web-platform-tests/html/semantics/popovers/popover-top-layer-interactions-expected.txt: Copied from LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-top-layer-interactions-expected.txt.
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::requestFullscreenForElement):
(WebCore::FullscreenManager::exitFullscreen): Fix nullptr deref in the edge case where 2 exit fullscreen event loop tasks are queued next to each other.
Canonical link: https://commits.webkit.org/266426@main
Canonical link: https://commits.webkit.org/265870.333@safari-7616-branch
Commit: a6d6cc12dd1a52cef3696b922be993bfcb1a3b08
https://github.com/WebKit/WebKit/commit/a6d6cc12dd1a52cef3696b922be993bfcb1a3b08
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebCore/PAL/pal/spi/cg/ImageIOSPI.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
Log Message:
-----------
Cherry-pick 5f408cbc4474. rdar://problem/113604278
Cherry-pick c0fc79a6a65c. rdar://problem/112477703
Disable all image hardware decoding in the WebContent process
https://bugs.webkit.org/show_bug.cgi?id=259457
rdar://112477703
Reviewed by Brent Fulgham.
Disable hardware decoding for all image formats in the WebContent process when IOKit is blocked.
* Source/WTF/wtf/PlatformHave.h:
* Source/WebCore/PAL/pal/spi/cg/ImageIOSPI.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
Canonical link: https://commits.webkit.org/266335@main
Identifier: 265870.254 at safari-7616.1.27-branch
Canonical link: https://commits.webkit.org/265870.334@safari-7616-branch
Commit: 0d768ea8710ad82aea7415c92d60bf779215d83a
https://github.com/WebKit/WebKit/commit/0d768ea8710ad82aea7415c92d60bf779215d83a
Author: Matthew Finkel <sysrqb at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/html/CanvasBase.cpp
M Source/WebCore/html/CanvasBase.h
M Source/WebCore/html/HTMLCanvasElement.cpp
M Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm
Log Message:
-----------
Cherry-pick e263b383e544. rdar://problem/113604224
Cherry-pick 1e0716ff6245. rdar://problem/107564162
Add page-targeted quirk for Canvas2D noise injection
https://bugs.webkit.org/show_bug.cgi?id=259480
rdar://107564162
Reviewed by Wenson Hsieh.
fedex.com and walgreens.com rely on canvas2d fingerprinting on some sensitive
pages. Sometimes the noise injection protection we introduced that protects
against fingerprinting causes a login failure. In this change now we return a
fixed value for the image data: URL on the relevant pages instead of returning
the actual encoded image with noise.
Simon is rightfully concerned that this fix is too narrow, and there are many
other sites that are broken in a similar way. We'll address that further in
https://bugs.webkit.org/show_bug.cgi?id=259601.
* Source/WebCore/html/CanvasBase.cpp:
(WebCore::CanvasBase::recordLastFillText):
* Source/WebCore/html/CanvasBase.h:
(WebCore::CanvasBase::lastFillText const):
* Source/WebCore/html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::toDataURL):
* Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp:
(WebCore::CanvasRenderingContext2D::fillText):
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldEnableCanvas2DAdvancedPrivacyProtectionQuirk const):
(WebCore::Quirks::advancedPrivacyProtectionSubstituteDataURLForText const):
* Source/WebCore/page/Quirks.h:
* Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/266400@main
Identifier: 265870.266 at safari-7616.1.27-branch
Canonical link: https://commits.webkit.org/265870.335@safari-7616-branch
Commit: 57c9fd65f0022a4ddbd99172426501c23056b9cf
https://github.com/WebKit/WebKit/commit/57c9fd65f0022a4ddbd99172426501c23056b9cf
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick d6e9002c0665. rdar://problem/113604250
Cherry-pick 9336846dfe3b. rdar://problem/112410375
[popover] Using shadow DOM wrongly auto-hides popover by light dismiss
https://bugs.webkit.org/show_bug.cgi?id=259261
rdar://112410375
Reviewed by Ryosuke Niwa and Darin Adler.
Use the flat tree as mandated by the spec when calculating which popover to light dismiss:
- https://html.spec.whatwg.org/#topmost-clicked-popover
- https://html.spec.whatwg.org/#nearest-inclusive-open-popover
- https://html.spec.whatwg.org/#nearest-inclusive-target-popover-for-invoker
* LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::handlePopoverLightDismiss):
Canonical link: https://commits.webkit.org/266457@main
Identifier: 265870.284 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.336@safari-7616-branch
Commit: 311db697639b9b8e3cd02b9dda9c5dc1b999e7fd
https://github.com/WebKit/WebKit/commit/311db697639b9b8e3cd02b9dda9c5dc1b999e7fd
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
A LayoutTests/fast/screen-orientation/orientation-in-resize-event-expected.txt
A LayoutTests/fast/screen-orientation/orientation-in-resize-event.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/mac/TestExpectations
M Source/WebCore/Headers.cmake
M Source/WebCore/Sources.txt
M Source/WebCore/SourcesCocoa.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
R Source/WebCore/platform/ScreenOrientationProvider.cpp
R Source/WebCore/platform/ScreenOrientationProvider.h
R Source/WebCore/platform/ios/ScreenOrientationProviderIOS.mm
M Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingVideoSourceGStreamer.cpp
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/WebScreenOrientationManagerProxy.cpp
M Source/WebKit/UIProcess/WebScreenOrientationManagerProxy.h
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/UIProcess/ios/WebScreenOrientationManagerProxyIOS.mm
Log Message:
-----------
Cherry-pick 9f56887fb2ba. rdar://problem/112416568
Videos disappear when switching from landscape to portrait on cnn.com
https://bugs.webkit.org/show_bug.cgi?id=259666
rdar://112416568
Reviewed by Eric Carlson.
On CNN.com, the JS listens for the window `resize` event instead of the orientation change
event and queries `screen.orientation.angle` when this event is fired to determine if we're
in landscape or portrait.
The issue is that Safari has very special handling to deal with rotation (_beginAnimatedResizeWithUpdates
& _endAnimatedResize), where it temporarily overrides the screen orientation. While `window.orientation`
was properly handling this (making sure `window.orientation` stays consistent with the viewport size),
`window.screen.orientation.angle` wasn't. As a result, we'd fire a resize event for the rotation but
the value returned by `window.screen.orientation.angle` would be inconsistent, causing CNN.com to make
the wrong decision and not removing a CSS class when it should have. This was the root cause of the bug.
To address the issue, I am updating `window.screen.orientation` to get its orientation from the same
place as `window.orientation`, instead of the ScreenOrientationProvider, which didn't properly deal
with Safari animated resizing. This actually simplifies the code a lot and gets rid of the bug.
* LayoutTests/fast/screen-orientation/orientation-in-resize-event-expected.txt: Added.
* LayoutTests/fast/screen-orientation/orientation-in-resize-event.html: Added.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/mac/TestExpectations:
* Source/WebCore/Headers.cmake:
* Source/WebCore/Sources.txt:
* Source/WebCore/SourcesCocoa.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/platform/ScreenOrientationProvider.cpp: Removed.
* Source/WebCore/platform/ScreenOrientationProvider.h: Removed.
* Source/WebCore/platform/ios/ScreenOrientationProviderIOS.mm: Removed.
* Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm:
(WebKit::WebPageProxy::setCocoaView):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didAttachToRunningProcess):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/WebScreenOrientationManagerProxy.cpp:
(WebKit::toString):
(WebKit::WebScreenOrientationManagerProxy::WebScreenOrientationManagerProxy):
(WebKit::WebScreenOrientationManagerProxy::~WebScreenOrientationManagerProxy):
(WebKit::WebScreenOrientationManagerProxy::currentOrientation):
(WebKit::WebScreenOrientationManagerProxy::setCurrentOrientation):
(WebKit::WebScreenOrientationManagerProxy::lock):
(WebKit::WebScreenOrientationManagerProxy::setShouldSendChangeNotification):
(WebKit::WebScreenOrientationManagerProxy::screenOrientationDidChange): Deleted.
(WebKit::WebScreenOrientationManagerProxy::platformInitialize): Deleted.
(WebKit::WebScreenOrientationManagerProxy::platformDestroy): Deleted.
* Source/WebKit/UIProcess/WebScreenOrientationManagerProxy.h:
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::toScreenOrientationType):
(WebKit::WebPageProxy::setDeviceOrientation):
* Source/WebKit/UIProcess/ios/WebScreenOrientationManagerProxyIOS.mm:
(WebKit::WebScreenOrientationManagerProxy::platformInitialize): Deleted.
(WebKit::WebScreenOrientationManagerProxy::platformDestroy): Deleted.
(WebKit::WebScreenOrientationManagerProxy::setWindow): Deleted.
(WebKit::WebScreenOrientationManagerProxy::webViewDidMoveToWindow): Deleted.
Canonical link: https://commits.webkit.org/266531@main
Canonical link: https://commits.webkit.org/265870.337@safari-7616-branch
Commit: 77f3961e68f8cec94589f1d614fc159390b86187
https://github.com/WebKit/WebKit/commit/77f3961e68f8cec94589f1d614fc159390b86187
Author: J Pascoe <j_pascoe at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp
Log Message:
-----------
Cherry-pick b9ff70d1e70e. rdar://problem/112477660
[WebAuthn] Do not end ceremony if plugged in U2F cannot fulfill the request.
https://bugs.webkit.org/show_bug.cgi?id=259662
rdar://112477660
Reviewed by Brent Fulgham.
These responses cause ceremonies to error out whenever an unsupported for the
operation U2F key is plugged in. We shouldn't end the ceremony just because
the plugged in U2F key is plugged in because the user could still plug in a different
key or use the platform authenticator.
* Source/WebKit/UIProcess/WebAuthentication/fido/U2fAuthenticator.cpp:
(WebKit::U2fAuthenticator::makeCredential):
(WebKit::U2fAuthenticator::getAssertion):
Canonical link: https://commits.webkit.org/266658@main
Canonical link: https://commits.webkit.org/265870.338@safari-7616-branch
Commit: 0ff248dc56b3d2829800fe700eb39fba06953523
https://github.com/WebKit/WebKit/commit/0ff248dc56b3d2829800fe700eb39fba06953523
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
A LayoutTests/fast/canvas/canvas-ImageData-cache-expected.txt
A LayoutTests/fast/canvas/canvas-ImageData-cache.html
A LayoutTests/fast/canvas/imageData-consistency-expected.txt
A LayoutTests/fast/canvas/imageData-consistency.html
A LayoutTests/platform/gtk/fast/canvas/imageData-consistency-expected.txt
A LayoutTests/platform/wpe/fast/canvas/imageData-consistency-expected.txt
M Source/WebCore/html/ImageData.cpp
M Source/WebCore/html/ImageData.h
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.h
M Source/WebCore/platform/Timer.h
Log Message:
-----------
Cherry-pick da64f6c28daa. rdar://problem/113608278
Cherry-pick 5466cd2c2451. rdar://problem/112746729
Avoid going back to the GPU process for canvas ImageData when possible
https://bugs.webkit.org/show_bug.cgi?id=259436
rdar://problem/112746729
Reviewed by Cameron McCormack and Myles C. Maxfield.
On a 2D canvas, if a recent putImageData() was made with no other
intervening drawing commands, we can use its data to fulfill a
subsequent getImageData(). Start with some simple conditions for
ImageData size and drawing dimensions, which can be extended later if it
proves useful.
* LayoutTests/fast/canvas/canvas-ImageData-cache-expected.txt: Added.
* LayoutTests/fast/canvas/canvas-ImageData-cache.html: Added.
* Source/WebCore/html/ImageData.cpp:
(WebCore::ImageData::clone const):
* Source/WebCore/html/ImageData.h:
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::CanvasRenderingContext2DBase::reset):
(WebCore::CanvasRenderingContext2DBase::didDraw):
(WebCore::CanvasRenderingContext2DBase::cacheImageDataIfPossible):
(WebCore::CanvasRenderingContext2DBase::takeCachedImageDataIfPossible const):
(WebCore::CanvasRenderingContext2DBase::getImageData const):
(WebCore::CanvasRenderingContext2DBase::putImageData):
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.h:
Canonical link: https://commits.webkit.org/266632@main
Identifier: 265870.310 at safari-7616.1.27.11-branch
Canonical link: https://commits.webkit.org/265870.339@safari-7616-branch
Commit: 4d3b19c7137926a127afab42a290bdb741d4602b
https://github.com/WebKit/WebKit/commit/4d3b19c7137926a127afab42a290bdb741d4602b
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.mm
Log Message:
-----------
Cherry-pick 28184199acb7. rdar://problem/113608282
Cherry-pick 3eac88b8c6c7. rdar://problem/113424298
[macOS] Present SCKit picker with `-[SCContentSharingPicker presentPickerUsingContentStyle:]`
https://bugs.webkit.org/show_bug.cgi?id=259851
rdar://113424298
Reviewed by Andy Estes.
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.mm:
(WebCore::ScreenCaptureKitSharingSessionManager::promptWithSCContentSharingPicker): Call
`-[SCContentSharingPicker presentPickerUsingContentStyle:]` when it is available and we
are supposed to limit picking to either window or screen.
Canonical link: https://commits.webkit.org/266640@main
Identifier: 265870.311 at safari-7616.1.27.11-branch
Canonical link: https://commits.webkit.org/265870.340@safari-7616-branch
Commit: 2ba3a1153ab7a3f2f8ccf5f05f1d54c0baf7fe69
https://github.com/WebKit/WebKit/commit/2ba3a1153ab7a3f2f8ccf5f05f1d54c0baf7fe69
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.h
M Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.mm
M Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm
Log Message:
-----------
Cherry-pick a76acff8e983. rdar://problem/113608345
Cherry-pick de279587fd2e. rdar://problem/112625311
[Cocoa] memorialpress.com: Video not playing in iOS 17
https://bugs.webkit.org/show_bug.cgi?id=259838
rdar://112625311
Reviewed by Simon Fraser.
There was a misspelling of a new AVFoundation option to be passed into -isPlayableExtendedMIMEType:options:
which prevents queries of `application/x-mpegURL; codecs="avc1.42E01E"` from succeding.
* Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.h:
* Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.mm:
* Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:
(WebCore::AVAssetMIMETypeCache::canDecodeExtendedType):
Canonical link: https://commits.webkit.org/266615@main
Identifier: 265870.305 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.341@safari-7616-branch
Commit: 197647aed0d01c9529714aff85aff6573a372a6e
https://github.com/WebKit/WebKit/commit/197647aed0d01c9529714aff85aff6573a372a6e
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ProcessThrottler.cpp
Log Message:
-----------
Cherry-pick f97a94e135dc. rdar://problem/113608299
Cherry-pick fe792fdab477. rdar://problem/113459152
Crash under ProcessThrottlerActivity::isValid()
https://bugs.webkit.org/show_bug.cgi?id=259886
rdar://113459152
Reviewed by Brent Fulgham.
ProcessThrottlerTimedActivity::activityTimedOut() was getting called, it
would set `m_activity` to nullptr, which would destroy the
ProcessThrottlerActivity. Because this was the last activity, it would
cause the prepareToSuspend logic to get called, which could cause
`m_activity` to get queried while in the middle of the assignment, causing
a crash.
To address the issue, I now use std::variant::swap() in activityTimedOut()
so that m_activity is in a good state (nullptr) when the
ProcessThrottlerActivity gets destroyed.
* Source/WebKit/UIProcess/ProcessThrottler.cpp:
(WebKit::ProcessThrottlerTimedActivity::activityTimedOut):
Canonical link: https://commits.webkit.org/266642@main
Identifier: 265870.306 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.342@safari-7616-branch
Commit: 48e95759306e09744cf1f53e0424873f8e98da9c
https://github.com/WebKit/WebKit/commit/48e95759306e09744cf1f53e0424873f8e98da9c
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick 0ea6efe2a2ee. rdar://problem/113516225
REGRESSION (iOS 16): Web content cannot capture Cmd+F keyboard events
https://bugs.webkit.org/show_bug.cgi?id=259892
rdar://113516225
Reviewed by Richard Robinson.
Following the addition of new keyboard shortcuts for find and replace in iOS
16, UIKit stopped giving WebKit a chance to handle Cmd+F (and related shortcuts)
prior to performing the system action.
In order to fix the issue, a UIKit change is required. However, once the issue
is fixed in UIKit, the find/replace actions will be dispatched to
`WKContentView` (the input delegate), rather than to `WKWebView`. Currently,
WebKit handles find/replace actions in `WKWebView`, in order to ensure support
for `WKPDFView`.
To prevent an issue following a UIKit fix, implement the find/replace actions on
`WKContentView`, forwarding calls back to `WKWebView` to perform the actual logic.
No new tests at this time, as there is no behavior change from this patch alone,
and a UIKit change is required to get the keyboard event working end-to-end.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView find:]):
(-[WKContentView findAndReplace:]):
(-[WKContentView findNext:]):
(-[WKContentView findPrevious:]):
Canonical link: https://commits.webkit.org/266663@main
Canonical link: https://commits.webkit.org/265870.343@safari-7616-branch
Commit: 964d180de1eb7471e0d2c1bc6866eb53e74ecb58
https://github.com/WebKit/WebKit/commit/964d180de1eb7471e0d2c1bc6866eb53e74ecb58
Author: Nikolaos Mouchtaris <nmouchtaris at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta-and-position-expected.html
A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta-and-position.html
A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta-expected.html
A LayoutTests/fast/scrolling/programmatic-scroll-merge-delta.html
A LayoutTests/fast/scrolling/programmatic-scroll-merge-position-and-delta-expected.html
A LayoutTests/fast/scrolling/programmatic-scroll-merge-position-and-delta.html
M Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.cpp
Log Message:
-----------
Cherry-pick 6707a4323f9f. rdar://problem/113608268
Cherry-pick 2f97007c9a1e. rdar://problem/113366817
[UI-side compositing] Webpage going blank when navigating diffs in https://whatpr.org/html/9537/238086f...f400a41/canvas.html#drawing-state
https://bugs.webkit.org/show_bug.cgi?id=259813
rdar://113366817
Reviewed by Simon Fraser and Cameron McCormack.
When getting multiple non-animated scroll requests, the current merging code loses the previous
scroll request if a new delta update comes in. To resolve this, add the two scroll requests together
if either or both are a delta update. Added a couple new tests for this since the tests in
imported/w3c/web-platform-tests/css/cssom-view/scroll-behavior-* do not cover this since they
are testing the web process position.
* Source/WebCore/page/scrolling/ScrollingCoordinatorTypes.cpp:
(WebCore::RequestedScrollData::merge):
Canonical link: https://commits.webkit.org/266646@main
Identifier: 265870.307 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.344@safari-7616-branch
Commit: 4b449e71a8dbdd65cbeb74f7d522fbf1e7e25c99
https://github.com/WebKit/WebKit/commit/4b449e71a8dbdd65cbeb74f7d522fbf1e7e25c99
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
Log Message:
-----------
Cherry-pick 1697dcdd99ec. rdar://problem/112627755
[visionOS] Audio is still heard after closing Safari
https://bugs.webkit.org/show_bug.cgi?id=259909
rdar://112627755
Reviewed by Eric Carlson.
The root cause of this issue is the same as 266665 at main. See that change for
additional details.
However, 266665 at main is an incomplete fix, as `AVSampleBufferRenderSynchronizer`'s
rate may still be non-zero, while the timebase's rate is changed to zero. In
this case `m_playing` continues to remain true, and playback gets resumed
following the interruption.
To fix, set `m_playing` based on the timebase rate, which is the most accurate
information available. AVSBRS's rate will eventually get set to zero too.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::effectiveRateChanged):
Canonical link: https://commits.webkit.org/266675@main
Canonical link: https://commits.webkit.org/265870.345@safari-7616-branch
Commit: cc483668138b69618d2da308e661951115904d41
https://github.com/WebKit/WebKit/commit/cc483668138b69618d2da308e661951115904d41
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.cpp
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebCore/platform/RuntimeApplicationChecks.h
M Source/WebCore/platform/cocoa/RuntimeApplicationChecksCocoa.mm
M Source/WebCore/style/Styleable.cpp
Log Message:
-----------
Cherry-pick 4798fb6802d2. rdar://problem/113608304
Cherry-pick 4f35a025c0ba. rdar://problem/112679186
REGRESSION (260398 at main): DOFUS Touch app: Color palette canvas element is blank during character creation
https://bugs.webkit.org/show_bug.cgi?id=259849
rdar://112679186
Reviewed by Wenson Hsieh.
With 260398 at main, fewer transitionend events may be emitted for cancelling transitions. Add a Quirk for DOFUS Touch.
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.cpp:
(WTF::computeSDKAlignedBehaviors):
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::needsResettingTransitionCancelsRunningTransitionQuirk const):
* Source/WebCore/page/Quirks.h:
* Source/WebCore/platform/RuntimeApplicationChecks.h:
* Source/WebCore/platform/cocoa/RuntimeApplicationChecksCocoa.mm:
(WebCore::IOSApplication::isDOFUSTouch):
* Source/WebCore/style/Styleable.cpp:
(WebCore::updateCSSTransitionsForStyleableAndProperty):
Canonical link: https://commits.webkit.org/266655@main
Identifier: 265870.309 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.346@safari-7616-branch
Commit: 3443658dae817635f3b1eee75bed79063f89cc4b
https://github.com/WebKit/WebKit/commit/3443658dae817635f3b1eee75bed79063f89cc4b
Author: Cameron McCormack <heycam at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/Path.cpp
M Source/WebCore/platform/graphics/PathImpl.h
M Source/WebCore/platform/graphics/PathSegment.cpp
M Source/WebCore/platform/graphics/PathSegment.h
M Source/WebCore/platform/graphics/PathSegmentData.cpp
M Source/WebCore/platform/graphics/PathSegmentData.h
M Source/WebCore/platform/graphics/PathStream.cpp
M Source/WebCore/platform/graphics/PathStream.h
M Source/WebCore/platform/graphics/cairo/PathCairo.cpp
M Source/WebCore/platform/graphics/cairo/PathCairo.h
M Source/WebCore/platform/graphics/cg/PathCG.cpp
M Source/WebCore/platform/graphics/cg/PathCG.h
Log Message:
-----------
Cherry-pick 68eec7e48f11. rdar://problem/113608292
Cherry-pick bc527208a62f. rdar://problem/111934640
Path::transform() should not trigger creation of a platform path
https://bugs.webkit.org/show_bug.cgi?id=258759
rdar://problem/111934640
Reviewed by Simon Fraser.
Many paths consist only of Move/Line/Quadratic/Cubic/Close segments, which are
all simple to apply an AffineTransform to. Transform single segment and PathStream
based paths in place when Path::transform() is called, to avoid the overhead of
generating a CGPath. If other segment types are in the path, continue to convert
to a platform path first.
Some WPT (path + transform) tests fail on GTK ports because the tests are fragile
to floating point calculations. The tests rotate the context by 90 degree and scale
it by 283 then they stroke a line to cover the whole canvas by the stroke color.
If we scale by 282, the last row in the canvas will not be stroked even without
this patch. On GKT port and with this patch, the last row is stroked but it is
anti-aliased with the background.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/platform/graphics/Path.cpp:
(WebCore::Path::transform):
* Source/WebCore/platform/graphics/PathImpl.h:
* Source/WebCore/platform/graphics/PathSegment.cpp:
(WebCore::PathSegment::canTransform const):
(WebCore::PathSegment::transform):
* Source/WebCore/platform/graphics/PathSegment.h:
* Source/WebCore/platform/graphics/PathSegmentData.cpp:
(WebCore::PathMoveTo::transform):
(WebCore::PathLineTo::transform):
(WebCore::PathQuadCurveTo::transform):
(WebCore::PathBezierCurveTo::transform):
(WebCore::PathDataLine::transform):
(WebCore::PathDataQuadCurve::transform):
(WebCore::PathDataBezierCurve::transform):
(WebCore::PathCloseSubpath::transform):
* Source/WebCore/platform/graphics/PathSegmentData.h:
* Source/WebCore/platform/graphics/PathStream.cpp:
(WebCore::PathStream::transform):
* Source/WebCore/platform/graphics/PathStream.h:
* Source/WebCore/platform/graphics/cairo/PathCairo.cpp:
(WebCore::PathCairo::transform):
* Source/WebCore/platform/graphics/cairo/PathCairo.h:
* Source/WebCore/platform/graphics/cg/PathCG.cpp:
(WebCore::PathCG::transform):
* Source/WebCore/platform/graphics/cg/PathCG.h:
Canonical link: https://commits.webkit.org/266672@main
Identifier: 265870.311 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.347@safari-7616-branch
Commit: 6c327e7553b83141b728a3b38aaaa3b19daaa70d
https://github.com/WebKit/WebKit/commit/6c327e7553b83141b728a3b38aaaa3b19daaa70d
Author: Karl Dubost <karlcow at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick a1ccdbec71a4. rdar://problem/107636342
Remove Quirk shouldDispatchSimulatedMouseEvents for nba.com
https://bugs.webkit.org/show_bug.cgi?id=259332
rdar://107636342
Reviewed by Brent Fulgham.
This quirk is not necessary anymore for the website nba.com.
It also creates a secondary issue for the website developers on iPad,
as explained in https://bugs.webkit.org/show_bug.cgi?id=259272
Removing the Quirk resolved the secondary issue.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldDispatchSimulatedMouseEvents const):
Canonical link: https://commits.webkit.org/266691@main
Canonical link: https://commits.webkit.org/265870.348@safari-7616-branch
Commit: 0fd4f44133902c24d46ce28a8a8f7765374d4618
https://github.com/WebKit/WebKit/commit/0fd4f44133902c24d46ce28a8a8f7765374d4618
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/ThirdParty/libwebrtc/Source/webrtc/api/video_codecs/h264_profile_level_id.cc
Log Message:
-----------
Cherry-pick 1d2056ae612b. rdar://problem/113608273
Cherry-pick 9b88dbfe47d7. rdar://problem/113008968
[RTCVideoEncoderH264 initWithCodecInfo] should cope with invalid profile level id
https://bugs.webkit.org/show_bug.cgi?id=259592
rdar://113008968
Reviewed by Eric Carlson.
With WebCodecs, we allow JS to pass any profile level id to RTCVideoEncoderH264.
For now, we are defaulting to a default profile level id if none is matching.
A future patch should probably make sure that we return an error so that JS knows the configuration is not unsupported.
* Source/ThirdParty/libwebrtc/Source/webrtc/api/video_codecs/h264_profile_level_id.cc:
Canonical link: https://commits.webkit.org/266392@main
Identifier: 265423.759 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.349@safari-7616-branch
Commit: 0d1f1dc56bac1f2755b6783e46677299d28ac6cb
https://github.com/WebKit/WebKit/commit/0d1f1dc56bac1f2755b6783e46677299d28ac6cb
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkDataTask.cpp
Log Message:
-----------
Cherry-pick 1bb13d33aa72. rdar://problem/113608286
Cherry-pick c0a7c3bf2d79. rdar://problem/113530127
Regression(266594 at main) Crash under NetworkSession::unregisterNetworkDataTask()
https://bugs.webkit.org/show_bug.cgi?id=259910
<rdar://113530127>
Reviewed by J Pascoe.
NetworkDataTask::m_session is a WeakPtr and may thus be null by the time the
NetworkDataTask runs. Null check it before calling `unregisterNetworkDataTask()`
on it.
* Source/WebKit/NetworkProcess/NetworkDataTask.cpp:
(WebKit::NetworkDataTask::~NetworkDataTask):
Canonical link: https://commits.webkit.org/266690@main
Identifier: 265423.760 at safari-7616.1.27.10-branch
Canonical link: https://commits.webkit.org/265870.350@safari-7616-branch
Commit: 9737242afb8e977958dd36ac338cc6f5f72be91e
https://github.com/WebKit/WebKit/commit/9737242afb8e977958dd36ac338cc6f5f72be91e
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/GPUProcess/media/RemoteAudioDestinationManager.cpp
M Source/WebKit/GPUProcess/media/RemoteAudioDestinationManager.h
M Source/WebKit/GPUProcess/media/RemoteAudioDestinationManager.messages.in
M Source/WebKit/WebProcess/GPU/media/RemoteAudioDestinationProxy.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteAudioDestinationProxy.h
Log Message:
-----------
Cherry-pick f35686d63822. rdar://problem/112621241
Web Audio glitches when hardware buffer size is not divisible by 128
https://bugs.webkit.org/show_bug.cgi?id=259899
<radar://112621241>
Reviewed by Chris Dumez.
Whenever the buffer size of the hardware was not a multiple of 128, the
audio would not be in sync with the client leading to audible artifacts.
We can fix this by passing the number of frames from AURemoteIO to the
web process and rendering all of the frames that AURemoteIO asked us to render.
* Source/WebKit/GPUProcess/media/RemoteAudioDestinationManager.cpp:
(WebKit::RemoteAudioDestinationManager::createAudioDestination):
Create a shared memory member variable which we can write the frame count from
AURemoteUI to.
* Source/WebKit/GPUProcess/media/RemoteAudioDestinationManager.h:
Update member function parameters.
* Source/WebKit/GPUProcess/media/RemoteAudioDestinationManager.messages.in:
Pass the shared memory handle to the web process.
* Source/WebKit/WebProcess/GPU/media/RemoteAudioDestinationProxy.cpp:
(WebKit::RemoteAudioDestinationProxy::startRenderingThread):
Get the number of frames to render from the shared memory with the GPU process.
(WebKit::RemoteAudioDestinationProxy::connection):
Create the shared memory handle in the web process and pass it to the GPU process.
We could create it the other way around, but it would require adding another IPC
message, which seems uncessary for this purpose.
* Source/WebKit/WebProcess/GPU/media/RemoteAudioDestinationProxy.h:
Add shared memory member variable.
Canonical link: https://commits.webkit.org/266747@main
Canonical link: https://commits.webkit.org/265870.351@safari-7616-branch
Commit: 364fbe86185ab59332a3a205452d7fbf0e34121c
https://github.com/WebKit/WebKit/commit/364fbe86185ab59332a3a205452d7fbf0e34121c
Author: Luming Yin <luming_yin at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebCore/platform/ScrollbarTheme.h
M Source/WebCore/platform/graphics/GraphicsLayer.cpp
M Source/WebCore/platform/graphics/GraphicsLayer.h
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebCore/platform/mac/ScrollbarThemeMac.h
M Source/WebCore/platform/mac/ScrollbarThemeMac.mm
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm
Log Message:
-----------
Cherry-pick b0c474278a21. rdar://problem/113648503
[macOS] Remove linen texture when zoomed or rubber banding
https://bugs.webkit.org/show_bug.cgi?id=260002
rdar://113648503
Reviewed by Simon Fraser.
When running on OS X Mavericks 10.9 and earlier, web views used to draw a gray linen texture when zoomed out or
rubber banding. This design has been replaced with a flat color since the OS X Yosemite 10.10, but we continue
to draw the linen texture, only to have it covered by an opaque foreground layer.
In popup windows, this linen texture may unexpectedly become visible in some circumstances on macOS Sonoma. To
reduce resource usage and remove a source of layout bugs, drop the linen texture implementation completely.
* Source/WebCore/platform/ScrollbarTheme.h:
(WebCore::ScrollbarTheme::setUpOverhangAreasLayerContents): Deleted.
(WebCore::ScrollbarTheme::setUpContentShadowLayer): Deleted.
Removed since these are no longer used on supported versions of macOS.
* Source/WebCore/platform/graphics/GraphicsLayer.cpp:
(WebCore::operator<<):
Remove the ScrollingOverhang appearance since we no longer need to draw any linen.
* Source/WebCore/platform/graphics/GraphicsLayer.h:
Same as above.
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::updateCustomAppearance):
Do not set up or remove the linen overhang area background.
* Source/WebCore/platform/mac/ScrollbarThemeMac.h:
* Source/WebCore/platform/mac/ScrollbarThemeMac.mm:
(WebCore::linenBackgroundColor): Deleted.
(WebCore::ScrollbarThemeMac::setUpOverhangAreaBackground): Deleted.
(WebCore::ScrollbarThemeMac::removeOverhangAreaBackground): Deleted.
(WebCore::ScrollbarThemeMac::setUpOverhangAreasLayerContents): Deleted.
(WebCore::ScrollbarThemeMac::setUpContentShadowLayer): Deleted.
Remove code to set up and update the linen overhang area background.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateLayerForOverhangAreasBackgroundColor):
Stop setting a custom linen appearance for the overhang area.
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm:
(WebKit::updateCustomAppearance):
Do not set up or remove the linen overhang area background.
Canonical link: https://commits.webkit.org/266752@main
Canonical link: https://commits.webkit.org/265870.352@safari-7616-branch
Commit: 3fe3796aff8aca7cc62076e4a5e7755fdd506eaa
https://github.com/WebKit/WebKit/commit/3fe3796aff8aca7cc62076e4a5e7755fdd506eaa
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Revert "c74570e69d6b Cherry-pick 6e40b4c5f442. rdar://problem/113604929"
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _holdWindowResizeSnapshotIfNeeded]): Deleted.
Identifier: 265870.353 at safari-7616-branch
Commit: 3b98a13bb18cf04f321e6d5c4014151ab1110457
https://github.com/WebKit/WebKit/commit/3b98a13bb18cf04f321e6d5c4014151ab1110457
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M LayoutTests/resources/ui-helper.js
M Source/WebKit/UIProcess/ios/WKTextSelectionRect.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
Revert "a94eb47144db Cherry-pick 69d07a6b99c8. rdar://problem/111793617"
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.getSelectionEndGrabberViewShapePathDescription.return.new.Promise.): Deleted.
(window.UIHelper.getSelectionEndGrabberViewShapePathDescription.return.new.Promise): Deleted.
(window.UIHelper.getSelectionEndGrabberViewShapePathDescription): Deleted.
* Source/WebKit/UIProcess/ios/WKTextSelectionRect.mm:
(-[WKTextSelectionRect _customHandleInfo]):
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::selectionEndGrabberViewRect const):
(WTR::UIScriptController::selectionEndGrabberViewShapePathDescription const): Deleted.
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::selectionEndGrabberViewShapePathDescription const): Deleted.
Identifier: 265870.354 at safari-7616-branch
Commit: 3c3db27a9013effedff45f97b473f8a29fc348d1
https://github.com/WebKit/WebKit/commit/3c3db27a9013effedff45f97b473f8a29fc348d1
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
Log Message:
-----------
Cherry-pick 6e40b4c5f442. rdar://problem/113604929
Cherry-pick 3d721c09585b. rdar://problem/111534888
REGRESSION (UI-side compositing): Jumpy full screen transition animation
https://bugs.webkit.org/show_bug.cgi?id=259375
rdar://111534888
Reviewed by Wenson Hsieh.
With UI-side compositing, when entering or exiting window fullscreen mode, the transition is
sometimes jumpy. This happens in cases where the UI process resizes before the web content has a
chance to resize. The web content and the UI Process should always resize in the same CA commit.
Fix by adopting an AppKit SPI to defer entering or exiting window fullscreen mode until the web
content has actually been resized to the new size. This is done by using a "window snapshot readiness handler".
* Source/WTF/wtf/PlatformHave.h:
Add a new `HAVE` definition to only enable this on macOS, and only on versions where the SPI exists.
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]):
Invokes the readiness handler and then resets it, indicating to AppKit that the full screen should
be allowed to resume.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]):
(-[WKView _web_windowWillExitFullScreen]):
Stub methods required to compile legacy WebKit.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
When `setFrameSize` gets called with the new frame size, the UI process waits for the next presentation
update of the web prcoess. Once in the completion handler, we know that the web content has properly
resized, and so we should now invalidate the readiness handler.
(-[WKWebView _web_windowWillEnterFullScreen]):
(-[WKWebView _web_windowWillExitFullScreen]):
Upon receiving one of these notifications, we take out a window snapshot readiness handler and store
it. This tells AppKit to defer the final stage of the enter and exit full screen animations until
the handler is invoked.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
In some cases, `setFrameSize` would early return inside of `didChangeFrameSize` due to these set of
methods. This caused the bug to still reproduce, since the new drawing area size was no longer being set.
These methods have long been not actually needed, so their implementations are now removed and there is
no longer a need for an early return.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]):
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]):
(WebKit::WebViewImpl::windowWillEnterFullScreen):
(WebKit::WebViewImpl::windowWillExitFullScreen):
When entering or exiting full screen, we now listen to their respective notifications.
Canonical link: https://commits.webkit.org/266273@main
Identifier: 265870.296 at safari-7616.1.27.10-branch
Identifier: 265870.355 at safari-7616-branch
Commit: 93aace6d930f64afed215ed2b3bf9fe4867247fa
https://github.com/WebKit/WebKit/commit/93aace6d930f64afed215ed2b3bf9fe4867247fa
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-10 (Thu, 10 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Cherry-pick ccb976224ab6. rdar://problem/113604929
Cherry-pick 265870.295 at safari-7616.1.27.10-branch (ccb976224ab6). rdar://111534888
Cherry-pick 43da1fd1587a. rdar://problem/111534888
WebKit Media: Toggling fullscreen fails to work
https://bugs.webkit.org/show_bug.cgi?id=259760
rdar://111534888
Reviewed by Aditya Keerthi.
The window resize handler is created when receiving the `will{Enter|Exit}FullScreen` notification,
and is then invalidated as a result of `setFrameSize` being called. However, when transiting to/from
element full screen, `setFrameSize` is called before the notification is posted, instead of after.
This causes the handler to never be invalidated.
Fix by creating the handler directly inside `setFrameSize`, and not rely on the full screen
notifications at all. This is ok since `_holdResizeSnapshotWithReason` only returns a non-nil block
when entering or exiting full screen, so it has no effect in other cases.
No new tests, since all tests in `FullscreenVideoTextRecognition` already test this behavior in some
configurations.
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _holdWindowResizeSnapshotWithReason:]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Canonical link: https://commits.webkit.org/266558@main
Identifier: 265870.295 at safari-7616.1.27.10-branch
Identifier: 265870.356 at safari-7616-branch
Commit: 8e677b301cae6b622ea100483c89269d71ba1470
https://github.com/WebKit/WebKit/commit/8e677b301cae6b622ea100483c89269d71ba1470
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-11 (Fri, 11 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm
Log Message:
-----------
Main frame URL is wrong after server-side redirect to a page serving the COOP header
https://bugs.webkit.org/show_bug.cgi?id=260046
rdar://111855179
Reviewed by Brent Fulgham and Alex Christensen.
In the poc, the page is opening a popup (without opener) to the same origin URL1.
This URL1 does a server-side redirect to URL2 which serves the `COOP: same-origin`
HTTP header. After the navigation, Safari was displaying URL1 instead of URL2 in
the URL bar.
It is important to note that that 2 process-swap occur here. The first occurs when
we do the navigation to URL1 in a popup that doesn't have an opener (in the
decidePolicyForNavigationAction). The second one occurs when we receive the
COOP header from URL2 (on navigation response).
In ProvisionalPageProxy::didCreateMainFrame(), we have code which does the following:
```
if (previousMainFrame && !previousMainFrame->provisionalURL().isEmpty()) {
// In case of a process swap after response policy, the didStartProvisionalLoad already happened but the new main frame doesn't know about it
// so we need to tell it so it can update its provisional URL.
m_mainFrame->didStartProvisionalLoad(previousMainFrame->provisionalURL());
}
```
During the second process-swap, we forward the provisional URL from the committed
frame to the provisional one. This is because the didStartProvisionalLoad IPC was
handled by the committed main frame, before we decided to process-swap on resource
response later on. As a result, the provisional main frame doesn't know yet about
the provisional load and we have to let it know about it so it sets its provisional
URL.
This worked fine in the usual case where the COOP process-swap doesn't follow
another process swap. However, in this case, the provisional URL got updated by
an earlier server side redirect which got handled by a provisional frame, not the
committed one. As a result, the committed frame didn't know about the latest
provisional URL, only the original one before the server side redirect.
To address the issue, whenever a provisional main frame receives a server-side
redirect, we now let the committed main frame know about it too so that the
committed frame's provisional URL always stays up-to-date. As a result, when
ProvisionalPageProxy::didCreateMainFrame() forwards the committed frame's URL to
the new provisional frame, it is now accurate.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:
Canonical link: https://commits.webkit.org/265870.357@safari-7616-branch
Commit: 58df0c6439362245853daf58acce7cd2f3153e08
https://github.com/WebKit/WebKit/commit/58df0c6439362245853daf58acce7cd2f3153e08
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-11 (Fri, 11 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Revert "Cherry-pick ccb976224ab6. rdar://problem/113604929"
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _holdWindowResizeSnapshotIfNeeded]): Deleted.
Identifier: 265870.358 at safari-7616-branch
Commit: 4f7228135c6b051fb3717648d927bf396811d71d
https://github.com/WebKit/WebKit/commit/4f7228135c6b051fb3717648d927bf396811d71d
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-11 (Fri, 11 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
Log Message:
-----------
Revert "3c3db27a9013 Cherry-pick 6e40b4c5f442. rdar://problem/113604929"
* Source/WTF/wtf/PlatformHave.h:
Identifier: 265870.359 at safari-7616-branch
Commit: 9121c2be172d173bc982a13a572bef6d4e720b46
https://github.com/WebKit/WebKit/commit/9121c2be172d173bc982a13a572bef6d4e720b46
Author: Andy Estes <aestes at apple.com>
Date: 2023-08-11 (Fri, 11 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.h
M Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm
Log Message:
-----------
Cherry-pick e1c50afade41. rdar://problem/112780721
REGRESSION(260575 at main): YouTube videos sometimes do not resize properly in fullscreen and theater modes
https://bugs.webkit.org/show_bug.cgi?id=260025
rdar://112780721
Reviewed by Mike Wyrzykowski.
WebAVPlayerLayer needs to know its video's dimensions in order to properly lay out its sublayers.
When video dimensions change, VideoFullscreenManagerProxy caches the dimensions in its
VideoFullscreenModelContext, updates the WebAVPlayerLayer with the new dimensions, and calls
-setNeedsLayout on the layer to trigger a re-layout of its sublayers. However, in rare cases, video
dimensions can change before the WebAVPlayerLayer is created. While VideoFullscreenModelContext
would cache the dimensions, the WebAVPlayerLayer would not be told about these cached dimensions
when it was created, leading it to believe the video had dimensions of 0x0 during -layoutSublayers.
Fixed this by setting VideoFullscreenModelContext's cached video dimensions on the WebAVPlayerLayer
at creation time to ensure it always lays out with the most recent video dimensions sent to it from
the WebContent process.
No new tests as I couldn't determine a way to capture the necessary timing in a test.
* Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.h:
* Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm:
(WebKit::VideoFullscreenModelContext::setPlayerLayer):
Canonical link: https://commits.webkit.org/266807@main
Identifier: 265870.360 at safari-7616-branch
Commit: 0c06090dad277c76e444c9d526e73919b28c010a
https://github.com/WebKit/WebKit/commit/0c06090dad277c76e444c9d526e73919b28c010a
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/rendering/RenderVideo.cpp
M Source/WebCore/rendering/RenderVideo.h
Log Message:
-----------
Cherry-pick deb6f171e956. rdar://problem/113731917
Revert Resizing video on YouTube can result in aliasing
https://bugs.webkit.org/show_bug.cgi?id=259171
<radar://113731917>
Unreviewed revert 266284 at main as it causes a regression opening to fullscreen.
* Source/WebCore/rendering/RenderVideo.cpp:
(WebCore::areAspectRatiosEssentiallyEqual):
(WebCore::RenderVideo::videoBox const):
(WebCore::RenderVideo::updatePlayer):
(WebCore::contentSizeAlmostEqualsFrameSize): Deleted.
(WebCore::RenderVideo::inElementOrVideoFullscreen const): Deleted.
* Source/WebCore/rendering/RenderVideo.h:
Canonical link: https://commits.webkit.org/266809@main
Identifier: 265870.361 at safari-7616-branch
Commit: f5747d323aaeb4226d48cdc72dd12857b65fd46b
https://github.com/WebKit/WebKit/commit/f5747d323aaeb4226d48cdc72dd12857b65fd46b
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick 6f57d245d733. rdar://problem/113650540
[visionOS] Fullscreen element doesn't lay out correctly when WKWebView's scale is not initially 1
https://bugs.webkit.org/show_bug.cgi?id=260031
<radar://113650540>
Reviewed by Aditya Keerthi.
Set the viewScale to 1 in fullscreen after saving the web view state.
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
Canonical link: https://commits.webkit.org/266822@main
Identifier: 265870.362 at safari-7616-branch
Commit: 328e02a9fdf0672973b6c4ea62136db0eb84d895
https://github.com/WebKit/WebKit/commit/328e02a9fdf0672973b6c4ea62136db0eb84d895
Author: Megan Gardner <megan_gardner at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/platform/ios/Device.cpp
M Source/WebCore/platform/ios/Device.h
M Source/WebCore/platform/ios/LocalCurrentTraitCollection.mm
M Source/WebKit/Shared/UserInterfaceIdiom.h
M Source/WebKit/Shared/UserInterfaceIdiom.mm
M Source/WebKit/Shared/UserInterfaceIdiom.serialization.in
M Source/WebKit/Shared/WebPreferencesDefaultValues.cpp
M Source/WebKit/UIProcess/Cocoa/WKShareSheet.mm
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick 9776a6b158e1. rdar://problem/113531570
Update to Vision idiom.
https://bugs.webkit.org/show_bug.cgi?id=259907
rdar://113531570
Reviewed by Wenson Hsieh.
Updated to new idiom now that reality idiom is deprecated.
* Source/WebCore/platform/ios/Device.cpp:
(WebCore::deviceClassIsVision):
(WebCore::deviceClassIsReality): Deleted.
* Source/WebCore/platform/ios/Device.h:
* Source/WebCore/platform/ios/LocalCurrentTraitCollection.mm:
(WebCore::adjustedTraitCollection):
* Source/WebKit/Shared/UserInterfaceIdiom.h:
* Source/WebKit/Shared/UserInterfaceIdiom.mm:
(WebKit::currentUserInterfaceIdiomIsVision):
(WebKit::updateCurrentUserInterfaceIdiom):
(WebKit::currentUserInterfaceIdiomIsReality): Deleted.
* Source/WebKit/Shared/UserInterfaceIdiom.serialization.in:
* Source/WebKit/Shared/WebPreferencesDefaultValues.cpp:
(WebKit::defaultAlternateFormControlDesignEnabled):
(WebKit::defaultVideoFullscreenRequiresElementFullscreen):
* Source/WebKit/UIProcess/Cocoa/WKShareSheet.mm:
(-[WKShareSheet presentWithShareDataArray:inRect:]):
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(WebKit::useSpatialFullScreenTransition):
Canonical link: https://commits.webkit.org/266673@main
Identifier: 265870.363 at safari-7616-branch
Commit: 9469be416cbeb0851a7ac7d48b3c8d10767ce455
https://github.com/WebKit/WebKit/commit/9469be416cbeb0851a7ac7d48b3c8d10767ce455
Author: Megan Gardner <megan_gardner at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj
M Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h
A Source/WebCore/PAL/pal/system/ios/Device.cpp
A Source/WebCore/PAL/pal/system/ios/Device.h
A Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.h
A Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.mm
M Source/WebCore/SourcesCocoa.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebCore/page/NavigatorBase.cpp
M Source/WebCore/page/ScreenOrientationType.h
M Source/WebCore/page/cocoa/SettingsBaseCocoa.mm
M Source/WebCore/platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp
R Source/WebCore/platform/ios/Device.cpp
R Source/WebCore/platform/ios/Device.h
M Source/WebCore/platform/ios/PlatformScreenIOS.mm
M Source/WebCore/platform/ios/UserAgentIOS.mm
M Source/WebCore/platform/network/BlobRegistry.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/Scripts/webkit/messages.py
R Source/WebKit/Shared/UserInterfaceIdiom.h
R Source/WebKit/Shared/UserInterfaceIdiom.mm
M Source/WebKit/Shared/UserInterfaceIdiom.serialization.in
M Source/WebKit/Shared/WebPreferencesDefaultValues.cpp
M Source/WebKit/Shared/WebProcessCreationParameters.h
M Source/WebKit/Shared/WebProcessCreationParameters.serialization.in
M Source/WebKit/Shared/ios/WebPreferencesDefaultValuesIOS.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewConfiguration.mm
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/UIProcess/ios/SmartMagnificationController.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WebDataListSuggestionsDropdownIOS.mm
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/UIProcess/ios/forms/WKDateTimeInputControl.mm
M Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm
M Source/WebKit/UIProcess/ios/forms/WKFormColorControl.mm
M Source/WebKit/UIProcess/ios/forms/WKFormSelectControl.mm
M Source/WebKit/UIProcess/ios/forms/WKFormSelectPicker.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Source/WebKit/WebProcess/WebProcess.h
M Source/WebKit/WebProcess/WebProcess.messages.in
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
M Source/WebKitLegacy/mac/WebView/WebPreferencesDefaultValues.mm
Log Message:
-----------
Cherry-pick 7ef05e80175b. rdar://problem/107389870
Cherry-pick 266710 at main (7ef05e80175b). rdar://107389870
System fonts are not displayed in the correct style for their idiom in compatibility mode on visionOS.
https://bugs.webkit.org/show_bug.cgi?id=259844
rdar://107389870
Reviewed by Tim Horton.
When requesting information about system fonts, we were always going with the current idiom, which for
the web-process will always match the device. If the UIProcess is in compatibility mode, we need
to make sure that we are using the idiom that it is in, or we will get system fonts on the wrong size.
We move the required classes into PAL so they can be used from WebCore while maintaining platform agnosticism
in WebCore itself, and then read the appropriate flag in the font code. Since the font database is
multithreaded, we also need to ensure that the flag is thread-safe.
* Source/WebCore/PAL/pal/system/ios/Device.cpp: Renamed from Source/WebCore/platform/ios/Device.cpp.
(PAL::deviceClassIsSmallScreen):
(PAL::deviceClassIsReality):
(PAL::deviceName):
(PAL::deviceHasIPadCapability):
* Source/WebCore/PAL/pal/system/ios/Device.h: Renamed from Source/WebCore/platform/ios/Device.h.
* Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.h: Renamed from Source/WebKit/Shared/UserInterfaceIdiom.h.
* Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.mm: Renamed from Source/WebKit/Shared/UserInterfaceIdiom.mm.
(PAL::currentUserInterfaceIdiomIsSmallScreen):
(PAL::currentUserInterfaceIdiomIsReality):
(PAL::currentUserInterfaceIdiom):
(PAL::setCurrentUserInterfaceIdiom):
(PAL::updateCurrentUserInterfaceIdiom):
Canonical link: https://commits.webkit.org/266710@main
Identifier: 265870.364 at safari-7616-branch
Commit: 9ed91adb323f5529fcb9519be0ab034ce1f4a663
https://github.com/WebKit/WebKit/commit/9ed91adb323f5529fcb9519be0ab034ce1f4a663
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
Log Message:
-----------
Cherry-pick 0a8efe4a7da6. rdar://problem/112638189
[visionOS] Videos on apple.com are not shown in compatibility mode when using a mobile UA
https://bugs.webkit.org/show_bug.cgi?id=260027
rdar://112638189
Reviewed by Mike Wyrzykowski, Megan Gardner and Tim Horton.
apple.com product pages (like https://www.apple.com/apple-vision-pro/) often
have a "Watch the film" button that displays a video and begins playback.
Depending on the user agent, as well as the relationship between screen
size (`Screen.availWidth` and `Screen.availHeight`) and viewport size, apple.com
uses different logic (JavaScript + DOM structure) for the video flow.
On the mobile site, apple.com simply begins playback on a 1x1 <video>. On iPhone,
this results in the video entering fullscreen automatically, as the `playsinline`
is missing. On the desktop site, apple.com simply shows the video inline, and sizes
it to fill the viewport.
Importantly, a mobile UA is not enough to get apple.com's mobile site, they also
account for screen size. Due to our screen size override on visionOS, added in
258005 at main, and the fact that apps running compatibility mode report other sizes
as if they were an iPad, apple.com ends up using the mobile logic. This logic
fails, as visionOS/iPadOS do not have automatic fullscreen on playback, leaving
a 1x1 <video> element behind.
To fix, do not apply the screen size override in compatibility mode. Apps in
compatibility mode have the exact same fullscreen behavior as iPad, and the
fix in 258005 at main is unnecessary there.
Note that the same bug can occur in Safari, depending on the size the window
is resized to. However, that is an existing site issue that will require a
fix by apple.com.
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::availableScreenSize):
(WebKit::WebPageProxy::overrideScreenSize):
Canonical link: https://commits.webkit.org/266780@main
Identifier: 265870.365 at safari-7616-branch
Commit: 9d533c5819372688976f5c5feb11207e42f2e461
https://github.com/WebKit/WebKit/commit/9d533c5819372688976f5c5feb11207e42f2e461
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/Configurations/WebCore.xcconfig
M Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h
M Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.h
M Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.mm
M Source/WebCore/platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp
M Source/WebKit/Shared/WebPreferencesDefaultValues.cpp
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
Log Message:
-----------
Cherry-pick eb8b191e357f. rdar://problem/113417307
Cherry-pick 266799 at main (eb8b191e357f). rdar://113417307
CoreText font platform should respect legacy visionOS styles when relevant
https://bugs.webkit.org/show_bug.cgi?id=260042
rdar://113417307
Reviewed by Aditya Keerthi and Mike Wyrzykowski.
The Web Content process needs to follow the host application's sub-idiom
for the purposes of font lookup, instead of just getting the default table
for its bundle identifier, to ensure correct resolution of system font styles.
* Source/WebCore/Configurations/WebCore.xcconfig:
Link RuntimeSupport on visionOS.
* Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.h:
* Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.mm:
(PAL::currentUserInterfaceIdiomIsVisionOrVisionLegacy):
(PAL::currentUserInterfaceIdiomIsVisionLegacy):
Add getters that can determine which visionOS sub-idiom you're using.
All clients (the vast majority) that don't care about the points-per-meter
value should use `IsVisionOrVisionLegacy`.
(PAL::determineVisionSubidiom):
Determine the sub-idiom by checking _RSCurrentProcessUsesNewPointsPerMeter.
(PAL::updateCurrentUserInterfaceIdiom):
(PAL::currentUserInterfaceIdiomIsVision): Deleted.
* Source/WebCore/platform/graphics/cocoa/SystemFontDatabaseCoreText.cpp:
(WebCore::fontPlatform):
Determine the correct CoreText font platform based on the sub-idiom.
* Source/WebKit/Shared/WebPreferencesDefaultValues.cpp:
(WebKit::defaultAlternateFormControlDesignEnabled):
(WebKit::defaultVideoFullscreenRequiresElementFullscreen):
Adopt the new getters.
Canonical link: https://commits.webkit.org/266799@main
Identifier: 265870.366 at safari-7616-branch
Commit: f6484ee0bc946faf326d928f5f5a9a8f44229484
https://github.com/WebKit/WebKit/commit/f6484ee0bc946faf326d928f5f5a9a8f44229484
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebKit/Shared/UserInterfaceIdiom.serialization.in
Log Message:
-----------
Cherry-pick 3985bf0d518b. rdar://problem/113731316
Received invalid message: 'WebProcess_InitializeWebProcess' after 266799 at main
https://bugs.webkit.org/show_bug.cgi?id=260056
Reviewed by Richard Robinson.
* Source/WebKit/Shared/UserInterfaceIdiom.serialization.in:
I forgot to update this file!
Canonical link: https://commits.webkit.org/266806@main
Identifier: 265870.367 at safari-7616-branch
Commit: ecb19b22473e206de3f3ad5515f57c431737b5d3
https://github.com/WebKit/WebKit/commit/ecb19b22473e206de3f3ad5515f57c431737b5d3
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/platform/cocoa/MIMETypeRegistryCocoa.mm
M Tools/TestWebKitAPI/Tests/WebCore/MIMETypeRegistry.cpp
Log Message:
-----------
Cherry-pick 97c1b7fd0b15. rdar://problem/113774128
Regression(266049 at main) Crash in MIMETypeRegistry::preferredExtensionForMIMEType
https://bugs.webkit.org/show_bug.cgi?id=260098
rdar://113774128
Reviewed by Aditya Keerthi.
Make sure we early return if `type` is a null string to avoid doing a HashMap
lookup with it later on, which would cause crashes.
* Source/WebCore/platform/cocoa/MIMETypeRegistryCocoa.mm:
(WebCore::MIMETypeRegistry::preferredExtensionForMIMEType):
* Tools/TestWebKitAPI/Tests/WebCore/MIMETypeRegistry.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/266837@main
Identifier: 265870.368 at safari-7616-branch
Commit: 5a9010373b3167e2e0ed58184fff0da9114e11ea
https://github.com/WebKit/WebKit/commit/5a9010373b3167e2e0ed58184fff0da9114e11ea
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
A LayoutTests/media/media-source/media-source-rendering-update-count-expected.txt
A LayoutTests/media/media-source/media-source-rendering-update-count.html
M LayoutTests/platform/gtk/TestExpectations
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
Log Message:
-----------
Cherry-pick 050470812f66. rdar://problem/113643405
REGRESSION (Sonoma): Media elements can trigger extra compositing updates, increasing power usage
https://bugs.webkit.org/show_bug.cgi?id=260095
rdar://113643405
Reviewed by Jer Noble.
After media layer double-hosting (260575 at main) and subsequent fixes (261455 at main, 264812 at main)
every call to GraphicsLayerCA::setContentsToVideoElement() triggered layer tree mutations via
updateVideoGravity() and noteSublayersChanged(), which schedule rendering updates. These in
turn result in CA commits in the UI process, causing a meassurable power regression.
Fix by early returning from GraphicsLayerCA::setContentsToVideoElement() when nothing has changed.
* LayoutTests/media/media-source/media-source-rendering-update-count-expected.txt: Added.
* LayoutTests/media/media-source/media-source-rendering-update-count.html: Added.
* LayoutTests/platform/gtk/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::setContentsToVideoElement):
Canonical link: https://commits.webkit.org/266855@main
Identifier: 265870.369 at safari-7616-branch
Commit: 4dafc44ae66d9b073e1a33d5ded9662ddfde1fc4
https://github.com/WebKit/WebKit/commit/4dafc44ae66d9b073e1a33d5ded9662ddfde1fc4
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDMSessionClearKey.cpp
Log Message:
-----------
Cherry-pick 7cfbb042f9c0. rdar://problem/112642265
Remove JSC VM usage from LegacyCDMSessionClearKey
https://bugs.webkit.org/show_bug.cgi?id=259386
rdar://112642265
Reviewed by Darin Adler.
LegacyCDMSessionClearKey is creating JSC VM and JSGlobalObject just to parse JSON!!
This is significantly costly. JSC::VM and JSGlobalObject are large JS environments.
Instantiation takes some time & it takes memory. They should not be required just to parse JSON.
Furthermore, this code runs on GPUProcess, and this part is the sole reason why GPUProcess still
creates JSC VM.
We should just use WTF::JSON::Value.
* Source/WebCore/Modules/encryptedmedia/legacy/LegacyCDMSessionClearKey.cpp:
(WebCore::CDMSessionClearKey::update):
(WebCore::CDMSessionClearKey::cachedKeyForKeyID const):
(WebCore::clearKeyVM): Deleted.
Canonical link: https://commits.webkit.org/266282@main
Identifier: 265870.370 at safari-7616-branch
Commit: 64bf67dd5a08ad2e7d386908373b4552043e2a90
https://github.com/WebKit/WebKit/commit/64bf67dd5a08ad2e7d386908373b4552043e2a90
Author: Vitor Roriz <vitor.roriz at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-lists/counter-reset-increment-overflow-underflow-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-lists/counter-reset-increment-overflow-underflow-ref.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-lists/counter-reset-increment-overflow-underflow.html
M Source/WTF/wtf/CheckedArithmetic.h
M Source/WebCore/rendering/CounterNode.cpp
Log Message:
-----------
Cherry-pick a3717f099f77. rdar://problem/111743827
Prevent counter values from over/underflowing
https://bugs.webkit.org/show_bug.cgi?id=258730
rdar://111743827
Reviewed by Chris Dumez.
We will ignore the counter-increment() operation if
this would result in overflow/underflow for compatibility
with other vendors (https://github.com/w3c/csswg-drafts/issues/9029).
* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/counter-reset-increment-overflow-underflow-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/counter-reset-increment-overflow-underflow-ref.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-lists/counter-reset-increment-overflow-underflow.html: Added.
* Source/WTF/wtf/CheckedArithmetic.h:
(WTF::sumIfNoOverflowOrFirstValue):
* Source/WebCore/rendering/CounterNode.cpp:
(WebCore::CounterNode::computeCountInParent const):
Canonical link: https://commits.webkit.org/266817@main
Identifier: 265870.371 at safari-7616-branch
Commit: 2e225adc6aaf24aabadb5f84706245fc79736037
https://github.com/WebKit/WebKit/commit/2e225adc6aaf24aabadb5f84706245fc79736037
Author: Ryan Fuller <ryanfuller at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick 8222cb10b1d0. rdar://problem/113732040
[visionOS] WKContentView doesn't relinquish first responder after tapping Safari unified field
https://bugs.webkit.org/show_bug.cgi?id=260060
rdar://113732040
Reviewed by Wenson Hsieh.
The keyboard request dismissal can happen *after* the firstResponder chain
is affected by the dismissal and in fact this does happen on visionOS. By
also checking _isEditable we ensure that even if the firstResponder is the
content view but was not before the dismissal, we don't incorrectly set the
keyboard lock to true (blocking the next attempted resignation), as
_isEditable is not yet true in this case.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _keyboardDidRequestDismissal:]):
Require the content view is firstResponder AND editable to block the next
firstResponder resignation attempt.
Canonical link: https://commits.webkit.org/266863@main
Identifier: 265870.372 at safari-7616-branch
Commit: a1355fc44c919f391360390dd22a7047c6683345
https://github.com/WebKit/WebKit/commit/a1355fc44c919f391360390dd22a7047c6683345
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm
Log Message:
-----------
Cherry-pick b951937980ed. rdar://problem/113608324
Cherry-pick 52ced8d1a83a. rdar://problem/113510677
[macOS] Suppress the SCStream privacy alert
https://bugs.webkit.org/show_bug.cgi?id=259889
rdar://113510677
Reviewed by Andy Estes.
WebKit only allows one tab to capture at a time, so the SCStream privacy alert is confusing
and unnecessary.
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm:
(WebCore::ScreenCaptureKitCaptureSource::streamConfiguration): Set
`configuration.presenterOverlayPrivacyAlertSetting` to `SCPresenterOverlayAlertSettingNever`
Canonical link: https://commits.webkit.org/266661@main
Canonical link: https://commits.webkit.org/265870.320@safari-7616.1.27.11-branch
Identifier: 265870.373 at safari-7616-branch
Commit: 2bdeaf051951a002309b5f8fcd0e291e15dffbc5
https://github.com/WebKit/WebKit/commit/2bdeaf051951a002309b5f8fcd0e291e15dffbc5
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-14 (Mon, 14 Aug 2023)
Changed paths:
M LayoutTests/fast/forms/shadow-tree-exposure-live-range-expected.txt
M LayoutTests/fast/forms/shadow-tree-exposure-live-range.html
M LayoutTests/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt
M LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt
M Source/WebCore/page/DOMSelection.cpp
Log Message:
-----------
Cherry-pick 457eb4252b1f. rdar://problem/113229516
REGRESSION (259904 at main): @math operation cannot trigger in Quip app
https://bugs.webkit.org/show_bug.cgi?id=259944
rdar://113229516
Reviewed by Ryosuke Niwa.
Currently, the `@math` feature in Quip is broken in Safari with Live Range Selection enabled; this
is because Quip's JavaScript editor focuses an input element, and expects `selection.rangeCount` to
return `1` instead of `0` (the latter of which causes Quip to believe that the user is no longer
editing the text field, and therefore leads to Quip dismissing the input field immediately after
presenting it).
This happens because the `rangeCount` and ranges we expose on `DOMSelection` are different with live
range selection in Safari 17, as opposed to both Safari 16 and Chrome (testing against both stable
and canary). Whereas we used to expose a single range that was collapsed to the start of the text
field, we now expose no ranges at all.
To avoid this incompatibility, we restore shipping behavior when the selection is inside of shadow
roots, by exposing a selection range that's equivalent to a caret before the shadow host.
See also: <w3c/selection-api#166>.
Test: fast/forms/shadow-tree-exposure-live-range.html
* LayoutTests/fast/forms/shadow-tree-exposure-live-range-expected.txt:
* LayoutTests/fast/forms/shadow-tree-exposure-live-range.html:
Rebaseline this layout test, such that it verifies that the ranges exposed via the Selection API
have the same behavior without live ranges, vs. with live ranges enabled; this also matches the
behavior in latest Chrome Canary.
* LayoutTests/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt:
* LayoutTests/platform/glib/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt:
* LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/editable-state-and-focus-in-shadow-dom-in-designMode.tentative-expected.txt:
Rebaseline a WPT — attempts to change the selection in a UA shadow root in this test now result in
the wrong base/anchor nodes and offsets after this patch, rather than the `IndexSizeError`s we
currently get.
* Source/WebCore/page/DOMSelection.cpp:
(WebCore::selectionShadowAncestor):
Remove an assertion that's no longer relevant, now that we use this in both live/legacy codepaths.
(WebCore::DOMSelection::type const):
Keep both `fast/forms/shadow-tree-exposure-live-range.html` and
`editing/selection/user-select-js-property.html` passing by adjusting our logic for returning the
selection type. Currently, a selection in a shadow root always results in a type of `None`, but this
diverges from Chrome (and Safari 16's) behavior, which returns the actual type of the selected
range, regardless of whether it's in the shadow tree.
(WebCore::DOMSelection::rangeCount const):
This is the main fix — return a `rangeCount` of 1 in the case where there are no associated live
ranges, if the range is still inside a shadow root.
(WebCore::createLiveRangeBeforeShadowHostWithSelection):
(WebCore::DOMSelection::getRangeAt):
Keep `getRangeAt` consistent with `rangeCount` by returning the caret range at the start of the
shadow host in the case where the selected range is in the shadow tree.
(WebCore::DOMSelection::shadowAdjustedNode const):
(WebCore::DOMSelection::shadowAdjustedOffset const):
These methods need to be adjusted as well, to keep the `(base|anchor|focus|extent)(Node|Offset)`
properties consistent with the `rangeCount` and selection ranges in the case where the selection is
inside of a shadow root. Since the behavior with or without live ranges when the selection is in a
shadow tree is now consistent, we no longer require live-range-specific codepaths, so we can
simplify this code a bit by just removing the `liveRangeSelectionEnabled()` checks.
Canonical link: https://commits.webkit.org/266781@main
Identifier: 265870.374 at safari-7616-branch
Commit: 8fb88f94b7f8aad3e965742a1d23f6cdbc6312f6
https://github.com/WebKit/WebKit/commit/8fb88f94b7f8aad3e965742a1d23f6cdbc6312f6
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
Log Message:
-----------
Cherry-pick dc06957a59d7. rdar://problem/113905497
WebGLRenderingContext classes have unused constructors
https://bugs.webkit.org/show_bug.cgi?id=259724
rdar://113255131
Reviewed by Dan Glastonbury.
Remove the unused constructors.
* Source/WebCore/html/canvas/WebGL2RenderingContext.cpp:
(WebCore::WebGL2RenderingContext::WebGL2RenderingContext):
* Source/WebCore/html/canvas/WebGL2RenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContext.cpp:
(WebCore::WebGLRenderingContext::WebGLRenderingContext):
* Source/WebCore/html/canvas/WebGLRenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.h:
Canonical link: https://commits.webkit.org/266535@main
Canonical link: https://commits.webkit.org/265870.375@safari-7616-branch
Commit: fcb34bee3625adf2302371d0d5f9e8363a33927d
https://github.com/WebKit/WebKit/commit/fcb34bee3625adf2302371d0d5f9e8363a33927d
Author: Russell Epstein <repstein at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
A LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt
A LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html
R LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt
R LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html
M Source/WebCore/html/canvas/OESVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLContextAttributes.idl
M Source/WebCore/html/canvas/WebGLContextGroup.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
M Source/WebCore/html/canvas/WebGLTransformFeedback.cpp
M Source/WebCore/html/canvas/WebGLTransformFeedback.h
M Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObject.h
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h
M Source/WebCore/platform/graphics/GraphicsContextGL.cpp
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
Log Message:
-----------
Cherry-pick 807850b2a461. rdar://problem/111695432
Crash in WebGLRenderingContextBase::reshape when context is lost during initialization
https://bugs.webkit.org/show_bug.cgi?id=258958
rdar://111695432
Reviewed by Dan Glastonbury.
Any synchoronous, result returning RemoteGraphicsContextGLProxy call may
fail, returning empty result. The WebGLRenderingContextBase /
WebGL2RenderingContext initialization did not account for this. This
would lead to scenario where querying for, say, MAX_VIEWPORT_DIMS would
return 0.
If the context loss happened before GraphicsContextGL::setClient() was
done, WebGLRenderingContextBase would not mark the rendering context
state lost.
This would happen, for example, in case where new context would be
created on a GPUP that was hung. The initialization message (WasCreated)
would never arrive, and timeout would mark the context lost. The caller
would not notice this and initialize the context with viewport
dimensions zero. Later, reshape would abort due to width std::clamp
having min dimension 1 and max 0.
Fix by:
- Move the setClient() after initialization, so that general purpose
context loss behavior is not triggered for initialization. The
failure to reinitialize after context loss must not trigger the
general logic, e.g. the context lost event.
- Track the RemoteGraphicsContextGLProxy context loss state in new
function GraphicsContextGL::isContextLost(). This allows detecting
the context loss without having the Client installed.
- Write GL calls in the initialization path with the expectation that
any call can fail. This means avoid using the public API, since
the isContextLost() is inconsistent for the initialization.
- When reinitializing a lost context, reset the context loss state
only if the initialization succeeds.
Other parts of WebGL calls still suffer from the problem of not
expecting any call to fail. These will be addressed in other patches.
* LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt: Added.
* LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html: Added.
* LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt: Removed.
* LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html: Removed.
* Source/WebCore/html/canvas/OESVertexArrayObject.cpp:
(WebCore::OESVertexArrayObject::createVertexArrayOES):
* Source/WebCore/html/canvas/WebGL2RenderingContext.cpp:
(WebCore::WebGL2RenderingContext::create):
(WebCore::WebGL2RenderingContext::initializeContextState):
(WebCore::WebGL2RenderingContext::initializeVertexArrayObjects):
(WebCore::WebGL2RenderingContext::createTransformFeedback):
(WebCore::WebGL2RenderingContext::createVertexArray):
(WebCore::WebGL2RenderingContext::WebGL2RenderingContext): Deleted.
(WebCore::WebGL2RenderingContext::initializeNewContext): Deleted.
* Source/WebCore/html/canvas/WebGL2RenderingContext.h:
* Source/WebCore/html/canvas/WebGLContextAttributes.idl:
* Source/WebCore/html/canvas/WebGLContextGroup.h:
* Source/WebCore/html/canvas/WebGLRenderingContext.cpp:
(WebCore::WebGLRenderingContext::create):
(WebCore::WebGLRenderingContext::initializeVertexArrayObjects):
(WebCore::WebGLRenderingContext::WebGLRenderingContext): Deleted.
* Source/WebCore/html/canvas/WebGLRenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::create):
(WebCore::WebGLRenderingContextBase::WebGLRenderingContextBase):
(WebCore::WebGLRenderingContextBase::initializeNewContext):
(WebCore::WebGLRenderingContextBase::initializeContextState):
(WebCore::WebGLRenderingContextBase::addActivityStateChangeObserverIfNecessary):
(WebCore::WebGLRenderingContextBase::setBoundVertexArrayObject):
(WebCore::WebGLRenderingContextBase::addSharedObject):
(WebCore::WebGLRenderingContextBase::maybeRestoreContext):
(WebCore::WebGLRenderingContextBase::setGraphicsContextGL): Deleted.
* Source/WebCore/html/canvas/WebGLRenderingContextBase.h:
* Source/WebCore/html/canvas/WebGLTransformFeedback.cpp:
(WebCore::WebGLTransformFeedback::create):
(WebCore::WebGLTransformFeedback::WebGLTransformFeedback):
* Source/WebCore/html/canvas/WebGLTransformFeedback.h:
* Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp:
(WebCore::WebGLVertexArrayObject::create):
(WebCore::WebGLVertexArrayObject::WebGLVertexArrayObject):
* Source/WebCore/html/canvas/WebGLVertexArrayObject.h:
* Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp:
(WebCore::WebGLVertexArrayObjectOES::createDefault):
(WebCore::WebGLVertexArrayObjectOES::createUser):
(WebCore::WebGLVertexArrayObjectOES::WebGLVertexArrayObjectOES):
(WebCore::WebGLVertexArrayObjectOES::create): Deleted.
* Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h:
* Source/WebCore/platform/graphics/GraphicsContextGL.cpp:
(WebCore::GraphicsContextGL::forceContextLost):
* Source/WebCore/platform/graphics/GraphicsContextGL.h:
(WebCore::GraphicsContextGL::isContextLost const):
* Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp:
(WebKit::RemoteGraphicsContextGLProxy::create):
(WebKit::RemoteGraphicsContextGLProxy::initializeIPC):
Canonical link: https://commits.webkit.org/266803@main
Canonical link: https://commits.webkit.org/265870.376@safari-7616-branch
Commit: 6efcc9a7f3b7ded26ab1517e49770e6eb7e2c00f
https://github.com/WebKit/WebKit/commit/6efcc9a7f3b7ded26ab1517e49770e6eb7e2c00f
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
R LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt
R LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html
A LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt
A LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html
M Source/WebCore/html/canvas/OESVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLContextAttributes.idl
M Source/WebCore/html/canvas/WebGLContextGroup.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
M Source/WebCore/html/canvas/WebGLTransformFeedback.cpp
M Source/WebCore/html/canvas/WebGLTransformFeedback.h
M Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObject.h
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h
M Source/WebCore/platform/graphics/GraphicsContextGL.cpp
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
Log Message:
-----------
Revert "Cherry-pick 807850b2a461. rdar://problem/111695432"
This reverts commit fcb34bee3625adf2302371d0d5f9e8363a33927d.
Identifier: 265870.377 at safari-7616-branch
Commit: 80f77ba181b2ae6be6cc9dcd313b3f1d57cee3dd
https://github.com/WebKit/WebKit/commit/80f77ba181b2ae6be6cc9dcd313b3f1d57cee3dd
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
Log Message:
-----------
Revert "Cherry-pick dc06957a59d7. rdar://problem/113905497"
This reverts commit 8fb88f94b7f8aad3e965742a1d23f6cdbc6312f6.
Identifier: 265870.378 at safari-7616-branch
Commit: f9c87832a3949cacf5bfd85f89b7b2c375f86c24
https://github.com/WebKit/WebKit/commit/f9c87832a3949cacf5bfd85f89b7b2c375f86c24
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M Source/WebCore/workers/service/server/SWRegistrationDatabase.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm
Log Message:
-----------
Cherry-pick 8e9f2eb04c2e. rdar://problem/113878001
ServiceWorkerRegistration data is not deleted correctly
https://bugs.webkit.org/show_bug.cgi?id=260163
rdar://112092827
Reviewed by Brent Fulgham.
bindText() returns error code and 0 (SQLITE_OK) means the operation succeeds, so updateRegistrations should not return
early.
API Test: WKWebsiteDataStore.RemoveServiceWorkerDataByOrigin
* Source/WebCore/workers/service/server/SWRegistrationDatabase.cpp:
(WebCore::SWRegistrationDatabase::updateRegistrations):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsiteDataStoreCustomPaths.mm:
Canonical link: https://commits.webkit.org/266882@main
Identifier: 265870.379 at safari-7616-branch
Commit: 6b66476a3783ff37eafe4e5cd4fb8121b314f7b7
https://github.com/WebKit/WebKit/commit/6b66476a3783ff37eafe4e5cd4fb8121b314f7b7
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/AXTextMarker.cpp
Log Message:
-----------
Cherry-pick 435522c0b090. rdar://problem/113931267
AX: Crash in [WebAccessibilityObjectWrapper textMarkerRangeAtTextMarker:forUnit:].
https://bugs.webkit.org/show_bug.cgi?id=260187
rdar://110921099
Reviewed by Tyler Wilcock.
The crash was happening because the Node pointed to by the TextMarker is destroyed in a main loop cycle before it is used as the result of a request coming on the AX thread that is dispatched back to the main thread. This patch fixes the problem by checking whether the pointer is still in the AXObjectCache data structure that keeps track of the Nodes still alive and in use by TextMarkers.
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::AXTextMarker::operator CharacterOffset const):
Canonical link: https://commits.webkit.org/266909@main
Identifier: 265870.380 at safari-7616-branch
Commit: b5b70c4574a7023676abcefbe4b5188801fbd8c6
https://github.com/WebKit/WebKit/commit/b5b70c4574a7023676abcefbe4b5188801fbd8c6
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-08-15 (Tue, 15 Aug 2023)
Changed paths:
M JSTests/stress/regexp-vflag-property-of-strings.js
M Source/JavaScriptCore/yarr/YarrPattern.cpp
Log Message:
-----------
CrashOnOverflow in CharacterClassConstructor::compareUTF32Strings
https://bugs.webkit.org/show_bug.cgi?id=260173
rdar://113872060
Reviewed by Ryosuke Niwa.
Fixed and simplified the the sort comparison function compareUTF32Strings() to properly handle
zero length strings.
Added relevant tests.
* JSTests/stress/regexp-vflag-property-of-strings.js:
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::CharacterClassConstructor::compareUTF32Strings):
Canonical link: https://commits.webkit.org/265870.381@safari-7616-branch
Commit: 60dcb7cba20c11627015f53e693448baa0a49bf4
https://github.com/WebKit/WebKit/commit/60dcb7cba20c11627015f53e693448baa0a49bf4
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Cherry-pick de3a2bcea0c5. rdar://problem/113942469
Cherry-pick ccb976224ab6. rdar://problem/113604929
Cherry-pick 265870.295 at safari-7616.1.27.10-branch (ccb976224ab6). rdar://111534888
Cherry-pick 43da1fd1587a. rdar://problem/111534888
WebKit Media: Toggling fullscreen fails to work
https://bugs.webkit.org/show_bug.cgi?id=259760
rdar://111534888
Reviewed by Aditya Keerthi.
The window resize handler is created when receiving the `will{Enter|Exit}FullScreen` notification,
and is then invalidated as a result of `setFrameSize` being called. However, when transiting to/from
element full screen, `setFrameSize` is called before the notification is posted, instead of after.
This causes the handler to never be invalidated.
Fix by creating the handler directly inside `setFrameSize`, and not rely on the full screen
notifications at all. This is ok since `_holdResizeSnapshotWithReason` only returns a non-nil block
when entering or exiting full screen, so it has no effect in other cases.
No new tests, since all tests in `FullscreenVideoTextRecognition` already test this behavior in some
configurations.
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _holdWindowResizeSnapshotWithReason:]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Canonical link: https://commits.webkit.org/266558@main
Identifier: 265870.295 at safari-7616.1.27.10-branch
Identifier: 265870.330 at safari-7616.2.1-branch
Identifier: 265870.382 at safari-7616-branch
Commit: bd8791f0ba86c9cb9131d826c0218be01c413e2f
https://github.com/WebKit/WebKit/commit/bd8791f0ba86c9cb9131d826c0218be01c413e2f
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKView.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Cherry-pick a4d6b88fd624. rdar://problem/113942469
Apply patch. rdar://problem/113604929
Identifier: 265870.333 at safari-7616.2.1-branch
Identifier: 265870.383 at safari-7616-branch
Commit: c40ed98815f0c93b5b9df36554042965493b8934
https://github.com/WebKit/WebKit/commit/c40ed98815f0c93b5b9df36554042965493b8934
Author: Kimmo Kinnunen <kkinnunen at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
Log Message:
-----------
Cherry-pick 8fb88f94b7f8. rdar://problem/113905497
Cherry-pick dc06957a59d7. rdar://problem/113905497
WebGLRenderingContext classes have unused constructors
https://bugs.webkit.org/show_bug.cgi?id=259724
rdar://113255131
Reviewed by Dan Glastonbury.
Remove the unused constructors.
* Source/WebCore/html/canvas/WebGL2RenderingContext.cpp:
(WebCore::WebGL2RenderingContext::WebGL2RenderingContext):
* Source/WebCore/html/canvas/WebGL2RenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContext.cpp:
(WebCore::WebGLRenderingContext::WebGLRenderingContext):
* Source/WebCore/html/canvas/WebGLRenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.h:
Canonical link: https://commits.webkit.org/266535@main
Canonical link: https://commits.webkit.org/265870.375@safari-7616-branch
Identifier: 265870.384 at safari-7616-branch
Commit: 6a8b77849012604307e1ff81d8158c16d3dfb1fa
https://github.com/WebKit/WebKit/commit/6a8b77849012604307e1ff81d8158c16d3dfb1fa
Author: Russell Epstein <repstein at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
A LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt
A LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html
R LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt
R LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html
M Source/WebCore/html/canvas/OESVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLContextAttributes.idl
M Source/WebCore/html/canvas/WebGLContextGroup.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
M Source/WebCore/html/canvas/WebGLTransformFeedback.cpp
M Source/WebCore/html/canvas/WebGLTransformFeedback.h
M Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObject.h
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h
M Source/WebCore/platform/graphics/GraphicsContextGL.cpp
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
Log Message:
-----------
Cherry-pick fcb34bee3625. rdar://problem/111695432
Cherry-pick 807850b2a461. rdar://problem/111695432
Crash in WebGLRenderingContextBase::reshape when context is lost during initialization
https://bugs.webkit.org/show_bug.cgi?id=258958
rdar://111695432
Reviewed by Dan Glastonbury.
Any synchoronous, result returning RemoteGraphicsContextGLProxy call may
fail, returning empty result. The WebGLRenderingContextBase /
WebGL2RenderingContext initialization did not account for this. This
would lead to scenario where querying for, say, MAX_VIEWPORT_DIMS would
return 0.
If the context loss happened before GraphicsContextGL::setClient() was
done, WebGLRenderingContextBase would not mark the rendering context
state lost.
This would happen, for example, in case where new context would be
created on a GPUP that was hung. The initialization message (WasCreated)
would never arrive, and timeout would mark the context lost. The caller
would not notice this and initialize the context with viewport
dimensions zero. Later, reshape would abort due to width std::clamp
having min dimension 1 and max 0.
Fix by:
- Move the setClient() after initialization, so that general purpose
context loss behavior is not triggered for initialization. The
failure to reinitialize after context loss must not trigger the
general logic, e.g. the context lost event.
- Track the RemoteGraphicsContextGLProxy context loss state in new
function GraphicsContextGL::isContextLost(). This allows detecting
the context loss without having the Client installed.
- Write GL calls in the initialization path with the expectation that
any call can fail. This means avoid using the public API, since
the isContextLost() is inconsistent for the initialization.
- When reinitializing a lost context, reset the context loss state
only if the initialization succeeds.
Other parts of WebGL calls still suffer from the problem of not
expecting any call to fail. These will be addressed in other patches.
* LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt: Added.
* LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html: Added.
* LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt: Removed.
* LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html: Removed.
* Source/WebCore/html/canvas/OESVertexArrayObject.cpp:
(WebCore::OESVertexArrayObject::createVertexArrayOES):
* Source/WebCore/html/canvas/WebGL2RenderingContext.cpp:
(WebCore::WebGL2RenderingContext::create):
(WebCore::WebGL2RenderingContext::initializeContextState):
(WebCore::WebGL2RenderingContext::initializeVertexArrayObjects):
(WebCore::WebGL2RenderingContext::createTransformFeedback):
(WebCore::WebGL2RenderingContext::createVertexArray):
(WebCore::WebGL2RenderingContext::WebGL2RenderingContext): Deleted.
(WebCore::WebGL2RenderingContext::initializeNewContext): Deleted.
* Source/WebCore/html/canvas/WebGL2RenderingContext.h:
* Source/WebCore/html/canvas/WebGLContextAttributes.idl:
* Source/WebCore/html/canvas/WebGLContextGroup.h:
* Source/WebCore/html/canvas/WebGLRenderingContext.cpp:
(WebCore::WebGLRenderingContext::create):
(WebCore::WebGLRenderingContext::initializeVertexArrayObjects):
(WebCore::WebGLRenderingContext::WebGLRenderingContext): Deleted.
* Source/WebCore/html/canvas/WebGLRenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::create):
(WebCore::WebGLRenderingContextBase::WebGLRenderingContextBase):
(WebCore::WebGLRenderingContextBase::initializeNewContext):
(WebCore::WebGLRenderingContextBase::initializeContextState):
(WebCore::WebGLRenderingContextBase::addActivityStateChangeObserverIfNecessary):
(WebCore::WebGLRenderingContextBase::setBoundVertexArrayObject):
(WebCore::WebGLRenderingContextBase::addSharedObject):
(WebCore::WebGLRenderingContextBase::maybeRestoreContext):
(WebCore::WebGLRenderingContextBase::setGraphicsContextGL): Deleted.
* Source/WebCore/html/canvas/WebGLRenderingContextBase.h:
* Source/WebCore/html/canvas/WebGLTransformFeedback.cpp:
(WebCore::WebGLTransformFeedback::create):
(WebCore::WebGLTransformFeedback::WebGLTransformFeedback):
* Source/WebCore/html/canvas/WebGLTransformFeedback.h:
* Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp:
(WebCore::WebGLVertexArrayObject::create):
(WebCore::WebGLVertexArrayObject::WebGLVertexArrayObject):
* Source/WebCore/html/canvas/WebGLVertexArrayObject.h:
* Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp:
(WebCore::WebGLVertexArrayObjectOES::createDefault):
(WebCore::WebGLVertexArrayObjectOES::createUser):
(WebCore::WebGLVertexArrayObjectOES::WebGLVertexArrayObjectOES):
(WebCore::WebGLVertexArrayObjectOES::create): Deleted.
* Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h:
* Source/WebCore/platform/graphics/GraphicsContextGL.cpp:
(WebCore::GraphicsContextGL::forceContextLost):
* Source/WebCore/platform/graphics/GraphicsContextGL.h:
(WebCore::GraphicsContextGL::isContextLost const):
* Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp:
(WebKit::RemoteGraphicsContextGLProxy::create):
(WebKit::RemoteGraphicsContextGLProxy::initializeIPC):
Canonical link: https://commits.webkit.org/266803@main
Canonical link: https://commits.webkit.org/265870.376@safari-7616-branch
Identifier: 265870.385 at safari-7616-branch
Commit: c8383f67b20937a71b64bc22d53c8d77dae65ae1
https://github.com/WebKit/WebKit/commit/c8383f67b20937a71b64bc22d53c8d77dae65ae1
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
R LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt
R LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html
A LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt
A LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html
M Source/WebCore/html/canvas/OESVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLContextAttributes.idl
M Source/WebCore/html/canvas/WebGLContextGroup.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
M Source/WebCore/html/canvas/WebGLTransformFeedback.cpp
M Source/WebCore/html/canvas/WebGLTransformFeedback.h
M Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObject.h
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h
M Source/WebCore/platform/graphics/GraphicsContextGL.cpp
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
Log Message:
-----------
Revert "Cherry-pick fcb34bee3625. rdar://problem/111695432"
This reverts commit 6a8b77849012604307e1ff81d8158c16d3dfb1fa.
Identifier: 265870.386 at safari-7616-branch
Commit: 89d5c3254e77586b0e66392da49e1c6664791db6
https://github.com/WebKit/WebKit/commit/89d5c3254e77586b0e66392da49e1c6664791db6
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
Log Message:
-----------
Revert "Cherry-pick 8fb88f94b7f8. rdar://problem/113905497"
This reverts commit c40ed98815f0c93b5b9df36554042965493b8934.
Identifier: 265870.387 at safari-7616-branch
Commit: 6fd415506d71a05741af85a09371eb31a6c81ced
https://github.com/WebKit/WebKit/commit/6fd415506d71a05741af85a09371eb31a6c81ced
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.3
Identifier: 265870.388 at safari-7616-branch
Commit: 6fff714a645f22766ba415770d3fe1fa6eba38c2
https://github.com/WebKit/WebKit/commit/6fff714a645f22766ba415770d3fe1fa6eba38c2
Author: Tim Horton <thorton at apple.com>
Date: 2023-08-16 (Wed, 16 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.mm
Log Message:
-----------
Cherry-pick 81f1c237dc81. rdar://problem/113758512
Crashes under currentUserInterfaceIdiomIsVisionOrVisionLegacy() on iPad
https://bugs.webkit.org/show_bug.cgi?id=260077
rdar://113758512
Reviewed by Wenson Hsieh.
* Source/WebCore/PAL/pal/system/ios/UserInterfaceIdiom.mm:
(PAL::updateCurrentUserInterfaceIdiom):
Ensure that we write `Default` to the optional so it is always engaged once updated.
Canonical link: https://commits.webkit.org/266825@main
Identifier: 265870.389 at safari-7616-branch
Commit: 7b08e5e5eb0b02f78a12aa2732f574104f20d8e8
https://github.com/WebKit/WebKit/commit/7b08e5e5eb0b02f78a12aa2732f574104f20d8e8
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
A LayoutTests/http/tests/paymentrequest/paymentrequest-supportedCountries.https-expected.txt
A LayoutTests/http/tests/paymentrequest/paymentrequest-supportedCountries.https.html
M LayoutTests/http/tests/resources/payment-request.js
M Source/WebCore/Modules/applepay/ApplePayRequestBase.cpp
M Source/WebCore/Modules/applepay/ApplePayRequestBase.h
M Source/WebCore/testing/MockPaymentCoordinator.cpp
M Source/WebCore/testing/MockPaymentCoordinator.h
M Source/WebCore/testing/MockPaymentCoordinator.idl
Log Message:
-----------
Cherry-pick e5afaf96365a. rdar://problem/113557607
supportedCountries only works on ApplePaySession, not PaymentRequest (affects Shopify)
https://bugs.webkit.org/show_bug.cgi?id=259940
rdar://113557607
Reviewed by Alex Christensen.
The `supportedCountries` property only seems to be reflected in a payment
request when it is set in an ApplePayJS request, and not the W3C Payment
Request API. This is because we end up calling
`WebCore::convertAndValidate()` multiple times for `ApplePayRequestBase`
in the Payment Request flow, which means we end up `WTFMove`-ing the
`supportedCountries` vector on the first call and said vector is empty
on subsequent entries into the function, so we ultimately set it to an
empty vector.
The multiple calls to `WebCore::convertAndValidate()` is an architectural
issue that we should address (https://bugs.webkit.org/show_bug.cgi?id=260050),
but in the meantime we opt to fix the issue by copying the
`supportedCountries` vector before moving it at the
`setSupportedCountries()` callsite in `WebCore::convertAndValidate()`.
We also modify `WebCore::convertAndValidate()`'s signature to expect a
const L-value reference to `ApplePayRequestBase` instead, which should
mitigate against accidental data corruption.
This patch also introduces a layout test (and some associated Internals
plumbing) that improves our test coverage for the `supportedCountries`
attribute in payment requests.
* LayoutTests/http/tests/paymentrequest/paymentrequest-supportedCountries.https-expected.txt: Added.
* LayoutTests/http/tests/paymentrequest/paymentrequest-supportedCountries.https.html: Added.
* LayoutTests/http/tests/resources/payment-request.js:
(async validPaymentMethod):
* Source/WebCore/Modules/applepay/ApplePayRequestBase.cpp:
(WebCore::convertAndValidate):
* Source/WebCore/Modules/applepay/ApplePayRequestBase.h:
* Source/WebCore/testing/MockPaymentCoordinator.cpp:
(WebCore::MockPaymentCoordinator::showPaymentUI):
* Source/WebCore/testing/MockPaymentCoordinator.h:
* Source/WebCore/testing/MockPaymentCoordinator.idl:
Canonical link: https://commits.webkit.org/266829@main
Identifier: 265870.390 at safari-7616-branch
Commit: eea9edb8c12a8389a6de69a0afbeee0b17c12567
https://github.com/WebKit/WebKit/commit/eea9edb8c12a8389a6de69a0afbeee0b17c12567
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/fast/canvas/do-not-expose-non-default-focus-ring-color-expected.html
A LayoutTests/fast/canvas/do-not-expose-non-default-focus-ring-color.html
A LayoutTests/fast/canvas/resources/do-not-expose-non-default-focus-ring-color.js
A LayoutTests/fast/css/mac/focus-ring-color-should-not-expose-accent-color-expected-mismatch.html
A LayoutTests/fast/css/mac/focus-ring-color-should-not-expose-accent-color.html
M LayoutTests/platform/mac-wk2/TestExpectations
M LayoutTests/resources/ui-helper.js
M Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/RenderImage.cpp
M Source/WebCore/rendering/RenderThemeIOS.mm
M Source/WebCore/rendering/RenderThemeMac.mm
M Source/WebCore/testing/Internals.cpp
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl
M Tools/WebKitTestRunner/InjectedBundle/TestRunner.h
M Tools/WebKitTestRunner/TestController.h
M Tools/WebKitTestRunner/mac/TestControllerMac.mm
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.h
M Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm
Log Message:
-----------
Cherry-pick 04c640bb1dce. rdar://problem/105554669
[macOS] drawFocusIfNeeded() should not expose the user's system accent color
https://bugs.webkit.org/show_bug.cgi?id=260102
rdar://105554669
Reviewed by Tim Nguyen.
On macOS, `drawFocusIfNeeded()` currently exposes the user's system accent color via
`RenderTheme::focusRingColor()`. To mitigate fingerprinting risk due to this API for users that have
chosen a non-default system accent color, we make `RenderTheme::focusRingColor()` respect the given
`UseSystemAppearance` state by returning the default system focus ring color on macOS, in the case
where that option is absent. As a result, this means that quirks-mode webpages that use
`-webkit-focus-ring-color` will also no longer be able to determine the user's accent color. This
aligns with existing behavior for the "activeborder" CSS value.
Tests: fast/canvas/do-not-expose-non-default-focus-ring-color.html
fast/css/mac/focus-ring-color-should-not-expose-accent-color.html
* LayoutTests/TestExpectations:
* LayoutTests/fast/canvas/do-not-expose-non-default-focus-ring-color-expected.html: Added.
* LayoutTests/fast/canvas/do-not-expose-non-default-focus-ring-color.html: Added.
* LayoutTests/fast/canvas/resources/do-not-expose-non-default-focus-ring-color.js: Added.
(paintIntoSwatch):
Add a test to verify that accent colors can't be read back using canvas 2D; to test this, we render
a simple focus ring to a 2D canvas, use `getImageData` to read it back, and verify that the average
non-transparent pixel values in the resulting image data match even when the accent color is
different (customized using the new `UIScriptController` hook below).
* LayoutTests/fast/css/mac/focus-ring-color-should-not-expose-accent-color-expected-mismatch.html: Added.
* LayoutTests/fast/css/mac/focus-ring-color-should-not-expose-accent-color.html: Added.
Add another test to verify that accent colors (1) are not directly leaked through the use of the
`-webkit-focus-ring-color` CSS property, and (2) enabling system appearance is sufficient to expose
the real focus ring color again.
* LayoutTests/platform/mac-wk2/TestExpectations:
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.isMac):
(window.UIHelper.setAppAccentColor):
* Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h:
Drive-by fix: remove an unnecessary UIKit SPI method declaraction.
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::paintFocusRing const):
Set `UseSystemAppearance` here to ensure that focus rings still paint with the correct appearance.
* Source/WebCore/rendering/RenderImage.cpp:
(WebCore::RenderImage::paintAreaElementFocusRing):
Set `UseSystemAppearance` here to ensure that focus rings still paint with the correct appearance.
* Source/WebCore/rendering/RenderThemeIOS.mm:
(WebCore::RenderThemeIOS::systemFocusRingColor):
* Source/WebCore/rendering/RenderThemeMac.mm:
(WebCore::defaultFocusRingColor):
(WebCore::RenderThemeMac::platformFocusRingColor const):
This is the main fix — pull the hard-coded value for the focus ring color out into a separate helper
function, which we use in `platformFocusRingColor` if `UseSystemAppearance` is unset.
(WebCore::RenderThemeMac::systemColor const):
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::focusRingColor):
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::setAppAccentColor):
Add a `UIScriptController` hook to set a custom accent color, using `-_setAccentColor:`. This is
reset to the default value (computed upon initializing the test runner and stored in
`m_defaultAppAccentColor`) between test runs.
* Tools/WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
* Tools/WebKitTestRunner/InjectedBundle/TestRunner.h:
(WTR::TestRunner::isMac const):
* Tools/WebKitTestRunner/TestController.h:
* Tools/WebKitTestRunner/mac/TestControllerMac.mm:
(WTR::TestController::platformInitialize):
(WTR::TestController::platformResetStateToConsistentValues):
* Tools/WebKitTestRunner/mac/UIScriptControllerMac.h:
* Tools/WebKitTestRunner/mac/UIScriptControllerMac.mm:
(WTR::UIScriptControllerMac::setAppAccentColor):
Canonical link: https://commits.webkit.org/266881@main
Identifier: 265870.391 at safari-7616-branch
Commit: d0be14cac44747d380b524daa58560e8dc415a5f
https://github.com/WebKit/WebKit/commit/d0be14cac44747d380b524daa58560e8dc415a5f
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick c6859d32429f. rdar://problem/104938789
bankofamerica.com - Loading icon still present when navigating back after failing log in
https://bugs.webkit.org/show_bug.cgi?id=260082
rdar://104938789
Reviewed by Brent Fulgham.
On bankofamerica.com, if you attempt to log in with invalid credential and then
navigate back, the "log in" will still be shown as "Loading ...".
The reason this happens is that the page changes the "Log in" button text to
"Loading ..." right before the navigation but fails to reset it on "pagehide"
or "pageshow" event. Safari successfully caches the page in the back/forward
cache and thus the page still shows "Loading ..." after the back navigation.
The issue doesn't reproduce in Chrome because they do not cache pages as
aggressively as we do. In particular, they do not cache pages that have an
"unload" event handler, like this page. Safari has been caching such pages
for years.
Since this is a content issue that could easily be addressed by the site
developers, I am addressing this with a quirk. If we detect this particular
"sign in" button with the "loading" class on bankofamerica.com, and if the
page has an "unload" event handler, we now prevent the page from going into
the cache.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldBypassBackForwardCache const):
Canonical link: https://commits.webkit.org/266898@main
Identifier: 265870.392 at safari-7616-branch
Commit: 5cd65f45eb897dcfeebe61e5d4d1a2a139004114
https://github.com/WebKit/WebKit/commit/5cd65f45eb897dcfeebe61e5d4d1a2a139004114
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
M Source/WebCore/Configurations/WebCore.xcconfig
Log Message:
-----------
Fix build breakage in 265870.366 at safari-7616-branch (9d533c581937)
rdar://problem/113417307
Unreviewed build fix.
* Source/WebCore/Configurations/WebCore.xcconfig: Fix incorrect conflict resolution in 265870.366 at safari-7616-branch.
Canonical link: https://commits.webkit.org/265870.393@safari-7616-branch
Commit: 5af3321142b696880c35ad69e9854bcd8da7ac3e
https://github.com/WebKit/WebKit/commit/5af3321142b696880c35ad69e9854bcd8da7ac3e
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-18 (Fri, 18 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
Log Message:
-----------
Apply patch. rdar://problem/111695432
Identifier: 265870.394 at safari-7616-branch
Commit: f7f24086bcfb64016659862328118d26ba6d9a11
https://github.com/WebKit/WebKit/commit/f7f24086bcfb64016659862328118d26ba6d9a11
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-18 (Fri, 18 Aug 2023)
Changed paths:
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.h
Log Message:
-----------
Apply patch. rdar://problem/111695432
Identifier: 265870.395 at safari-7616-branch
Commit: 05e549349042fdb6dd9d9e2cbabcbc47521bc884
https://github.com/WebKit/WebKit/commit/05e549349042fdb6dd9d9e2cbabcbc47521bc884
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-18 (Fri, 18 Aug 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
A LayoutTests/webgl/webgl-fail-after-context-creation-no-crash-expected.txt
A LayoutTests/webgl/webgl-fail-after-context-creation-no-crash.html
R LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash-expected.txt
R LayoutTests/webgl/webgl-fail-remote-context-ipc-buffer-allocation-no-crash.html
M Source/WebCore/html/canvas/OESVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLContextAttributes.idl
M Source/WebCore/html/canvas/WebGLContextGroup.h
M Source/WebCore/html/canvas/WebGLRenderingContext.cpp
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
M Source/WebCore/html/canvas/WebGLTransformFeedback.cpp
M Source/WebCore/html/canvas/WebGLTransformFeedback.h
M Source/WebCore/html/canvas/WebGLVertexArrayObject.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObject.h
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.cpp
M Source/WebCore/html/canvas/WebGLVertexArrayObjectOES.h
M Source/WebCore/platform/graphics/GraphicsContextGL.cpp
M Source/WebCore/platform/graphics/GraphicsContextGL.h
M Source/WebCore/platform/graphics/GraphicsContextGLAttributes.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
Log Message:
-----------
Apply patch. rdar://problem/111695432
Identifier: 265870.396 at safari-7616-branch
Commit: 084b42ad6447435736d6fa50e007e8f5921d4016
https://github.com/WebKit/WebKit/commit/084b42ad6447435736d6fa50e007e8f5921d4016
Author: Tim Nguyen <ntim at apple.com>
Date: 2023-08-18 (Fri, 18 Aug 2023)
Changed paths:
A LayoutTests/fast/scrolling/ios/overflow-scroll-after-inert-change-expected.txt
A LayoutTests/fast/scrolling/ios/overflow-scroll-after-inert-change.html
M Source/WebCore/rendering/style/RenderStyle.cpp
Log Message:
-----------
Cherry-pick cd37141f0b59. rdar://problem/113239461
[inert][iOS] Can't scroll element after inert attribute has been removed
https://bugs.webkit.org/show_bug.cgi?id=259684
rdar://113239461
Reviewed by Wenson Hsieh.
inert use the same invalidation as pointer-events / user-select as effectivePointerEvents / effectiveUserSelect both read effectiveInert.
* LayoutTests/fast/scrolling/ios/overflow-scroll-after-inert-change-expected.txt: Added.
* LayoutTests/fast/scrolling/ios/overflow-scroll-after-inert-change.html: Added.
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::rareInheritedDataChangeRequiresRepaint):
(WebCore::RenderStyle::changeRequiresRecompositeLayer const):
Canonical link: https://commits.webkit.org/267030@main
Identifier: 265870.397 at safari-7616-branch
Commit: 32e64de9858a56249a384fdc94055917a23134b7
https://github.com/WebKit/WebKit/commit/32e64de9858a56249a384fdc94055917a23134b7
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py
Log Message:
-----------
Cherry-pick 266187 at main (273f723b9c16). rdar://98099682
[git-webkit] Allow re-running command with --issue
https://bugs.webkit.org/show_bug.cgi?id=243284
rdar://98099682
Reviewed by Elliott Williams.
If the current branch is a potential representation of the issue passed
by --issue, configure the bug URLs and commit title to match the specified
issue.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py:
(PullRequest.pull_request_branch_point): Allow --issue on a PR branch if the PR
branch matches the provided issue.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py:
Canonical link: https://commits.webkit.org/266187@main
Canonical link: https://commits.webkit.org/265870.398@safari-7616-branch
Commit: cfdf42efe829fd9bee5e82a3d22bcf8cd1b36a26
https://github.com/WebKit/WebKit/commit/cfdf42efe829fd9bee5e82a3d22bcf8cd1b36a26
Author: Aakash Jain <aakash_jain at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/local/git.py
Log Message:
-----------
Cherry-pick 266291 at main (9ed56214691e). https://bugs.webkit.org/show_bug.cgi?id=259477
Improve error message when webkitbot fails to find identifier
https://bugs.webkit.org/show_bug.cgi?id=259477
Reviewed by Ryan Haddad.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/local/git.py:
Canonical link: https://commits.webkit.org/266291@main
Canonical link: https://commits.webkit.org/265870.399@safari-7616-branch
Commit: de8de702615488d5ba239287a9ef4fd33e95f37d
https://github.com/WebKit/WebKit/commit/de8de702615488d5ba239287a9ef4fd33e95f37d
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py
Log Message:
-----------
Cherry-pick 266526 at main (7072a0ccaa41). rdar://112268906
[git-webkit] no-issue should disable radar CC
https://bugs.webkit.org/show_bug.cgi?id=259214
rdar://112268906
Reviewed by Dewei Zhu and Ryan Haddad.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py:
(PullRequest.create_pull_request): Disable radar CC when not updating an issue.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py:
Canonical link: https://commits.webkit.org/266526@main
Canonical link: https://commits.webkit.org/265870.400@safari-7616-branch
Commit: 7c9353a836570352463773846306e165340ac959
https://github.com/WebKit/WebKit/commit/7c9353a836570352463773846306e165340ac959
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
M Tools/Scripts/hooks/prepare-commit-msg
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/cherry_pick.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/cherry_pick_unittest.py
Log Message:
-----------
Cherry-pick 266527 at main (81d929e4e8c0). rdar://112621977
[prepare-commit-msg] Automatically de-duplicate cherry-pick messages
https://bugs.webkit.org/show_bug.cgi?id=259370
rdar://112621977
Reviewed by Dewei Zhu.
Un-indent cherry-picks of cherry-picks.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/hooks/prepare-commit-msg: Un-indent cherry-picks of cherry-picks.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/cherry_pick.py:
(CherryPick.parser): Set 'original' to 'None'.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/cherry_pick_unittest.py:
(TestCherryPick.test_resolve_default): Test the default arguments to cherry-pick.
(TestCherryPick.test_resolve): Pass '--use-original'.
Canonical link: https://commits.webkit.org/266527@main
Canonical link: https://commits.webkit.org/265870.401@safari-7616-branch
Commit: 6e2c138711fbc9774e343a2cd5715aba95ce18b8
https://github.com/WebKit/WebKit/commit/6e2c138711fbc9774e343a2cd5715aba95ce18b8
Author: Elliott Williams <emw at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
M Configurations/CommonBase.xcconfig
A Configurations/SDKAdditions.xcconfig
M Configurations/WebKitProjectPaths.xcconfig
M PerformanceTests/DecoderTest/Configurations/Base.xcconfig
M PerformanceTests/MediaTime/Configurations/Base.xcconfig
M Source/JavaScriptCore/Configurations/Base.xcconfig
M Source/ThirdParty/ANGLE/Configurations/Base.xcconfig
M Source/ThirdParty/libwebrtc/Configurations/Base.xcconfig
M Source/WTF/Configurations/Base.xcconfig
M Source/WebCore/Configurations/Base.xcconfig
M Source/WebCore/PAL/Configurations/Base.xcconfig
M Source/WebCore/PAL/ThirdParty/libavif/Configurations/Base.xcconfig
M Source/WebCore/PAL/ThirdParty/libavif/ThirdParty/dav1d/Configurations/Base.xcconfig
M Source/WebGPU/Configurations/Base.xcconfig
M Source/WebInspectorUI/Configurations/Base.xcconfig
M Source/WebKit/Configurations/Base.xcconfig
M Source/WebKit/SwiftOverlay/Configurations/Base.xcconfig
M Source/WebKitLegacy/mac/Configurations/Base.xcconfig
M Source/bmalloc/Configurations/Base.xcconfig
M Tools/DumpRenderTree/mac/Configurations/Base.xcconfig
M Tools/ImageDiff/cg/Configurations/Base.xcconfig
M Tools/MiniBrowser/Configurations/Base.xcconfig
M Tools/MiniBrowserSwiftUI/Configurations/Base.xcconfig
M Tools/MobileMiniBrowser/Configurations/Base.xcconfig
M Tools/TestWebKitAPI/Configurations/Base.xcconfig
M Tools/WebEditingTester/Configurations/Base.xcconfig
M Tools/WebGPUPlayground/Configurations/Base.xcconfig
M Tools/WebKitTestRunner/Configurations/Base.xcconfig
M Tools/lldb/lldbWebKitTester/Configurations/Base.xcconfig
A WebKitLibraries/SDKs/macosx14.0-additions.sdk/SDKSettings.plist
A WebKitLibraries/SDKs/macosx14.0-additions.sdk/usr/local/include/AvailabilityProhibitedInternal.h
Log Message:
-----------
Cherry-pick 265967 at main (6dba0b8967fc). rdar://111922548
[macOS Sonoma] Add a sparse SDK for public SDK overrides
https://bugs.webkit.org/show_bug.cgi?id=258749
rdar://problem/111922548
Reviewed by Alexey Proskuryakov.
WebKit uses SPI-only classes in the SDK which are marked
API_UNAVAILABLE. Instead of handling this in
configure-xcode-for-embedded-development, add a sparse SDK which
contains an AvailabilityProhibitedInternal.h header that disables
unavailability annotations.
This establishes precedent for making more SDK-level customizations via
sparse SDKs.
* Configurations/CommonBase.xcconfig:
* Configurations/SDKAdditions.xcconfig: Added, contains conditional
logic to determine when a sparse SDK should be used. Defines
WK_ADDITIONAL_SDKS, which is used in projects to set ADDITIONAL_SDKS.
* Configurations/WebKitProjectPaths.xcconfig: Refactor the logic used to
figure out the path to WebKitLibraries/. Previously, it assumed any
project was two directories deep in the repo hierarchy (i.e.
Source/WebCore/WebCore.xcodeproj). Now, it figures out the workspace
root path dynamically based on SRCROOT.
In projects, set ADDITIONAL_SDKS = $(WK_ADDITIONAL_SDKS):
* PerformanceTests/DecoderTest/Configurations/Base.xcconfig:
* PerformanceTests/MediaTime/Configurations/Base.xcconfig:
* Source/JavaScriptCore/Configurations/Base.xcconfig:
* Source/ThirdParty/ANGLE/Configurations/Base.xcconfig:
* Source/ThirdParty/libwebrtc/Configurations/Base.xcconfig:
* Source/WTF/Configurations/Base.xcconfig:
* Source/WebCore/Configurations/Base.xcconfig:
* Source/WebCore/PAL/Configurations/Base.xcconfig:
* Source/WebCore/PAL/ThirdParty/libavif/Configurations/Base.xcconfig:
* Source/WebCore/PAL/ThirdParty/libavif/ThirdParty/dav1d/Configurations/Base.xcconfig:
* Source/WebGPU/Configurations/Base.xcconfig:
* Source/WebInspectorUI/Configurations/Base.xcconfig:
* Source/WebKit/Configurations/Base.xcconfig:
* Source/WebKit/SwiftOverlay/Configurations/Base.xcconfig:
* Source/WebKitLegacy/mac/Configurations/Base.xcconfig:
* Source/bmalloc/Configurations/Base.xcconfig:
* Tools/DumpRenderTree/mac/Configurations/Base.xcconfig:
* Tools/ImageDiff/cg/Configurations/Base.xcconfig:
* Tools/MiniBrowser/Configurations/Base.xcconfig:
* Tools/MiniBrowserSwiftUI/Configurations/Base.xcconfig:
* Tools/MobileMiniBrowser/Configurations/Base.xcconfig:
* Tools/TestWebKitAPI/Configurations/Base.xcconfig:
* Tools/WebEditingTester/Configurations/Base.xcconfig:
* Tools/WebGPUPlayground/Configurations/Base.xcconfig:
* Tools/WebKitTestRunner/Configurations/Base.xcconfig:
* Tools/lldb/lldbWebKitTester/Configurations/Base.xcconfig:
The sparse SDK contains an AvailabilityProhibitedInternal header,
exactly the same as the one installed by
configure-xcode-for-embedded-development.
* WebKitLibraries/SDKs/macosx14.0-additions.sdk/SDKSettings.plist: Added.
* WebKitLibraries/SDKs/macosx14.0-additions.sdk/usr/local/include/AvailabilityProhibitedInternal.h: Added.
Canonical link: https://commits.webkit.org/265967@main
Canonical link: https://commits.webkit.org/265870.402@safari-7616-branch
Commit: 43c01fefcaa51eaf1344782f232b5b767083df29
https://github.com/WebKit/WebKit/commit/43c01fefcaa51eaf1344782f232b5b767083df29
Author: J Pascoe <j_pascoe at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm
Log Message:
-----------
Check CSP and X-Frame-Options for subframe AppSSO
https://bugs.webkit.org/show_bug.cgi?id=260100
rdar://108625087
Reviewed by Alex Christensen.
Before this patch, AppSSO unconditionally sets cookies whenever
a session occurs without considering the headers in the response.
This patch starts considering CSP and X-Frame-Options for AppSSO responses.
Added API tests for this behavior.
* Source/WebKit/UIProcess/API/APIFrameInfo.h:
* Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h:
* Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
(WebKit::SOAuthorizationSession::complete):
(WebKit::SOAuthorizationSession::shouldInterruptLoadForXFrameOptions):
(WebKit::SOAuthorizationSession::shouldInterruptLoadForCSPFrameAncestorsOrXFrameOptions):
(): Deleted.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/265870.403@safari-7616-branch
Commit: aa32244a89e79971d2c3ddf7b9f21c519b8cb0fe
https://github.com/WebKit/WebKit/commit/aa32244a89e79971d2c3ddf7b9f21c519b8cb0fe
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-21 (Mon, 21 Aug 2023)
Changed paths:
A JSTests/stress/date-set-time-purify-nan.js
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
[JSC] Purify NaN for Date#setTime DFG / FTL implementations
https://bugs.webkit.org/show_bug.cgi?id=260497
rdar://114177456
Reviewed by Mark Lam.
Date#setTime should purify NaN, otherwise, it can put arbitrary NaN boxed values, and cause type-confusion.
We can just use canonical NaN when the input is NaN.
* JSTests/stress/date-set-time-purify-nan.js: Added.
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileDateSet):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
Canonical link: https://commits.webkit.org/265870.404@safari-7616-branch
Commit: 76d4ffe914b192cf90f8420e05d71d420ab8ddd1
https://github.com/WebKit/WebKit/commit/76d4ffe914b192cf90f8420e05d71d420ab8ddd1
Author: Devin Rousso <hi at devinrousso.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/ConsoleMessageView.js
Log Message:
-----------
Cherry-pick ae256c9a88db. rdar://112170843
Stop using Number.prototype.toLocaleString() for numeric console format specifiers
https://bugs.webkit.org/show_bug.cgi?id=259146
Reviewed by Patrick Angle.
`console.log("%i", 1000)` should have the same output as `console.log("1000")`.
* Source/WebInspectorUI/UserInterface/Views/ConsoleMessageView.js:
(WI.ConsoleMessageView.prototype._formatWithSubstitutionString.floatFormatter):
(WI.ConsoleMessageView.prototype._formatWithSubstitutionString.integerFormatter):
Remove calling `Number.prototype.toLocaleString` as that can insert unwanted text (e.g. commas).
Canonical link: https://commits.webkit.org/266020@main
(cherry picked from commit a8e9bea7874b61df1580f18dbd9dd1fdfe320e41)
Identifier: 265870.405 at safari-7616-branch
Commit: bd6f9b551dee426c8fd72f6eadb75e0336383d01
https://github.com/WebKit/WebKit/commit/bd6f9b551dee426c8fd72f6eadb75e0336383d01
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M LayoutTests/compositing/backing/backface-visibility-flip-expected.txt
M LayoutTests/compositing/layer-creation/overlap-transformed-preserved-3d-expected.txt
M LayoutTests/fast/text/combining-character-sequence-vertical.html
M LayoutTests/fast/text/vertical-quotation-marks.html
M LayoutTests/platform/ios-wk2/compositing/tiling/backface-preserve-3d-tiled-expected.txt
M LayoutTests/platform/ios-wk2/compositing/visible-rect/flipped-preserve-3d-expected.txt
M LayoutTests/platform/mac/compositing/tiling/backface-preserve-3d-tiled-expected.txt
M LayoutTests/platform/mac/compositing/visible-rect/flipped-preserve-3d-expected.txt
A LayoutTests/transforms/3d/hit-testing/hit-preserves-3d-3-expected.txt
A LayoutTests/transforms/3d/hit-testing/hit-preserves-3d-3.html
M Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp
Log Message:
-----------
Cherry-pick 1aa517d47471. rdar://111393557
Hit testing on element with 180deg flip inside preserve-3d not finding correct element.
https://bugs.webkit.org/show_bug.cgi?id=258565
<rdar://111393557>
Reviewed by Simon Fraser.
Floating point precision (using double) meant that sin(180deg) wasn't returning exactly 0.
When combining multiple transforms together using preserve-3d, this meant that layers that are intended to be coplanar
ended up at slightly different depths.
This adds rounding for tiny values to make them exactly zero, so that the layers end up coplanar again, and we hit
test in DOM order for those.
* LayoutTests/transforms/3d/hit-testing/hit-preserves-3d-3-expected.txt: Added.
* LayoutTests/transforms/3d/hit-testing/hit-preserves-3d-3.html: Added.
* Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:
(WebCore::roundEpsilonToZero):
(WebCore::TransformationMatrix::rotate3d):
(WebCore::TransformationMatrix::rotate):
Canonical link: https://commits.webkit.org/266237@main
(cherry picked from commit dc20f798ac70245fe6380b921b583a4d5bba6e0a)
Identifier: 265870.406 at safari-7616-branch
Commit: bb00c10b305060319518b5e38f3d2d13b01b5669
https://github.com/WebKit/WebKit/commit/bb00c10b305060319518b5e38f3d2d13b01b5669
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/bindings/js/JSDOMWrapper.cpp
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
M Source/WebCore/bindings/js/SerializedScriptValue.h
M Source/WebCore/dom/MessageEvent.cpp
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/UserContentWorld.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/postMessage-various-types.html
Log Message:
-----------
Cherry-pick acece69bd261. rdar://112618195
window.postMessage with OffscreenCanvas is broken with isolated world message listener
https://bugs.webkit.org/show_bug.cgi?id=259362
rdar://112618195
Reviewed by Darin Adler.
When constructing a MessageEvent, we would deserialize the `data` SerializedScriptValue
and cache the resulting JSValue. When accessing MessageEvent.data from the main world,
we would return the cached JSValue and everything would work fine.
However, upon accessing MessageEvent.data from a non-main world, the cached JSValue
would not be usable and we would deserialize the original SerializedScriptValue again.
The issue is that a SerializedScriptValue is not meant to be deserialized several times.
This is because the deserialization "consumes" certain internal objects. For examples,
OffscreenCanvas are stored as DetachedOffscreenCanvas internally and consumed upon
deserialization to construct OffscreenCanvas objects again.
To address the issue, this patch makes several changes:
1. MessageEvent::create() now stores the deserialized JSValue inside the MessageEvent
object instead of the SerializedScriptValue. As a result, when accessing
MessageEvent.data from the main world, we'll just return the internal JSValue.
When accessing MessageEvent.data from a non-main world, cachedPropertyValue() will
detect that the internal JSValue is no compatible with this world and call
cloneAcrossWorlds() on the internal JSValue to generate one suitable for the non-main
world. Internally, cloneAcrossWorlds() creates a SerializedScriptValue from the JSValue
and then deserializes that SerializedScriptValue in the target world.
2. As currently implemented, cloneAcrossWorlds() would drop transferrable objects such
as OffscreenCanvas and MessagePort. To address the issue, we now introduce a new
CloneAcrossWorlds SerializationContext. When in this context, SerializedScriptValue
serialization will store OffscreenCanvas/MessagePort in the JSValue inside internal
vectors and merely serialize indexes inside those vectors. Upon deserialization, we
deserialize the index and lookup the OffscreenCanvas/MessagePort from the internal
vector. Then, we call toJS() on the implementation object to get a JS wrapper for the
target world.
* Source/WebCore/bindings/js/JSDOMWrapper.cpp:
(WebCore::cloneAcrossWorlds):
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::isTypeExposedToGlobalObject):
(WebCore::CloneSerializer::serialize):
(WebCore::CloneSerializer::CloneSerializer):
(WebCore::CloneSerializer::dumpOffscreenCanvas):
(WebCore::CloneSerializer::dumpIfTerminal):
(WebCore::CloneDeserializer::deserialize):
(WebCore::CloneDeserializer::CloneDeserializer):
(WebCore::CloneDeserializer::readInMemoryOffscreenCanvas):
(WebCore::CloneDeserializer::readTerminal):
(WebCore::SerializedScriptValue::SerializedScriptValue):
(WebCore::SerializedScriptValue::create):
(WebCore::SerializedScriptValue::deserialize):
* Source/WebCore/bindings/js/SerializedScriptValue.h:
* Source/WebCore/dom/MessageEvent.cpp:
(WebCore::MessageEvent::create):
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/UserContentWorld.mm:
(-[UserContentWorldMessageHandler userContentController:didReceiveScriptMessage:]):
(TEST):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/postMessage-various-types.html: Added.
Canonical link: https://commits.webkit.org/266465@main
(cherry picked from commit 30374749222b984dc257ff566fa498d81d010c46)
Identifier: 265870.407 at safari-7616-branch
Commit: 5ebd13fafb50f19312b399fdc88a9dc5a0bd9690
https://github.com/WebKit/WebKit/commit/5ebd13fafb50f19312b399fdc88a9dc5a0bd9690
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/Headers.cmake
A Source/WebCore/Modules/mediastream/MediaAccessDenialReason.h
M Source/WebCore/Modules/mediastream/UserMediaRequest.cpp
M Source/WebCore/Modules/mediastream/UserMediaRequest.h
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp
M Source/WebCore/platform/mediastream/RealtimeMediaSource.h
M Source/WebCore/platform/mediastream/RealtimeMediaSourceCenter.cpp
M Source/WebCore/platform/mediastream/RealtimeMediaSourceCenter.h
M Source/WebCore/platform/mediastream/cocoa/DisplayCaptureSourceCocoa.cpp
M Source/WebCore/platform/mediastream/cocoa/DisplayCaptureSourceCocoa.h
M Source/WebCore/platform/mediastream/gstreamer/GStreamerAudioCaptureSource.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerDisplayCaptureDeviceManager.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoCaptureSource.cpp
M Source/WebCore/platform/mediastream/gstreamer/MockDisplayCaptureSourceGStreamer.cpp
M Source/WebCore/platform/mediastream/gstreamer/MockRealtimeAudioSourceGStreamer.cpp
M Source/WebCore/platform/mediastream/gstreamer/MockRealtimeVideoSourceGStreamer.cpp
M Source/WebCore/platform/mediastream/ios/ReplayKitCaptureSource.h
M Source/WebCore/platform/mediastream/ios/ReplayKitCaptureSource.mm
M Source/WebCore/platform/mediastream/mac/AVVideoCaptureSource.mm
M Source/WebCore/platform/mediastream/mac/CGDisplayStreamScreenCaptureSource.h
M Source/WebCore/platform/mediastream/mac/CGDisplayStreamScreenCaptureSource.mm
M Source/WebCore/platform/mediastream/mac/CoreAudioCaptureSource.cpp
M Source/WebCore/platform/mediastream/mac/MockAudioSharedUnit.mm
M Source/WebCore/platform/mediastream/mac/MockRealtimeVideoSourceMac.mm
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.h
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.h
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.mm
M Source/WebCore/platform/mock/MockRealtimeAudioSource.cpp
M Source/WebCore/platform/mock/MockRealtimeMediaSourceCenter.cpp
M Source/WebCore/platform/mock/MockRealtimeVideoSource.cpp
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp
M Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.h
M Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.messages.in
M Source/WebKit/UIProcess/SpeechRecognitionServer.cpp
M Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/WebProcess/MediaStream/UserMediaPermissionRequestManager.cpp
M Source/WebKit/WebProcess/MediaStream/UserMediaPermissionRequestManager.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeAudioSource.cpp
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSource.cpp
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSource.h
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSourceProxy.cpp
M Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSourceProxy.h
Log Message:
-----------
Cherry-pick a21e7fccf8e5. rdar://112978888
REGRESSION(259969 at main): wpt /screen-capture/getdisplaymedia.https.html
https://bugs.webkit.org/show_bug.cgi?id=259564
rdar://112978888
Reviewed by Youenn Fablet.
When a RealTimeMediaSource create function fails, return struct with a String and a failure
code so we can create the correct type of exception when rejecting a getUserMedia or
getDisplayMedia promise. Update a lot of plumbing to pass this struct around so we don't
have to guess about what error code to use.
* Source/WebCore/Headers.cmake:
* Source/WebCore/Modules/mediastream/MediaAccessDenialReason.h: Added.
* Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:
(WebCore::UserMediaRequest::allow):
(WebCore::UserMediaRequest::deny):
* Source/WebCore/Modules/mediastream/UserMediaRequest.h:
(): Deleted.
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/platform/mediastream/RealtimeMediaSource.h:
(WebCore::CaptureSourceError::CaptureSourceError):
(WebCore::CaptureSourceError::operator bool const):
(WebCore::CaptureSourceOrError::CaptureSourceOrError):
(WebCore::CaptureSourceOrError::operator bool const):
(WebCore::CaptureSourceOrError::source):
(WebCore::RealtimeMediaSource::whenReady):
* Source/WebCore/platform/mediastream/RealtimeMediaSourceCenter.cpp:
(WebCore::RealtimeMediaSourceCenter::createMediaStream):
* Source/WebCore/platform/mediastream/RealtimeMediaSourceCenter.h:
* Source/WebCore/platform/mediastream/cocoa/DisplayCaptureSourceCocoa.cpp:
(WebCore::DisplayCaptureSourceCocoa::create):
* Source/WebCore/platform/mediastream/cocoa/DisplayCaptureSourceCocoa.h:
* Source/WebCore/platform/mediastream/gstreamer/GStreamerAudioCaptureSource.cpp:
(WebCore::GStreamerAudioCaptureSource::create):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerDisplayCaptureDeviceManager.cpp:
(WebCore::GStreamerDisplayCaptureDeviceManager::createDisplayCaptureSource):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoCaptureSource.cpp:
(WebCore::GStreamerVideoCaptureSource::create):
(WebCore::GStreamerVideoCaptureSource::createPipewireSource):
* Source/WebCore/platform/mediastream/gstreamer/MockDisplayCaptureSourceGStreamer.cpp:
(WebCore::MockDisplayCaptureSourceGStreamer::create):
* Source/WebCore/platform/mediastream/gstreamer/MockRealtimeAudioSourceGStreamer.cpp:
(WebCore::MockRealtimeAudioSource::create):
* Source/WebCore/platform/mediastream/gstreamer/MockRealtimeVideoSourceGStreamer.cpp:
(WebCore::MockRealtimeVideoSource::create):
* Source/WebCore/platform/mediastream/ios/ReplayKitCaptureSource.h:
* Source/WebCore/platform/mediastream/ios/ReplayKitCaptureSource.mm:
(WebCore::ReplayKitCaptureSource::create):
* Source/WebCore/platform/mediastream/mac/AVVideoCaptureSource.mm:
(WebCore::AVVideoCaptureSource::create):
* Source/WebCore/platform/mediastream/mac/CGDisplayStreamScreenCaptureSource.h:
* Source/WebCore/platform/mediastream/mac/CGDisplayStreamScreenCaptureSource.mm:
(WebCore::CGDisplayStreamScreenCaptureSource::create):
* Source/WebCore/platform/mediastream/mac/CoreAudioCaptureSource.cpp:
(WebCore::initializeCoreAudioCaptureSource):
(WebCore::CoreAudioCaptureSource::create):
* Source/WebCore/platform/mediastream/mac/MockAudioSharedUnit.mm:
(WebCore::MockRealtimeAudioSource::create):
* Source/WebCore/platform/mediastream/mac/MockRealtimeVideoSourceMac.mm:
(WebCore::MockRealtimeVideoSource::create):
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.h:
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitCaptureSource.mm:
(WebCore::ScreenCaptureKitCaptureSource::create):
(WebCore::ScreenCaptureKitCaptureSource::~ScreenCaptureKitCaptureSource):
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.h:
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.mm:
(WebCore::ScreenCaptureKitSharingSessionManager::cancelPendingSessionForDevice):
* Source/WebCore/platform/mock/MockRealtimeAudioSource.cpp:
(WebCore::MockRealtimeAudioSource::create):
* Source/WebCore/platform/mock/MockRealtimeMediaSourceCenter.cpp:
* Source/WebCore/platform/mock/MockRealtimeVideoSource.cpp:
(WebCore::MockRealtimeVideoSource::create):
* Source/WebKit/Scripts/webkit/messages.py:
(types_that_cannot_be_forward_declared):
(headers_for_type):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp:
(WebKit::UserMediaCaptureManagerProxy::createMediaSourceForCaptureDeviceWithConstraints):
* Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.h:
* Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.messages.in:
* Source/WebKit/UIProcess/SpeechRecognitionServer.cpp:
(WebKit::SpeechRecognitionServer::handleRequest):
* Source/WebKit/UIProcess/UserMediaPermissionRequestManagerProxy.cpp:
(WebKit::toWebCore):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::createRealtimeMediaSourceForSpeechRecognition):
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::createSpeechRecognitionServer):
* Source/WebKit/WebProcess/MediaStream/UserMediaPermissionRequestManager.cpp:
(WebKit::UserMediaPermissionRequestManager::startUserMediaRequest):
(WebKit::UserMediaPermissionRequestManager::sendUserMediaRequest):
(WebKit::UserMediaPermissionRequestManager::userMediaAccessWasDenied):
* Source/WebKit/WebProcess/MediaStream/UserMediaPermissionRequestManager.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::userMediaAccessWasDenied):
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeAudioSource.cpp:
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSource.cpp:
(WebKit::RemoteRealtimeMediaSource::createRemoteMediaSource):
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSource.h:
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSourceProxy.cpp:
(WebKit::RemoteRealtimeMediaSourceProxy::whenReady):
(WebKit::RemoteRealtimeMediaSourceProxy::didFail):
* Source/WebKit/WebProcess/cocoa/RemoteRealtimeMediaSourceProxy.h:
Canonical link: https://commits.webkit.org/266483@main
(cherry picked from commit fa66c51f8723888ddda8bbab638fd1f045982d9b)
Identifier: 265870.408 at safari-7616-branch
Commit: 1ad87710592d28495cfa2961494665453d370601
https://github.com/WebKit/WebKit/commit/1ad87710592d28495cfa2961494665453d370601
Author: Devin Rousso <hi at devinrousso.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/DetailsSection.css
M Source/WebInspectorUI/UserInterface/Views/FontVariationDetailsSectionRow.css
M Source/WebInspectorUI/UserInterface/Views/InlineSwatch.css
M Source/WebInspectorUI/UserInterface/Views/SpreadsheetCSSStyleDeclarationEditor.css
Log Message:
-----------
Cherry-pick 0c7db85e2b70. rdar://113244266
Web Inspector: REGRESSION(?): Elements: background of color swatch is not checkered
https://bugs.webkit.org/show_bug.cgi?id=259720
Reviewed by Tim Nguyen.
Ensure that CSS `background-size` with only a percentage width also have a height, as if it's not included then it's assumed to be `auto`.
* Source/WebInspectorUI/UserInterface/Views/InlineSwatch.css:
(.inline-swatch:is(.color, .gradient)):
* Source/WebInspectorUI/UserInterface/Views/DetailsSection.css:
(.details-section > .content > .group > .row.simple > .warning):
* Source/WebInspectorUI/UserInterface/Views/FontVariationDetailsSectionRow.css:
(.details-section > .content > .group > .row.font-variation > .warning):
* Source/WebInspectorUI/UserInterface/Views/SpreadsheetCSSStyleDeclarationEditor.css:
(.spreadsheet-style-declaration-editor .property.has-warning .warning):
Drive-by: these should be fine since they already have a defined `height`, but fix them the same just in case.
Canonical link: https://commits.webkit.org/266502@main
(cherry picked from commit f8ac96cbba39dd520682e61e84c1bb688c123577)
Identifier: 265870.409 at safari-7616-branch
Commit: b6e8c842159b2b940cb4d359427769da07594da8
https://github.com/WebKit/WebKit/commit/b6e8c842159b2b940cb4d359427769da07594da8
Author: destra <destra at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/platform/audio/PlatformMediaSession.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewSuspendAllMediaPlayback.mm
Log Message:
-----------
Cherry-pick e6ac3419306c. rdar://111917263
Pausing media playback after suspending media playback, and then later unsuspending media
playback should not unpause media that was playing before the original suspension
https://bugs.webkit.org/show_bug.cgi?id=259801
rdar://111917263
Reviewed by Eric Carlson.
Currently, if playing media is suspended, then a user pauses the media, when
playback is unsuspended the media begins playing again. However the desired behavior is for
the pause to be honored when media is unsuspended. This bug happens because when playback is
suspended, PlatformMediaSession::beginInterruption records the playback state to restore when
unsuspended in m_stateToRestore. But this data member is not updated if pausing occurs while
suspended.
Now, when playback is paused, PlatformMediaSession::pauseSession checks if playback is currently
interrupted (meaning it is suspended), and if so, sets m_stateToRestore to 'paused'.
1 API test added that checks that after doing suspend -> pause -> unsuspend, media that was playing
originally is now paused.
* Source/WebCore/platform/audio/PlatformMediaSession.cpp:
(WebCore::PlatformMediaSession::pauseSession):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewSuspendAllMediaPlayback.mm:
Canonical link: https://commits.webkit.org/266590@main
(cherry picked from commit cff13798f2ee47638c0b12496e559c07c8a7be60)
Identifier: 265870.410 at safari-7616-branch
Commit: dbd593b40fe26fb708ba4546db6155002f8644b0
https://github.com/WebKit/WebKit/commit/dbd593b40fe26fb708ba4546db6155002f8644b0
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/WebProcessPool.cpp
Log Message:
-----------
Cherry-pick f68c66458d7e. rdar://113364552
Make web process run at foreground priority during initialization on macOS
https://bugs.webkit.org/show_bug.cgi?id=259807
rdar://113364552
Reviewed by Chris Dumez.
We've seen many reports about web processes becoming unresponsive during initialization (rdar://111051922). This could
be related to adopting RunningBoard assertion on macOS, which enables web processes that don't hold a visible view to
run at a lower priority than UI process. This can lead web process to spend more time in initialization. A full fix
would be not generating reports when WebKit explicitly sets low priority for web process. But before that, let's try
confirming the cause by simply bumping process priority during initialization.
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::initializeNewWebProcess):
Canonical link: https://commits.webkit.org/266592@main
(cherry picked from commit 61a948e5e900589e6be42efd9bec0f0ea838c046)
Identifier: 265870.411 at safari-7616-branch
Commit: 7d025ff552e922a73a1b10666b4838d738e7ef60
https://github.com/WebKit/WebKit/commit/7d025ff552e922a73a1b10666b4838d738e7ef60
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp
M Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp
M Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h
M Source/JavaScriptCore/bytecode/Repatch.cpp
Log Message:
-----------
Cherry-pick 41847fe79586. rdar://113416758
[JSC] IntrinsicGetter AccessCase should not use Equivalent condition
https://bugs.webkit.org/show_bug.cgi?id=259841
rdar://113416758
Reviewed by Keith Miller.
265594 at main leveraged Equivalent condition in AccessCase, but this is wrong.
DFG cannot use Equivalent condition for AccessCase (see planLoad, ComplexGetByStatus etc.),
and breaking a key invariant / heuristics for DFG.
This patch reverts 265594 at main and fixes the original issue in different way.
Instead of using Equivalent condition, we just check getter in AccessCase.
* Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:
(JSC::InlineCacheCompiler::generateImpl):
* Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionsForPrototypePropertyHit):
* Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:
* Source/JavaScriptCore/bytecode/Repatch.cpp:
(JSC::tryCacheGetBy):
Canonical link: https://commits.webkit.org/266659@main
(cherry picked from commit e2c240ab4d7f640c413237cad30813fe9ca18477)
Identifier: 265870.412 at safari-7616-branch
Commit: caf03fac689ed2abb9b237bbcd278c2addce2d42
https://github.com/WebKit/WebKit/commit/caf03fac689ed2abb9b237bbcd278c2addce2d42
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h
M Source/WebCore/editing/cocoa/AttributedString.h
M Source/WebCore/editing/cocoa/AttributedString.mm
M Source/WebCore/editing/cocoa/HTMLConverter.mm
M Source/WebCore/platform/cocoa/MIMETypeRegistryCocoa.mm
M Source/WebKit/Shared/Cocoa/WebCoreArgumentCodersCocoa.serialization.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewGetContents.mm
Log Message:
-----------
Cherry-pick 664af9c1e8d7. rdar://112030767
REGRESSION (261984 at main): Copied tables from some web pages don't properly paste into Numbers
https://bugs.webkit.org/show_bug.cgi?id=259928
rdar://112030767
Reviewed by Megan Gardner.
When copying a table in Quip and pasting into the Numbers app, tables are programmatically written
to the pasteboard as HTML; upon paste, UIFoundation uses `nsattributedstringagent` to convert this
pasted markup into an `NSAttributedString`, by loading the markup in a `WKWebView` and asking it to
`-_getContentsAsAttributedStringWithCompletionHandler:`. This exercises the `HTMLConverter` codepath
in WebCore, which implements the correct logic for representing tables and lists in the markup as
`-textBlocks` and `-textLists`, respectively, on `NSParagraphStyle`; for tables, we list multiple
`NSTextTableBlock`s that all point to the same `NSTextTable` object. For instance, two adjacent
cells in the same table would be represented as:
```
"NSParagraphStyle" => {
textBlocks => [ NSTextTableBlock 0x6000006e7100, table=<NSTextTable 0x6000003f27d0>, {0, 0} ],
…
}
"NSParagraphStyle" => {
textBlocks => [ NSTextTableBlock 0x6000006e6d80, table=<NSTextTable 0x6000003f27d0>, {0, 1} ],
…
}
```
Similarly, lists are represented by having multiple paragraph styles with the same `NSTextList`s.
Two adjacent items in the same list, for instance, will have paragraph styles whose `-textLists`
array contains the exact same list (i.e. equal pointers):
```
"NSParagraphStyle" => {
textLists => [ NSTextList 0x600002676400 format <{disc}> ],
…
}
"NSParagraphStyle" => {
textLists => [ NSTextList 0x600002676400 format <{disc}> ],
…
}
```
Prior to the changes in 261984 at main, we used a single `NSKeyedArchiver`/`NSKeyedUnarchiver` to
encode/decode an `NSAttributedString` when sending this data from the web process to the UI process
for writing to the pasteboard. This meant that Foundation's internal object caching mechanism in the
keyed archiver would ensure that multiple `NSParagraphStyle` instances that all reference the same
`NSTextList` or `NSTextTable` upon encoding would still reference the same list or table upon
decoding, thereby preserving the table/list structure when writing to the pasteboard.
However, after 261984 at main, we now use a different keyed (un)archiver when encoding/decoding each
individual attribute; as a result, different `NSParagraphStyle` instances that reference the same
`NSTextList` or `NSTextTable` no longer correspond to the same object in the archiver's backing map.
This means that in the two above examples, we'd end up with two 2x1 tables (each with only 1 cell
populated), and two single-item lists, respectively.
To fix this, we add some logic to plumb unique identifiers corresponding to tables or lists for each
`NSTextBlock` or `NSTextList` in `-[NSParagraphStyle textBlocks]` and `-[NSParagraph textLists]`,
which are propagated along with the rest of the attributes upon encoding. When decoding, we use
these unique identifiers to ensure that all paragraph styles that previously referenced the same
table or list will continue to do so after decoding.
Tests: WKWebView.AttributedStringFromTable
WKWebView.AttributedStringFromList
* Source/WebCore/PAL/pal/spi/ios/UIKitSPI.h:
Move various UIKit SPI and IPI declarations out of the implementation file in `HTMLConverter.mm`
and into `UIKitSPI.h` instead, so that these declarations can be used in both `AttributedString.mm`
and `HTMLConverter.mm`.
* Source/WebCore/editing/cocoa/AttributedString.h:
Instead of encoding a single `RetainPtr<NSParagraphStyle>`, send a struct containing an
`RetainPtr<NSParagraphStyle>`, a list of `TextTableID` representing each text block, and a list of
`TextListID`. Note that `tableIDs` is a list of optional identifiers, since a `textBlock` may not
necessarily correspond to a table cell, in which case we use represent it via `nullopt`. `textLists`
doesn't have this same constraint since each entry corresponds directly to an `NSTextList`.
* Source/WebCore/editing/cocoa/AttributedString.mm:
(WebCore::reconstructStyle):
Add a helper method to take `HashMap`s of tables and lists by ID, and (only if necessary) create a
copy of the decoded `NSParagraphStyle` whose referenced tables and lists match those that were
previously referenced when decoding earlier parts of the attributed string.
(WebCore::toNSObject):
(WebCore::toNSDictionary):
Maintain maps of tables and lists by unique ID over the whole lifetime of decoding the string.
(WebCore::AttributedString::documentAttributesAsNSDictionary const):
(WebCore::AttributedString::nsAttributedString const):
(WebCore::extractListIDs):
(WebCore::extractTableIDs):
(WebCore::extractValue):
(WebCore::extractDictionary):
(WebCore::AttributedString::fromNSAttributedStringAndDocumentAttributes):
Implement the opposite half of the above logic, by collecting identical `NSTextList`s and
`NSTextTable`s that are referenced by `NSParagraphStyle`s during encoding. This allows us to build a
list of unique IDs that correspond to each table or list, which we send over IPC and use during
decoding to preserve references to the same objects when deserializing paragraph styles.
* Source/WebCore/editing/cocoa/HTMLConverter.mm:
* Source/WebCore/platform/cocoa/MIMETypeRegistryCocoa.mm:
(WebCore::extensionsForMIMETypeMap):
Drive-by fix: suppress a new deprecation warning.
* Source/WebKit/Shared/Cocoa/WebCoreArgumentCodersCocoa.serialization.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewGetContents.mm:
(-[WKWebView _contentsAsAttributedString]):
Add a couple of API tests to exercise attributed string conversion for tables and lists.
Importantly, these tests verify that table/list structure is preserved in the decoded string.
Canonical link: https://commits.webkit.org/266700@main
(cherry picked from commit 46c55c898c40d07178025f08beec969dfca927e2)
Identifier: 265870.413 at safari-7616-branch
Commit: 1e5c48509c90e28c869c0b523823edf6ed4e6151
https://github.com/WebKit/WebKit/commit/1e5c48509c90e28c869c0b523823edf6ed4e6151
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/JavaScriptCore/parser/SourceProvider.cpp
M Source/JavaScriptCore/parser/SourceProvider.h
M Source/JavaScriptCore/runtime/ScriptExecutable.h
M Source/JavaScriptCore/runtime/StackFrame.cpp
Log Message:
-----------
Cherry-pick 6fb27543f7ac. rdar://113616170
[JSC] sourceURLStripped should be cached
https://bugs.webkit.org/show_bug.cgi?id=259969
rdar://113616170
Reviewed by Keith Miller.
262420 at main introduced sourceURLStripped for error stack URLs. However this is really costly operation,
as a result, it makes error stack string generation slower. JetStream2/chai-wtb is frequently creating
this error stack string, so this is affected by this change by up to 5%.
This patch fixes the above performance issue by caching sourceURLStripped in SourceProvider.
* Source/JavaScriptCore/parser/SourceProvider.cpp:
(JSC::SourceProvider::sourceURLStripped):
* Source/JavaScriptCore/parser/SourceProvider.h:
* Source/JavaScriptCore/runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::sourceURLStripped const):
* Source/JavaScriptCore/runtime/StackFrame.cpp:
(JSC::processSourceURL):
(JSC::StackFrame::sourceURL const):
(JSC::StackFrame::sourceURLStripped const):
Canonical link: https://commits.webkit.org/266728@main
(cherry picked from commit a8407be948b2a6ee3b6fab633d991b23759bc7ac)
Identifier: 265870.414 at safari-7616-branch
Commit: 5ec4fb5861a295d30ae02adfc78f573d992236b6
https://github.com/WebKit/WebKit/commit/5ec4fb5861a295d30ae02adfc78f573d992236b6
Author: Matthew Finkel <sysrqb at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/xhr/resources/redirect.py
M LayoutTests/imported/w3c/web-platform-tests/xhr/send-redirect-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/xhr/send-redirect.htm
M Source/WebCore/platform/network/ResourceHandleInternal.h
M Source/WebCore/platform/network/mac/ResourceHandleMac.mm
M Source/WebKit/NetworkProcess/NetworkDataTask.h
M Source/WebKit/NetworkProcess/NetworkLoad.h
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm
Log Message:
-----------
Cherry-pick 9b8c53bed4f5. rdar://111899420
Content-Type gets wrongfully added to GET request after 303 redirects
https://bugs.webkit.org/show_bug.cgi?id=258720
rdar://111899420
Reviewed by Chris Dumez.
In 252713 at main we began copying the Content-Type header from the original
request if we receive a redirect with a 303 response status. However, we may be
handling a subsequent redirect, and in some cases the Content-Type header is
removed from redirect requests. For example, if we transition from a POST to a
GET request, Fetch 4.4.12 [0] says that the Content-Type header should be
deleted. WebKit currently follows this specification, but we re-introduce the
header on a second redirect because we consult the first request instead of the
previous request.
This patch introduces NetworkDataTask::m_previousRequest to keep track of the
previous request. This is duplicate information that is stored in NetworkLoad,
as well, but I'm leaving merging these two copies for a follow-up patch.
[0] https://fetch.spec.whatwg.org/#http-redirect-fetch
* LayoutTests/imported/w3c/web-platform-tests/xhr/resources/redirect.py:
(main):
* LayoutTests/imported/w3c/web-platform-tests/xhr/send-redirect-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/xhr/send-redirect.htm:
* Source/WebCore/platform/network/ResourceHandleInternal.h:
* Source/WebCore/platform/network/mac/ResourceHandleMac.mm:
(WebCore::ResourceHandle::willSendRequest):
* Source/WebKit/NetworkProcess/NetworkDataTask.h:
* Source/WebKit/NetworkProcess/NetworkLoad.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm:
(WebKit::NetworkDataTaskCocoa::willPerformHTTPRedirection):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm:
(TEST):
Canonical link: https://commits.webkit.org/266761@main
(cherry picked from commit e0a1b0c5ac4afd4f7af683f95fd0f1b13465a55d)
Identifier: 265870.415 at safari-7616-branch
Commit: 77627a76cd8721d6459d2246c8a38323fa02f299
https://github.com/WebKit/WebKit/commit/77627a76cd8721d6459d2246c8a38323fa02f299
Author: Vitor Roriz <vitor.roriz at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-reload-expected.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-reload-ref.html
A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-reload.html
M Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp
Log Message:
-----------
Cherry-pick 04c2e0b22b88. rdar://111709567
Fix font-size-adjust toggling font sizes for 'system-ui' font.
https://bugs.webkit.org/show_bug.cgi?id=259895
rdar://111709567
Reviewed by Tim Nguyen.
When using 'system-ui' font, we will end up calling FontFamilySpecificationCoreText::fontRanges for obtaining FontRanges
with an appended font.
Before this patch, ::fontRanges() was updating the font's size for the
font-size-adjust everytime fontRange was called. The update would mutate
the font that is cached. After the page is refreshed and this function
was called again, we would retrieve the cached font, and execute the
size adjustment again, what would cause the bug.
This patch moves the call to updateSizeWithFontSizeAdjust to the lambda
function invoked when the Font is being cached, guaranteeing it will be
called just once.
* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-reload-expected.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-reload-ref.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/font-size-adjust-reload.html: Added.
* Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp:
(WebCore::FontFamilySpecificationCoreText::fontRanges const):
Canonical link: https://commits.webkit.org/266771@main
(cherry picked from commit 841cb7a2f104d51d3eb8275afd99f57d96cbfa8a)
Identifier: 265870.416 at safari-7616-branch
Commit: cf5a3ad5d1fb0637924ff536ef47812270363428
https://github.com/WebKit/WebKit/commit/cf5a3ad5d1fb0637924ff536ef47812270363428
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj
M Source/WebCore/PAL/pal/PlatformMac.cmake
A Source/WebCore/PAL/pal/spi/cocoa/NetworkSPI.h
M Source/WebCore/platform/network/cf/ResourceError.h
M Source/WebCore/platform/network/mac/ResourceErrorMac.mm
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCTCPSocketCocoa.mm
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCUDPSocketCocoa.mm
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCUtilitiesCocoa.h
M Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm
R Source/WebKit/Platform/spi/Cocoa/NWSPI.h
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick c307e83c5b06. rdar://112243760
[Private Browsing 2.0] Some trackers blocked by libnetcore aren't listed in Privacy Report
https://bugs.webkit.org/show_bug.cgi?id=260024
rdar://112243760
Reviewed by Tim Horton and Matthew Finkel.
Currently, blocked tracking requests in Private Browsing mode are surfaced to Safari through the
navigation delegate method `-_webView:didFailLoadDueToNetworkConnectionIntegrityWithURL:`. Safari
then cross-references these URLs against another dataset of known trackers, and only shows blocked
domains in the Privacy Report UI, if the tracking domain matches one on this list. When blocking
CNAME-cloaked requests, this filtering means that unless the original request URL is itself a
known tracker, Safari will just omit this from the UI.
To fix this, we extract the host name of the endpoint that warranted blocking from libnetcore, and
replace the host name of the reported URL with this name instead: for instance, if "tracker.foo.com"
is a CNAME alias to "tracker.com", we'll report "tracker.com" instead of the original request,
"tracker.foo.com".
No new test, since this would require network request to a URL that's a CNAME alias, and which
mDNSResponder would map to a known tracking domain.
* Source/WebCore/PAL/PAL.xcodeproj/project.pbxproj:
* Source/WebCore/PAL/pal/PlatformMac.cmake:
* Source/WebCore/PAL/pal/spi/cocoa/NetworkSPI.h: Renamed from Source/WebKit/Platform/spi/Cocoa/NWSPI.h.
Move this header from WebKit into PAL, so we can use it below. We also rename the file to the
(slightly-less-mysterious) `NetworkSPI.h`.
* Source/WebCore/platform/network/cf/ResourceError.h:
(WebCore::ResourceError::blockedKnownTracker const):
(WebCore::ResourceError::blockedTrackerHostName const):
* Source/WebCore/platform/network/mac/ResourceErrorMac.mm:
(extractBlockedTrackerHostName):
Change the `m_blockedKnownTracker` flag to a string: `m_blockedTrackerHostName`. The null string
represents that the request was not blocked.
(WebCore::ResourceError::platformLazyInit):
(failureIsDueToTrackerBlocking): Deleted.
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didFailLoading):
Use the `blockedTrackerHostName()` above to replace the reported URL's host when reporting the
failing URL to the UI process via `NetworkProcessProxy::DidBlockLoadToKnownTracker`.
* Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm:
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCTCPSocketCocoa.mm:
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCUDPSocketCocoa.mm:
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCUtilitiesCocoa.h:
* Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm:
Change `NWSPI.h` imports to `<pal/spi/cocoa/NWSPI.h>`.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/266789@main
(cherry picked from commit a2a01661711d90db84f0636bfe0c368fb5008375)
Identifier: 265870.417 at safari-7616-branch
Commit: ae0a8a76325d2eb703b9aad13bb5f735d93d431d
https://github.com/WebKit/WebKit/commit/ae0a8a76325d2eb703b9aad13bb5f735d93d431d
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/platform/network/cf/ResourceError.h
M Source/WebCore/platform/network/mac/ResourceErrorMac.mm
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Cherry-pick bf96dcdc21fe. rdar://112243760
Remove tracker-related member variables in ResourceError
https://bugs.webkit.org/show_bug.cgi?id=260084
Reviewed by Alex Christensen.
Remove `ResourceError::m_blockedTrackerHostName`, and replace it with a couple of getter methods
instead to retrieve (1) whether or not the networking stack blocked a tracker, and (2) the resolved
host name of a blocked known tracker from the underlying `NSError`.
* Source/WebCore/platform/network/cf/ResourceError.h:
(WebCore::ResourceError::blockedKnownTracker const): Deleted.
(WebCore::ResourceError::blockedTrackerHostName const): Deleted.
* Source/WebCore/platform/network/mac/ResourceErrorMac.mm:
(WebCore::ResourceError::platformLazyInit):
(WebCore::ResourceError::blockedKnownTracker const):
(WebCore::ResourceError::blockedTrackerHostName const):
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didFailLoading):
Canonical link: https://commits.webkit.org/266840@main
(cherry picked from commit d8627b2e35c6cf4dd9a8131213dbbc2afc95a504)
Identifier: 265870.418 at safari-7616-branch
Commit: 53381bc6d9c191b46063198d078eef22cbf9be47
https://github.com/WebKit/WebKit/commit/53381bc6d9c191b46063198d078eef22cbf9be47
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/editing/AlternativeTextController.cpp
Log Message:
-----------
Cherry-pick 72850fdaaa7a. rdar://107152521
[macOS] Remove correction indicator underline when correction panel is shown
https://bugs.webkit.org/show_bug.cgi?id=260166
rdar://107152521
Reviewed by Megan Gardner.
On MacOS, we don't want the correction indictor underline to appear when
we've also shown a correction panel. To align with this expectation, we
simply remove the correction indicator marker from the corrected text
range as we're about the present the panel.
* Source/WebCore/editing/AlternativeTextController.cpp:
(WebCore::AlternativeTextController::timerFired):
Canonical link: https://commits.webkit.org/266888@main
(cherry picked from commit 819521e1066c59b667afdcba8f1ee4cfb683132f)
Identifier: 265870.419 at safari-7616-branch
Commit: f395f0d177b80cc006a4e33c00056a3a44678487
https://github.com/WebKit/WebKit/commit/f395f0d177b80cc006a4e33c00056a3a44678487
Author: Michael Saboff <msaboff at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M JSTests/stress/regexp-lookbehind.js
M Source/JavaScriptCore/yarr/YarrInterpreter.cpp
M Source/JavaScriptCore/yarr/YarrPattern.cpp
Log Message:
-----------
Cherry-pick caa31552bab4. rdar://112952197
Positive look-behind RegExp doesn't match in JSC but does match in V8
https://bugs.webkit.org/show_bug.cgi?id=259536
rdar://112952197
Reviewed by Yusuke Suzuki.
The reported bug indicated one issue. We were performing the beginning of line / end of line assertion optimization
on lookbehinds that contain BOL's / EOL's. Given that we match backwards for lookbehinds while doing soft
"do we have enough input" checks, we won't properly match such an assertion as the BOL assertion optimization
assumes that the BOL is at position 0 and not some prior location in the lookbehind.
After fixing that bug and adding more tests, discovered that we don't properly handle lookbehinds with alternatives
of different minimum lengths. We emit a single HaveCheckedInput for the minimum size of the alternation. Added a
check to emit a HaveCheckedInput for any alternative that had a minimum size larger that the minimum for the whole
alternation.
Updated tests accordingly.
* JSTests/stress/regexp-lookbehind.js:
(testRegExp.v):
(d.v):
(testRegExp.v.sv):
(testRegExp.v.sv.Rev):
* Source/JavaScriptCore/yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::emitDisjunction):
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::assertionBOL):
(JSC::Yarr::YarrPatternConstructor::copyDisjunction):
Canonical link: https://commits.webkit.org/266912@main
(cherry picked from commit 5afb8ddafd2b682aa3c593aabefb0d7bd345a8fc)
Identifier: 265870.420 at safari-7616-branch
Commit: 55089218c9086228d203b7b10e04eff538e4062d
https://github.com/WebKit/WebKit/commit/55089218c9086228d203b7b10e04eff538e4062d
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
A LayoutTests/fast/block/float/float-left-with-clear-right-incorrect-position-expected.html
A LayoutTests/fast/block/float/float-left-with-clear-right-incorrect-position.html
M Source/WebCore/layout/floats/FloatingContext.cpp
Log Message:
-----------
Cherry-pick 0c0259832cca. rdar://111577468
(REGRESSION 262277 at main) Incorrect float placement when clear is present
https://bugs.webkit.org/show_bug.cgi?id=260202
<rdar://111577468>
Reviewed by Antti Koivisto.
When no float is present at the clear direction it still needs to "clear" the existing floats.
e.g.
<div style="float: left"></div>
<div style="float: left; clear: right;"></div>
(notice we are supposed to clear right, but there's no right float in this context)
This patch ensures that we take existing floats into account for the initial position when there's nothing to clear.
* LayoutTests/fast/block/float/float-left-with-clear-right-incorrect-position-expected.html: Added.
* LayoutTests/fast/block/float/float-left-with-clear-right-incorrect-position.html: Added.
* Source/WebCore/layout/floats/FloatingContext.cpp:
(WebCore::Layout::FloatingContext::positionForFloat const):
(WebCore::Layout::FloatingContext::bottom const):
Canonical link: https://commits.webkit.org/266918@main
(cherry picked from commit 494bccac86ee6f585ff56138f28a99df19b7ec56)
Identifier: 265870.421 at safari-7616-branch
Commit: 6e9dd5f9bb779b77d66d923ec5e15db66e333b61
https://github.com/WebKit/WebKit/commit/6e9dd5f9bb779b77d66d923ec5e15db66e333b61
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick d409ef2d247f. rdar://112444285
[visionOS] Videos on youtube.com are cropped in compatibility mode when using a mobile UA
https://bugs.webkit.org/show_bug.cgi?id=260192
rdar://112444285
Reviewed by Mike Wyrzykowski and Richard Robinson.
Unlike the desktop site, YouTube's mobile site fullscreens the <video> element
rather than an element containing the <video>. Currently, on visionOS, WebKit
always uses element fullscreen (rather than the native player) when playing
fullscreen <video>. However, this results in cropping on YouTube's mobile site
as YouTube sets `object-fit: cover` on the <video>. On iPadOS, this CSS would
have no observable effect, as the native player is used.
This issue does not reproduce with YouTube's mobile site in Safari on visionOS,
even though element fullscreen is enforced, as the fullscreen window's aspect
ratio matches the <video>.
However, in compatibility mode, the fullscreen behavior should match iPadOS.
Fix by ensuring element fullscreen is not forced for <video> fullscreen in
compatibility mode.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::enterFullscreen):
Use the existing `videoFullscreenRequiresElementFullscreen` to determine whether
to force element fullscreen for <video>. This flag is only true when running on
visionOS, and compatibility mode is not active.
Canonical link: https://commits.webkit.org/266920@main
(cherry picked from commit a3e0a74bce24dca4a7f4bb80d90956773e28decf)
Identifier: 265870.422 at safari-7616-branch
Commit: 223cc07779578e3ae11c948251da8a9a5008cfe2
https://github.com/WebKit/WebKit/commit/223cc07779578e3ae11c948251da8a9a5008cfe2
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/rendering/RenderVideo.cpp
M Source/WebCore/rendering/RenderVideo.h
Log Message:
-----------
Cherry-pick cf3b8b67645c. rdar://113732345
Resizing video on YouTube can result in aliasing
https://bugs.webkit.org/show_bug.cgi?id=259171
<radar://112172798>
Reviewed by Tim Horton.
Undo the revert of 266284 at main but pass the correct size which
is videoBox().size() as opposed to contentSize(), so that videos
playing in fullscreen element which are within one point of the window
size take up the entire window size.
The latter caused a regression on macOS and iOS for letter boxed
videos or videos which did not consume the entire contentSize.
* Source/WebCore/rendering/RenderVideo.cpp:
(WebCore::RenderVideo::videoBox const):
(WebCore::RenderVideo::inElementOrVideoFullscree const):
(WebCore::RenderVideo::updatePlayer):
* Source/WebCore/rendering/RenderVideo.h:
Canonical link: https://commits.webkit.org/266933@main
(cherry picked from commit a8e014e365422c1f4b06d15840ba137e1926f033)
Identifier: 265870.423 at safari-7616-branch
Commit: 2636d8b53aa4d70780a8bb602afe5811e217b983
https://github.com/WebKit/WebKit/commit/2636d8b53aa4d70780a8bb602afe5811e217b983
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.css
M Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.js
Log Message:
-----------
Cherry-pick 1d5fbefb7141. rdar://113722710
visionOS Media Controls: Volume slider has wrong layout in small sizes
https://bugs.webkit.org/show_bug.cgi?id=260130
rdar://113722710
Reviewed by Tim Horton and Tim Nguyen.
The mute button should always be `Bar` when contained in a volume slider.
Drive-by fix: General media controls polish
- Fix bottom bar controls having a weird animation when changing fullscreen size by making the
transition be constrained only to the slider.
- Increase the size of the volume slider a bit to better match the system, and to make it easier to use.
- Apply the same track thumb style to the volume slider that the time slider uses.
* Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.css:
(.media-controls.vision.fullscreen .controls-bar.simple-layout .slider.vision.volume,):
(.media-controls.vision:not(.audio) .slider,):
(.media-controls.vision:not(.audio) > .controls-bar.top-right *,):
(.media-controls.vision:not(.audio) > .controls-bar.simple-layout.top-right .fill:after):
(.media-controls.vision:not(.audio) > .bottom.controls-bar .fill:after):
(.media-controls.vision:not(.audio) > .controls-bar.simple-layout.top-right .fill:after,):
(.media-controls.vision:not(.audio) > .controls-bar.simple-layout.top-right .slider:active .fill:after,):
(.media-controls.vision:not(.audio) > .bottom.controls-bar,): Deleted.
(.media-controls.vision:not(.audio) > .bottom.controls-bar *): Deleted.
(.media-controls.vision:not(.audio) > .bottom.controls-bar .slider:active .fill:after): Deleted.
* Source/WebCore/Modules/modern-media-controls/controls/vision-media-controls.js:
(VisionFullscreenMediaControls.prototype._performBottomBarLayout):
(VisionFullscreenMediaControls):
Canonical link: https://commits.webkit.org/266939@main
(cherry picked from commit 7ab5a08494a28c84e2477012380d7c19cbdbb2f8)
Identifier: 265870.424 at safari-7616-branch
Commit: 6a37d7774d058ae4543e816514d0f3c19e5d38d9
https://github.com/WebKit/WebKit/commit/6a37d7774d058ae4543e816514d0f3c19e5d38d9
Author: Megan Gardner <megan_gardner at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/forms/WKDateTimeInputControl.mm
Log Message:
-----------
Cherry-pick f08aa3ffb050. rdar://113725970
Buttons on the Date/Time picker are too low on visionOS.
https://bugs.webkit.org/show_bug.cgi?id=260316
rdar://113725970
Reviewed by Aditya Keerthi.
We had a hard coded size for the accessory view for the buttons
at the bottom of the date/time picker, and since visionOS has
a different layout, it did not look good on the platform. Use
sizeThatFits to have a good size on all platforms and remove
the constant as well as some others that are no longer used.
* Source/WebKit/UIProcess/ios/forms/WKDateTimeInputControl.mm:
(-[WKDateTimePicker initWithView:datePickerMode:]):
Canonical link: https://commits.webkit.org/266973@main
(cherry picked from commit 9fb1acf530496a880c12a0d46f32caf8d8005198)
Identifier: 265870.425 at safari-7616-branch
Commit: 1d26d4508b09fa092946e676336fdb36002455fe
https://github.com/WebKit/WebKit/commit/1d26d4508b09fa092946e676336fdb36002455fe
Author: Brent Fulgham <bfulgham at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
Log Message:
-----------
Cherry-pick 3372a68e3655. rdar://112032774
os_log_set_hook return value is improperly ignored
https://bugs.webkit.org/show_bug.cgi?id=260303
<rdar://112032774>
Reviewed by Per Arne Vollan.
In Bug 253342 we adopted `os_log_set_hook` so that we could relay logging information
from the WebContent process to the Network process to add to the logging system.
The documentation for this method says:
* os_log_set_hook returns the previously registered hook or NULL
* when this function is first called. As a client, if you register a hook and the
* return value is not NULL then it is your responsibility to chain the
* previous hook into the new hook so that both are invoked.
Any previously registered hook is unlikely to be able to interact with `logd`, since
we are sandboxed, but perhaps there are other side-effects we want to retain.
To comply with the API design, we should invoke any preregistered hooks before calling
our own logic.
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::registerLogHook):
Canonical link: https://commits.webkit.org/267007@main
(cherry picked from commit 1d3bcfaf8ec66dd7cb86ac7c688cd0dae0f23475)
Identifier: 265870.426 at safari-7616-branch
Commit: 77e7e609d21f037ca0d82b21472eb41e59c9b0f3
https://github.com/WebKit/WebKit/commit/77e7e609d21f037ca0d82b21472eb41e59c9b0f3
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/AVFoundationSPI.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
Log Message:
-----------
Cherry-pick 4c5bf811e466. rdar://112181086
[visionOS] Safari YouTube audio location stays stationary when window is moved while viewing other tab (audio is not spatial)
https://bugs.webkit.org/show_bug.cgi?id=260364
<radar://112181086>
Reviewed by Andy Estes.
Set the STSLabel when the viewer becomes invisible so audio follows the scene.
Set it back to nil when the viewer becomes visible to restore the current behavior.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::setPageIsVisible):
* Source/WebCore/PAL/pal/spi/cocoa/AVFoundationSPI.h:
Stage SPI for non-internal clients.
Canonical link: https://commits.webkit.org/267018@main
(cherry picked from commit a2c5bee6afc43220c36f582931039985fa30bf34)
Identifier: 265870.427 at safari-7616-branch
Commit: f9e61f6c2208deee281505d5af6f30f63858dc82
https://github.com/WebKit/WebKit/commit/f9e61f6c2208deee281505d5af6f30f63858dc82
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
Log Message:
-----------
Cherry-pick f4896f6e7c4b. rdar://113768013
AX: -[WebAccessibilityObjectWrapper attributedStringForNSRange:] should exit early for ranges of zero length
https://bugs.webkit.org/show_bug.cgi?id=260055
rdar://113768013
Reviewed by Andres Gonzalez.
We should exit early if given a range of zero length because asking an object for its attributed string
of zero length does not make sense. Also, return `nil` instead of returning an empty attributed string,
since empty, non-nil attributed strings can cause issues for some assistive technologies.
* Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper attributedStringForNSRange:]):
Canonical link: https://commits.webkit.org/267045@main
(cherry picked from commit 9dc8fb2aa4aaed53260f6477df18439b0e47287e)
Identifier: 265870.428 at safari-7616-branch
Commit: 894b2386142f37f1d0cdf774cf5ffc0288d6d066
https://github.com/WebKit/WebKit/commit/894b2386142f37f1d0cdf774cf5ffc0288d6d066
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
A JSTests/stress/spread-for-runtime-array.js
M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
M Source/JavaScriptCore/runtime/CommonSlowPaths.cpp
M Source/JavaScriptCore/runtime/IteratorOperations.cpp
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructorInlines.h
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h
M Source/JavaScriptCore/tools/JSDollarVM.cpp
M Source/WebCore/bindings/js/JSObservableArray.h
M Source/WebCore/bridge/runtime_array.h
Log Message:
-----------
Cherry-pick a347abe159d3. rdar://107768559
Cherry-pick 266464 at main (a347abe159d3). rdar://107768559
Intermittent removal of adoptedStyleSheet CSSStyleSheet instances when assigning adoptedStyleSheet array
https://bugs.webkit.org/show_bug.cgi?id=254844
rdar://107768559
Reviewed by Mark Lam.
JSObservableArray is using ArrayClass, but this is wrong: this is not implementing what Array in DFG etc. requires.
As a result, DFG attempt to read length in the same way to normal array, and it just reads empty butterfly.
1. JSObservableArray must not say ArrayClass. ArrayClass is more strict form (like, ArrayType), and DerivedArray normally
should not use it.
2. We also fix NPAPI's half-broken RuntimeArray's ArrayClass to NonArray.
3. We also change iteration protocol to consider this new scheme: we should only allow fast iteration for normal pure JSArray.
* JSTests/stress/spread-for-runtime-array.js: Added.
(shouldBe):
(test):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* Source/JavaScriptCore/runtime/CommonSlowPaths.cpp:
(JSC::iteratorNextTryFastImpl):
* Source/JavaScriptCore/runtime/IteratorOperations.cpp:
(JSC::getIterationMode):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::setFromArrayLike):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewPrivateFuncFromFast):
* Source/JavaScriptCore/tools/JSDollarVM.cpp:
* Source/WebCore/bindings/js/JSObservableArray.h:
* Source/WebCore/bridge/runtime_array.h:
Canonical link: https://commits.webkit.org/266464@main
(cherry picked from commit c6586f1cb34809a3243ef644464a78fcbea0038f)
Identifier: 265870.429 at safari-7616-branch
Commit: 0a2c9f72634fdae6f8001908b0a0236aee1d17fd
https://github.com/WebKit/WebKit/commit/0a2c9f72634fdae6f8001908b0a0236aee1d17fd
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/AccessibilityRenderObject.cpp
M Source/WebCore/html/HTMLAnchorElement.cpp
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/RenderBlock.h
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderBox.h
M Source/WebCore/rendering/RenderInline.cpp
M Source/WebCore/rendering/RenderInline.h
M Source/WebCore/rendering/RenderLineBreak.cpp
M Source/WebCore/rendering/RenderLineBreak.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
M Source/WebCore/rendering/RenderText.cpp
M Source/WebCore/rendering/RenderText.h
M Source/WebCore/rendering/RenderView.cpp
M Source/WebCore/rendering/RenderView.h
M Source/WebCore/rendering/svg/LegacyRenderSVGModelObject.cpp
M Source/WebCore/rendering/svg/LegacyRenderSVGModelObject.h
M Source/WebCore/rendering/svg/RenderSVGBlock.cpp
M Source/WebCore/rendering/svg/RenderSVGBlock.h
M Source/WebCore/rendering/svg/RenderSVGHiddenContainer.h
M Source/WebCore/rendering/svg/RenderSVGModelObject.cpp
M Source/WebCore/rendering/svg/RenderSVGModelObject.h
M Source/WebCore/rendering/svg/RenderSVGRoot.cpp
M Source/WebCore/rendering/svg/RenderSVGRoot.h
Log Message:
-----------
Cherry-pick 42d07b729042. rdar://113175046
Cherry-pick 266494 at main (42d07b729042). rdar://113175046
Rename RenderObject::absoluteRects() to RenderObject::boundingRects()
https://bugs.webkit.org/show_bug.cgi?id=259672
rdar://113175046
Reviewed by Alan Baradlay.
`RenderObject::absoluteRects()` didn't return absolute rects; it returns whatever
the caller asked for via the second parameter. So rename to `boundingRects()`.
Also change the rects to be LayoutRects.
* Source/WebCore/accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::elementPath const):
* Source/WebCore/html/HTMLAnchorElement.cpp:
(WebCore::hasNonEmptyBox):
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::textFragmentIndicatorTimerFired):
p* Source/WebCore/rendering/RenderBlock.cpp:
(WebCore::RenderBlock::boundingRects const):
(WebCore::RenderBlock::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderBlock.h:
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::boundingRects const):
(WebCore::RenderBox::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderBox.h:
* Source/WebCore/rendering/RenderInline.cpp:
(WebCore::RenderInline::boundingRects const):
(WebCore::RenderInline::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderInline.h:
* Source/WebCore/rendering/RenderLineBreak.cpp:
(WebCore::RenderLineBreak::boundingRects const):
(WebCore::RenderLineBreak::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderLineBreak.h:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::absoluteBoundingBoxRect const):
(WebCore::RenderObject::absoluteTextRects):
* Source/WebCore/rendering/RenderObject.h:
(WebCore::RenderObject::boundingRects const):
(WebCore::RenderObject::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderText.cpp:
(WebCore::RenderText::boundingRects const):
(WebCore::RenderText::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderText.h:
* Source/WebCore/rendering/RenderView.cpp:
(WebCore::RenderView::boundingRects const):
(WebCore::RenderView::absoluteRects const): Deleted.
* Source/WebCore/rendering/RenderView.h:
* Source/WebCore/rendering/svg/LegacyRenderSVGModelObject.cpp:
(WebCore::LegacyRenderSVGModelObject::boundingRects const):
(WebCore::LegacyRenderSVGModelObject::absoluteRects const): Deleted.
* Source/WebCore/rendering/svg/LegacyRenderSVGModelObject.h:
* Source/WebCore/rendering/svg/RenderSVGBlock.cpp:
(WebCore::RenderSVGBlock::boundingRects const):
(WebCore::RenderSVGBlock::absoluteRects const): Deleted.
* Source/WebCore/rendering/svg/RenderSVGBlock.h:
* Source/WebCore/rendering/svg/RenderSVGHiddenContainer.h:
* Source/WebCore/rendering/svg/RenderSVGModelObject.cpp:
(WebCore::RenderSVGModelObject::boundingRects const):
(WebCore::RenderSVGModelObject::absoluteRects const): Deleted.
* Source/WebCore/rendering/svg/RenderSVGModelObject.h:
* Source/WebCore/rendering/svg/RenderSVGRoot.cpp:
(WebCore::RenderSVGRoot::boundingRects const):
(WebCore::RenderSVGRoot::absoluteRects const): Deleted.
* Source/WebCore/rendering/svg/RenderSVGRoot.h:
Canonical link: https://commits.webkit.org/266494@main
(cherry picked from commit b8698d99ba3c58e4153ecc7f28c1cd10b3a4d55e)
Identifier: 265870.430 at safari-7616-branch
Commit: 30e37ea2bcb7d0bc303ef8826f191ecac453d05a
https://github.com/WebKit/WebKit/commit/30e37ea2bcb7d0bc303ef8826f191ecac453d05a
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
A LayoutTests/fast/forms/ua-shadow-select-all-behavior-expected.txt
A LayoutTests/fast/forms/ua-shadow-select-all-behavior.html
A LayoutTests/fast/forms/ua-shadow-select-all-crash-expected.txt
A LayoutTests/fast/forms/ua-shadow-select-all-crash.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/editing/VisibleSelection.cpp
Log Message:
-----------
Cherry-pick 786e20b52145. rdar://103683388
Cherry-pick 266505 at main (786e20b52145). rdar://103683388
VisibleSelection::nonBoundaryShadowTreeRootNode should return null when its anchor is a shadow root
https://bugs.webkit.org/show_bug.cgi?id=249862
rdar://103683388
Reviewed by Ryosuke Niwa.
Cherry-pick the following fix from Blink:
https://src.chromium.org/viewvc/blink?view=revision&revision=188788
While WebKit doesn't crash in release with the Blink test case, it does
hit the `ASSERT(!isShadowRoot());` assertion inside `Node::nonBoundaryShadowTreeRootNode()`
on debug builds. Also, our selection behavior was vastly different from Chrome and Firefox.
We would end up with a caret while Blink and Gecko would end up with a proper range
selection. This patch aligns our behavior with Blink.
* LayoutTests/fast/forms/ua-shadow-select-all-behavior-expected.txt: Added.
* LayoutTests/fast/forms/ua-shadow-select-all-behavior.html: Added.
* LayoutTests/fast/forms/ua-shadow-select-all-crash.html: Added.
* LayoutTests/fast/forms/ua-shadow-select-all-crash-expected.txt: Added.
* Source/WebCore/editing/VisibleSelection.cpp:
(WebCore::VisibleSelection::nonBoundaryShadowTreeRootNode const):
Canonical link: https://commits.webkit.org/266505@main
(cherry picked from commit 29e4d7d21ffd405e194ac02d84624d758771da79)
Identifier: 265870.431 at safari-7616-branch
Commit: 372c943385a2e6494787ade2951b3784ea93c3eb
https://github.com/WebKit/WebKit/commit/372c943385a2e6494787ade2951b3784ea93c3eb
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/en.lproj/Localizable.strings
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/ios/WKActionSheetAssistant.h
M Source/WebKit/UIProcess/ios/WKActionSheetAssistant.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick c007fbf1d5da. rdar://110675100
Cherry-pick 266892 at main (c007fbf1d5da). rdar://110675100
[visionOS] Add menu button to control scene dimming in fullscreen
https://bugs.webkit.org/show_bug.cgi?id=260164
rdar://110675100
Reviewed by Wenson Hsieh.
In <video> fullscreen, "Auto Dimming" will be offered as an option alongside
the rest of the overflow controls menu. In element fullscreen, a new menu is
added to the top left to hold the new action.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Enable fullscreen scene dimming by default.
* Source/WebCore/en.lproj/Localizable.strings:
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView fullScreenWindowSceneDimmingAction]):
Expose the action as a method on `WKWebView` so that the logic may be shared
between <video> and element fullscreen.
Use a `UIDeferredMenuElement` so that the action is initialized each time its
menu is presented, and the selected state is accurately reflected.
Use `UIMenuOptionsDisplayInline` in order to display a separator.
* Source/WebKit/UIProcess/ios/WKActionSheetAssistant.h:
* Source/WebKit/UIProcess/ios/WKActionSheetAssistant.mm:
(-[WKActionSheetAssistant showMediaControlsContextMenu:items:completionHandler:]):
Augment media controls context menu logic to add support for actions that are
completely handled on the UI process side.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView additionalMediaControlsContextMenuItemsForActionSheetAssistant:]):
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.h:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm:
Add `_WKExtrinsicButtonDelegate` in order to know if/when a button is presenting
a menu. If a menu is visible, the auto-hide logic needs to be prevented.
(-[_WKExtrinsicButton contextMenuInteraction:willDisplayMenuForConfiguration:animator:]):
(-[_WKExtrinsicButton contextMenuInteraction:willEndForConfiguration:animator:]):
(-[WKFullScreenViewController initWithWebView:]):
(-[WKFullScreenViewController hideUI]):
(-[WKFullScreenViewController videoControlsManagerDidChange]):
(-[WKFullScreenViewController loadView]):
(-[WKFullScreenViewController _createButtonWithExtrinsicContentSize:]):
(-[WKFullScreenViewController _wkExtrinsicButtonWillDisplayMenu:]):
Cancel auto-hide when a menu is presented.
(-[WKFullScreenViewController _wkExtrinsicButtonWillDismissMenu:]):
Auto-hide UI when the menu is dismissed, and playback is active.
(-[WKFullScreenViewController setSceneDimmed:]): Deleted.
(-[WKFullScreenViewController _toggleDimmingAction:]): Deleted.
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.h:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
(-[WKFullScreenWindowController prefersSceneDimming]):
(-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
Update logic to ensure dimming state is restored when exiting fullscreen, if the
preference is toggled while in fullscreen.
(-[WKFullScreenWindowController toggleSceneDimming]):
(-[WKFullScreenWindowController _prefersSceneDimming]): Deleted.
(-[WKFullScreenWindowController toggleDimming]): Deleted.
Canonical link: https://commits.webkit.org/266892@main
(cherry picked from commit b92101cbf647bea01ea35dace716000a3a5c7a8e)
Identifier: 265870.432 at safari-7616-branch
Commit: 2811f04e48da597eb0081f20f497d55b69e20058
https://github.com/WebKit/WebKit/commit/2811f04e48da597eb0081f20f497d55b69e20058
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/UIProcess/ios/WKPDFView.mm
M Tools/TestWebKitAPI/Tests/ios/UIPasteboardTests.mm
Log Message:
-----------
Cherry-pick 92e85e0ddd90. rdar://113107334
Cherry-pick 266894 at main (92e85e0ddd90). rdar://113107334
[iOS] Avoid leaving the data owner `Undefined` when writing to the pasteboard
https://bugs.webkit.org/show_bug.cgi?id=260171
rdar://113107334
Reviewed by Aditya Keerthi.
Instead of passing in `_UIDataOwnerUndefined` when copying or pasting web content, explicitly use
`_UIDataOwnerUser` when the current domain is not managed (unless the client has already set one of
the other data owner flags on the web view). This makes it explicit that the copied/pasted data is
unmanaged, and also avoids a fault message in pasteboard code, which would otherwise have security
implications.
Added new API test cases: UIPasteboardTests.PerformAsDataOwnerWithManagedURL
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _effectiveDataOwner:]):
Add a helper method to take a client supplied data owner value, and either return it (if defined) or
fall back to checking against `-[MCProfileConnection isManagedURL:]`.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _dataOwnerForPasteboard:]):
(-[WKContentView _writePromisedAttachmentToPasteboard:]):
* Source/WebKit/UIProcess/ios/WKPDFView.mm:
(-[WKPDFView actionSheetAssistant:performAction:]):
Patch a couple of places where we currently write to the pasteboard outside of the context of any
data owner in WebKit.
* Tools/TestWebKitAPI/Tests/ios/UIPasteboardTests.mm:
(TestWebKitAPI::TEST):
Add a couple of API tests to verify that:
1. An unmanaged domain results in `_UIDataOwnerUser` by default.
2. In a managed domain, if the client explicitly sets a `_UIDataOwner` type that's not undefined,
we'll use that instead of `_UIDataOwnerEnterprise`.
Canonical link: https://commits.webkit.org/266894@main
(cherry picked from commit 4a0ab27152e29484aed8873af680ee48baa8488b)
Identifier: 265870.433 at safari-7616-branch
Commit: ddf752fe162dc110a260dc086c17b2f873d467f8
https://github.com/WebKit/WebKit/commit/ddf752fe162dc110a260dc086c17b2f873d467f8
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/visionos/MRUIKitSPI.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick 2e3db948f82f. rdar://113512242
[visionOS] Safari URL bar goes up a bit when entering fullscreen, and back down when exiting
https://bugs.webkit.org/show_bug.cgi?id=260315
rdar://113512242
Reviewed by Tim Horton and Richard Robinson.
Safari's URL bar is implemented as an ornament. An ornament's position is
determined relative to its scene, using its `sceneAnchorPoint`. When performing
the fullscreen transition, the scene is temporarily resized to fit the original
window, as well as the fullscreen window. Since ornaments are anchored to scenes,
they move along with the resize.
Fix by temporarily updating ornament offsets to account for the temporary scene
size.
* Source/WebKit/Platform/spi/visionos/MRUIKitSPI.h:
`offset2D` is relative to the `sceneAnchorPoint`.
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKMRUIPlatterOrnamentProperties initWithOrnament:]):
Store the original `offset2D`, so that it can be restored when exiting fullscreen.
(-[WKFullScreenParentWindowState initWithWindow:]):
Store the original scene size, in order to determine the relative change in an
ornament's position.
(-[WKFullScreenWindowController _configureSpatialFullScreenTransition]):
(-[WKFullScreenWindowController _updateOrnamentOffsetsForTemporarySceneSize:]):
Update ornaments offsets to account for the temporary scene size.
(-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
Restore the original ornament offsets when exiting fullscreen.
Canonical link: https://commits.webkit.org/266984@main
(cherry picked from commit 36bdb612504686120ba978e4b0b9cdd82a14d1c3)
Identifier: 265870.434 at safari-7616-branch
Commit: 37acda0105bbc49d063f8b7552443210a4b05d6f
https://github.com/WebKit/WebKit/commit/37acda0105bbc49d063f8b7552443210a4b05d6f
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M LayoutTests/editing/selection/ios/change-selection-by-tapping-with-existing-selection.html
Log Message:
-----------
Cherry-pick 0f709caa10ac. rdar://105496266
[iOS] editing/selection/ios/change-selection-by-tapping-with-existing-selection.html fails
https://bugs.webkit.org/show_bug.cgi?id=259619
Reviewed by Wenson Hsieh.
This test fails on iOS because the test was expecting the selection end points to be canonicalized.
Use canonicalized positions so that the output matches the expectation.
* LayoutTests/editing/selection/ios/change-selection-by-tapping-with-existing-selection.html:
Canonical link: https://commits.webkit.org/266413@main
(cherry picked from commit 679a00736e21f20be176a85fdc76b82d019b7ce0)
Identifier: 265870.435 at safari-7616-branch
Commit: 8937c2cca87092457fcbb40623dd2ffd5bd2a981
https://github.com/WebKit/WebKit/commit/8937c2cca87092457fcbb40623dd2ffd5bd2a981
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/ThirdParty/ANGLE/src/compiler/translator/Compiler.cpp
Log Message:
-----------
Cherry-pick 266712 at main (f6e9a70fa4e3). rdar://111828854
ANGLE - error: implicit capture of 'this' with a capture default of '=' is deprecated [-Werror,-Wdeprecated-this-capture]
https://bugs.webkit.org/show_bug.cgi?id=259941
rdar://111828854
Reviewed by David Kilzer.
Newer versions of clang detect the now-deprecated implicit capture
of 'this' in lambdas. Replace that capture with explicit forms.
* Source/ThirdParty/ANGLE/changes.diff:
* Source/ThirdParty/ANGLE/src/compiler/translator/Compiler.cpp:
(sh::TCompiler::resizeClipAndCullDistanceBuiltins):
Canonical link: https://commits.webkit.org/266712@main
(cherry picked from commit 72de556c6a4b16e694c3e2887687c3c614f51c9a)
Identifier: 265870.436 at safari-7616-branch
Commit: cf2f280d1e0cf0d89d865485f56c97c0f59a4202
https://github.com/WebKit/WebKit/commit/cf2f280d1e0cf0d89d865485f56c97c0f59a4202
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M LayoutTests/interaction-region/interaction-layers-culling-expected.txt
M LayoutTests/interaction-region/layer-tree-expected.txt
M LayoutTests/interaction-region/layer-tree.html
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
Log Message:
-----------
Cherry-pick 3f543a9ea04e. rdar://112930285
Cherry-pick 266945 at main (3f543a9ea04e). <rdar://112930285>
Reuse InteractionRegion layers when an element is resized
https://bugs.webkit.org/show_bug.cgi?id=260078
<rdar://112930285>
Reviewed by Tim Horton and Mike Wyrzykowski.
We currently only reuse InteractionRegions layers based on their frame.
This patch adds the ability to reuse layers when an element is resized
or moved.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::setInteractionRegion): Deleted.
(WebKit::setInteractionRegionOcclusion): Deleted.
(WebKit::setInteractionRegionGuard): Deleted.
(WebKit::createInteractionRegionLayer):
Extract the layer creation code in a single function for readability.
(WebKit::configureRemoteEffect):
Extract the remote effect configuration in a function for readibility.
(WebKit::applyBackgroundColorForDebuggingToLayer):
Extract the debug layer configuration to a function for readability.
(WebKit::interactionRegionTypeForLayer):
(WebKit::interactionRegionGroupNameForRegion):
(WebKit::interactionRegionGroupNameForLayer):
(WebKit::isAnyInteractionRegionLayer):
Style fix. Re-order functions.
(WebKit::updateLayersForInteractionRegions):
Keep track of existing layers that are not part of a multi-layer
group effect for reuse.
Move the layer reuse / creation code to a lambda to use early returns
and improve readability. Add the new `groupName` based reuse code path.
Clarify the conditions under which we update properties on the
InteractionRegion layer.
* LayoutTests/interaction-region/layer-tree.html:
Make sure all branches of the `updateLayersForInteractionRegions()` get
exercised during the test.
* LayoutTests/interaction-region/interaction-layers-culling-expected.txt:
* LayoutTests/interaction-region/layer-tree-expected.txt:
Reset and update test expectations (something changed below us).
Canonical link: https://commits.webkit.org/266945@main
(cherry picked from commit aae9d86ed7056b146f5625178842279a458af485)
Identifier: 265870.437 at safari-7616-branch
Commit: a04291c8431c2b6ed7bcc23dc35b349a2c521dc2
https://github.com/WebKit/WebKit/commit/a04291c8431c2b6ed7bcc23dc35b349a2c521dc2
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick ad4d214a77c0. rdar://110354414
[visionOS] Add an internal setting to disable aspect ratio locking in fullscreen
https://bugs.webkit.org/show_bug.cgi?id=259404
rdar://110354414
Reviewed by Tim Nguyen.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController _sceneAspectRatioLockingEnabled]):
(-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
Canonical link: https://commits.webkit.org/266218@main
Identifier: 265423.885 at safari-7616-branch
Commit: 55c8ad6cdfdbdd70e4071bcc0935ffb52d2eccab
https://github.com/WebKit/WebKit/commit/55c8ad6cdfdbdd70e4071bcc0935ffb52d2eccab
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-23 (Wed, 23 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Unreviewed build fix
Identifier: 265870.439 at safari-7616-branch
Commit: 965be685c2ffb1bf77ab5dd1403e85f62268cfe4
https://github.com/WebKit/WebKit/commit/965be685c2ffb1bf77ab5dd1403e85f62268cfe4
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
A JSTests/stress/same-offset-different-property-name-multiple-get-by-variants.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGGraph.cpp
M Source/JavaScriptCore/dfg/DFGGraph.h
Log Message:
-----------
[JSC] DFG AI GetById adhoc folding should insert watchpoints for structures
https://bugs.webkit.org/show_bug.cgi?id=260678
rdar://114072069
Reviewed by Keith Miller.
For DFG AI GetById's variants, they are tuples of StructureSet and offset.
So, we should not obtain constant property just with offset since we first need to
ensure that the base object is having a structure in StructureSet.
Let's say [S0, 0] [S1, 1] variants are produced. In that case, we should not load
a value from offset 1 when object is S0. But previously we were doing that since
only thing we checked is that base is S0 or S1.
This patch just extends DFG AI GetById handling to use existing tryGetConstantProperty
mechanism with StructureSet. This properly inserts replacement watchpoints too, so that
we can guarantee that the loaded value is inferred constant (if it gets different, then
watchpoint fires). And we correctly check that the current object's structure is meeting
the requirement against *variant*'s structure set.
* JSTests/stress/same-offset-different-property-name-multiple-get-by-variants.js: Added.
(main.const.object1):
(main.const.object2):
(main.const.object3):
(main.get opt):
(main):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::inferredValueForProperty):
* Source/JavaScriptCore/dfg/DFGGraph.h:
Canonical link: https://commits.webkit.org/265870.440@safari-7616-branch
Commit: cc3798c31c20a70a72a586822b43c8297d4e85d8
https://github.com/WebKit/WebKit/commit/cc3798c31c20a70a72a586822b43c8297d4e85d8
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.4
Identifier: 265870.441 at safari-7616-branch
Commit: 13af4aba64abd01912891dc232c188f76296c569
https://github.com/WebKit/WebKit/commit/13af4aba64abd01912891dc232c188f76296c569
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Configurations/Sanitizers.xcconfig
M Source/WebGPU/WGSL/wgslc.cpp
M Tools/Scripts/set-webkit-configuration
M Tools/Scripts/webkitdirs.pm
Log Message:
-----------
Cherry-pick 751a8c03a46a. rdar://114455733
[WebGPU] Add the ability to fuzz wgslc
https://bugs.webkit.org/show_bug.cgi?id=259355
rdar://112576959
Reviewed by David Kilzer.
The way this works is:
% set-webkit-configuration --debug --asan --libFuzzer
% cd Source/WebGPU
% make SCHEME=wgslc
% ASAN_OPTIONS=whatever DYLD_FRAMEWORK_PATH=/path/to/Products/Debug DYLD_LIBRARY_PATH=/path/to/Products/Debug /path/to/Products/Debug/wgslc
This patch adds a new configuration option, named "libFuzzer" to WebKit. It sets
the ENABLE_LIBFUZZER Xcode variable, which automatically adds -fsanitize=fuzzer to
compilations. It also sets the ENABLE_LIBFUZZER preprocessor macro, which we can
use to conditionally use LLVMFuzzerTestOneInput() instead of main() if fuzzing is
enabled. Enabling fuzzing also enables ASAN (because of course it does).
* Configurations/Sanitizers.xcconfig:
* Source/WebGPU/WGSL/wgslc.cpp:
(runWGSL):
(LLVMFuzzerTestOneInput):
* Tools/Scripts/set-webkit-configuration:
(printCurrentSettings):
* Tools/Scripts/webkitdirs.pm:
(determineLibFuzzerIsEnabled):
(libFuzzerIsEnabled):
(XcodeOptions):
(generateBuildSystemFromCMakeProject):
Canonical link: https://commits.webkit.org/266202@main
Identifier: 265870.442 at safari-7616-branch
Commit: 47062a251402cfdb428f189ec535950a97c14ec5
https://github.com/WebKit/WebKit/commit/47062a251402cfdb428f189ec535950a97c14ec5
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Makefile.shared
Log Message:
-----------
Cherry-pick 80eedd698f82. rdar://114455833
Add support for `make LIBFUZZER=YES`
https://bugs.webkit.org/show_bug.cgi?id=259369
rdar://112621746
Reviewed by Alex Christensen.
* Makefile.shared:
- Add support for `make LIBFUZZER=YES` and
`make LIBFUZZER=NO`.
Canonical link: https://commits.webkit.org/266593@main
Identifier: 265870.443 at safari-7616-branch
Commit: 6caf041b7b0fc857899bcedb409e7ae856f21d24
https://github.com/WebKit/WebKit/commit/6caf041b7b0fc857899bcedb409e7ae856f21d24
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Configurations/Sanitizers.xcconfig
M Makefile.shared
Log Message:
-----------
Cherry-pick a4d949231543. rdar://114455874
Make it possible to override -fsanitize-coverage flags at build time
https://bugs.webkit.org/show_bug.cgi?id=260079
<rdar://113759381>
Reviewed by Alex Christensen.
* Configurations/Sanitizers.xcconfig:
(WK_SANITIZER_OTHER_LDFLAGS):
- Add -fsanitize-coverage flags to OTHER_LDFAGS to match what
`ENABLE_FUZZER=YES` does for -fno-sanitize-coverage flag.
(WK_LIBFUZZER_COVERAGE): Add.
- Extract default coverage values to a variable to make it possible to
override them.
(WK_LIBFUZZER_OTHER_CFLAGS_YES):
- Add -fsanitize-coverage flag.
- Remove -fno-sanitize-coverage=pc-table as that's already emitted by
clang when ENABLE_LIBFUZZER=YES is set.
(WK_LIBFUZZER_OTHER_LDFLAGS_YES): Add.
- Define -fsanitize-coverage flag for use in WK_SANITIZER_OTHER_LDFLAGS.
* Makefile.shared:
- Add support for `WK_LIBFUZZER_COVERAGE=...` argument.
Canonical link: https://commits.webkit.org/266846@main
Identifier: 265870.444 at safari-7616-branch
Commit: 1d30a3ef70d69e5c4f594270c6aa46fc83b943a3
https://github.com/WebKit/WebKit/commit/1d30a3ef70d69e5c4f594270c6aa46fc83b943a3
Author: Ada Chan <adachan at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/XR/PlatformXRSystem.cpp
M Source/WebKit/UIProcess/XR/PlatformXRSystem.h
Log Message:
-----------
Cherry-pick ce151b92a063. rdar://107913685
Restart XR immersive session foreground activity if needed when process is unsuspended
https://bugs.webkit.org/show_bug.cgi?id=260226
rdar://107913685
Reviewed by Chris Dumez and Dean Jackson.
The "XR immersive session" foreground activity is added when an
XR session starts so the web process has the foreground priority
to do rendering work. That activity gets invalidated when the
process is suspended. So if the process resumes again while an
XR session is still in progress, we need to add that foreground
activity again.
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::setProcessesShouldSuspend):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::restartXRSessionActivityOnProcessResumeIfNeeded):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/XR/PlatformXRSystem.cpp:
(WebKit::PlatformXRSystem::ensureImmersiveSessionActivity):
(WebKit::PlatformXRSystem::initializeTrackingAndRendering):
* Source/WebKit/UIProcess/XR/PlatformXRSystem.h:
Canonical link: https://commits.webkit.org/267097@main
Identifier: 265870.445 at safari-7616-branch
Commit: 9b8d6140bc1543629946ca0352b18d92732f3b89
https://github.com/WebKit/WebKit/commit/9b8d6140bc1543629946ca0352b18d92732f3b89
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Source/WebCore/workers/service/ServiceWorkerTypes.h
M Source/WebCore/workers/service/context/SWContextManager.cpp
M Source/WebCore/workers/service/context/SWContextManager.h
M Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp
M Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.h
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebCore/workers/service/server/SWServer.h
M Source/WebCore/workers/service/server/SWServerToContextConnection.h
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/NetworkProcess.messages.in
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/NetworkSession.h
M Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.cpp
M Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.h
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.h
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/ProvisionalPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebProcessPool.h
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.h
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.messages.in
Log Message:
-----------
Cherry-pick 519e45961292. rdar://108476513
[iOS 17] Remote inspection should be disabled for service workers used only in locked private tabs
https://bugs.webkit.org/show_bug.cgi?id=260400
rdar://108476513
Reviewed by Patrick Angle and Chris Dumez.
Safari 17 introduces the ability to lock tabs in private browsing mode, such that they require some
form of authentication before they're visible to the user. Aside from obscuring the web views, one
of the other (myriad) ways we hide these private tabs is by making them non-web-inspectable, via
`-[WKWebView setInspectable:]`. However, there's currently a corner case where service workers that
are loaded as a part of these locked private browsing tabs will still be inspectable, even if the
page itself is not; this is because service workers are currently _always_ inspectable, regardless
of whether inspection is enabled via web view API.
To address this corner case, we propagate `WKWebView` inspectability over to service workers by
letting a website datastore allow inspection for service workers only if at least one web view using
the data store is inspectable. In practice, because private browsing tabs always use a separate,
ephemeral data stores, making web views in private tabs non-inspectable is equivalent to making any
of their service workers non-inspectable.
At a high level, the inspection state plumbing takes the following route through WebKit:
1. UI Process
↳ `WKWebView`/`WebPageProxy` (source of truth)
↳ `WebsiteDataStore`
↳ `NetworkProcessProxy`
2. Network Process
↳ `NetworkProcess`
↳ `NetworkSession`
↳ `SWServer`
↳ `WebSWServerToContextConnection`
3. Web Process
↳ `WebSWContextManagerConnection`
↳ `SWContextManager`
↳ `ServiceWorkerThreadProxy` (final destination)
* Source/WebCore/workers/service/ServiceWorkerTypes.h:
Add a boolean `enum class ServiceWorkerIsInspectable` so that we can use it in `SWServer` and
adjacent code, so that the last argument to `installContextData` isn't just a plain `bool`.
* Source/WebCore/workers/service/context/SWContextManager.cpp:
(WebCore::SWContextManager::setInspectable):
Iterate over all `ServiceWorkerThreadProxy`s and plumb the updated inspectability state over to each
worker.
* Source/WebCore/workers/service/context/SWContextManager.h:
* Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp:
Take the inspectability state from the given `WebCore::Page`, which should now have an inspection
state that's consistent with the associated service worker.
(WebCore::ServiceWorkerThreadProxy::ServiceWorkerThreadProxy):
(WebCore::ServiceWorkerThreadProxy::setInspectable):
* Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.h:
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::SWServer):
(WebCore::SWServer::contextConnectionCreated):
Plumb initial inspectability state through `SWServer` into the context connection.
(WebCore::SWServer::setInspectable):
Update all context connections when inspectability changes.
* Source/WebCore/workers/service/server/SWServer.h:
* Source/WebCore/workers/service/server/SWServerToContextConnection.h:
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::setInspectionForServiceWorkersAllowed):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/NetworkProcess/NetworkProcess.messages.in:
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::NetworkSession):
(WebKit::NetworkSession::ensureSWServer):
(WebKit::NetworkSession::setInspectionForServiceWorkersAllowed):
* Source/WebKit/NetworkProcess/NetworkSession.h:
* Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.cpp:
(WebKit::NetworkSessionCreationParameters::encode const):
(WebKit::NetworkSessionCreationParameters::decode):
Add a new flag to `NetworkSession`'s creation parameters to indicate whether or not inspection
should be enabled. This is necessary in the case where we avoided sending any inspectability updates
eagerly, in order to avoid needlessly launching the network process.
* Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.h:
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.cpp:
(WebKit::WebSWServerToContextConnection::installServiceWorkerContext):
(WebKit::WebSWServerToContextConnection::setInspectable):
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerToContextConnection.h:
* Source/WebKit/Scripts/webkit/messages.py:
(headers_for_type):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::ProvisionalPageProxy):
(WebKit::ProvisionalPageProxy::~ProvisionalPageProxy):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::setInspectable):
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::pageBeginUsingWebsiteDataStore):
(WebKit::WebProcessPool::pageEndUsingWebsiteDataStore):
Update the data store's set of pages when pages begin or end use; we also adjust these to take
`WebPageProxy&`, so that we can pass them directly into `WebsiteDataStore`.
* Source/WebKit/UIProcess/WebProcessPool.h:
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::addExistingWebPage):
(WebKit::WebProcessProxy::removeWebPage):
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:
Maintain state on each data store, that determines whether or not service workers associated with
that data store should allow inspection. To achieve this, we maintain the set of `m_pages` currently
associated with this data store; whenever pages are added or removed, or when a page changes
inspectability, we recompute inspectability state on the data store and update the network session
if it changes.
(WebKit::WebsiteDataStore::parameters):
(WebKit::WebsiteDataStore::updateServiceWorkerInspectability):
(WebKit::WebsiteDataStore::addPage):
(WebKit::WebsiteDataStore::removePage):
Update `m_pages` when `WebPageProxy`s start or stop using the data store.
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp:
(WebKit::WebSWContextManagerConnection::installServiceWorker):
(WebKit::WebSWContextManagerConnection::setThrottleState):
(WebKit::WebSWContextManagerConnection::setInspectable):
Plumb inspectability state through to `SWContextManager`.
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.h:
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.messages.in:
Canonical link: https://commits.webkit.org/267118@main
Identifier: 265870.446 at safari-7616-branch
Commit: b738520332609eb488845fb4d832a93b3f438648
https://github.com/WebKit/WebKit/commit/b738520332609eb488845fb4d832a93b3f438648
Author: Gerald Squelart <g_squelart at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/cg/UTIRegistry.cpp
M Source/WebCore/platform/network/mac/UTIUtilities.h
M Source/WebCore/platform/network/mac/UTIUtilities.mm
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestUTIRegistry.cpp
A Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestUTIUtilities.cpp
Log Message:
-----------
Cherry-pick b2fab9cbd1d1. rdar://103614570
When adding image support for "com.adobe.photoshop-image", also add MIME type "application/x-photoshop"
https://bugs.webkit.org/show_bug.cgi?id=260464
rdar://103614570
Reviewed by Said Abou-Hallawa.
Mail adds "com.adobe.photoshop-image" as supported type, so that Photoshop images may be viewed as images
in emails. At that time, the associated MIME type "image/vnd.adobe.photoshop" also gets added.
However when inserting an attachment with file extension "psd", the system infers its MIME type as
"application/x-photoshop" instead, which is not supported by default, this prevents psd's from appearing
in the Mail editor.
So when adding "com.adobe.photoshop-image", the MIME type "application/x-photoshop" gets added as well to
correctly show attached psd images.
* Source/WebCore/platform/graphics/cg/UTIRegistry.cpp:
(WebCore::setAdditionalSupportedImageTypes):
* Source/WebCore/platform/network/mac/UTIUtilities.h:
* Source/WebCore/platform/network/mac/UTIUtilities.mm:
(WebCore::RequiredMIMETypesFromUTI):
Note: This 1:M UTI->MIME mapping should be exceedingly rare, so a simple `if` test here is enough.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestUTIRegistry.cpp: Added.
(TestWebKitAPI::TEST):
Relevant tests for this fix, but also a check to know if one day this fix is not needed anymore or needs
an update (e.g., if the platform starts to associate *.psd files with "image/vnd.adobe.photoshop" or
another MIME type).
* Tools/TestWebKitAPI/Tests/WebCore/cocoa/TestUTIUtilities.cpp: Added.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/267153@main
Identifier: 265870.447 at safari-7616-branch
Commit: 04061707df0d5c121a57da41f41409ba22491ce6
https://github.com/WebKit/WebKit/commit/04061707df0d5c121a57da41f41409ba22491ce6
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Source/WTF/wtf/text/TextBreakIterator.h
Log Message:
-----------
Cherry-pick 3e4dfc234c15. rdar://113654067
TextBreakIteratorCache shouldn't be used from worker threads.
https://bugs.webkit.org/show_bug.cgi?id=260498
<rdar://113654067>
Reviewed by David Kilzer.
An alternative here would be to have a cache per-thread, but I'm not aware of an easy way to
store thread local data from WTF currently.
This just skips the cache for non-main threads, and we can consider adding it back as needed
for performance in the future.
* Source/WTF/wtf/text/TextBreakIterator.h:
(WTF::CachedTextBreakIterator::CachedTextBreakIterator):
(WTF::CachedTextBreakIterator::~CachedTextBreakIterator):
Canonical link: https://commits.webkit.org/267175@main
Identifier: 265870.448 at safari-7616-branch
Commit: 28177f10f3157a66ef22ef0508ebfe9b451494d1
https://github.com/WebKit/WebKit/commit/28177f10f3157a66ef22ef0508ebfe9b451494d1
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
Log Message:
-----------
Cherry-pick 346fdad1569d. rdar://112269436
RemoteLayerTreeDrawingAreaProxy needs to hold use-count for IOSurfaces until CA commits.
https://bugs.webkit.org/show_bug.cgi?id=260374
<rdar://112269436>
Reviewed by Simon Fraser.
CoreAnimation doesn't guarantee to have marked the IOSurface as in-use until the transaction is committed, not once the layer mutation happens.
This code was removed in 266557 at main (rdar://111986083) with the belief that it was no longer necessary.
This adds it back, but replaces kCATransactionPhasePostSynchronize with kCATransactionPhasePostCommit.
Waiting for the synchronize phase was a performance regression, and is unnecessary with the latest CoreAnimation, but we
still need to wait for the commit to happen. WebKit doesn't explicitly commit the CoreAnimation transaction, so the implicit
transaction commit might happen significantly later, and we need to ensure that we continue to mark any IOSurfaces as in-use (by
retaining the wrapping mach_port) in the interim.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
Canonical link: https://commits.webkit.org/267204@main
Identifier: 265870.449 at safari-7616-branch
Commit: df24be575b5ae7c46fbc06dae0c516f9336bf139
https://github.com/WebKit/WebKit/commit/df24be575b5ae7c46fbc06dae0c516f9336bf139
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
A LayoutTests/fast/mediastream/stop-clone-when-muted-expected.txt
A LayoutTests/fast/mediastream/stop-clone-when-muted.html
M Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp
M Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.h
M Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp
M Source/WebCore/platform/mediastream/RealtimeMediaSource.h
M Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp
Log Message:
-----------
Cherry-pick fc3228ea6a4e. rdar://111534033
When stopped, a cloned MediaStreamTrack will stop its base MediaStreamTrack if the source is muted
https://bugs.webkit.org/show_bug.cgi?id=260655
rdar://111534033
Reviewed by Eric Carlson.
When we have two track clones, and the tracks are muted, stopping one of the track will end the other one.
This is due to the fact that when stopping a track, we request the source to end.
We then check each observer to know whether they are stopped, which is true when the track is muted.
We are adding a ended flag in UserMediaCaptureManagerProxy::SourceProxy and we rename preventSourceFromStopping in preventSourceFromEnding to clarify what we are doing.
* LayoutTests/fast/mediastream/stop-clone-when-muted-expected.txt: Added.
* LayoutTests/fast/mediastream/stop-clone-when-muted.html: Added.
* Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.cpp:
(WebCore::MediaStreamTrackPrivate::preventSourceFromEnding):
(WebCore::MediaStreamTrackPrivate::preventSourceFromStopping): Deleted.
* Source/WebCore/platform/mediastream/MediaStreamTrackPrivate.h:
* Source/WebCore/platform/mediastream/RealtimeMediaSource.cpp:
(WebCore::RealtimeMediaSource::requestToEnd):
* Source/WebCore/platform/mediastream/RealtimeMediaSource.h:
* Source/WebKit/UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp:
(WebKit::UserMediaCaptureManagerProxy::SourceProxy::end):
(WebKit::UserMediaCaptureManagerProxy::SourceProxy::preventSourceFromEnding):
(WebKit::UserMediaCaptureManagerProxy::SourceProxy::preventSourceFromStopping): Deleted.
Canonical link: https://commits.webkit.org/267247@main
Identifier: 265870.450 at safari-7616-branch
Commit: eb7a5d1be8b5c3c95fc7453850e8b5c765252f64
https://github.com/WebKit/WebKit/commit/eb7a5d1be8b5c3c95fc7453850e8b5c765252f64
Author: Dan Robson <dan_robson at apple.com>
Date: 2023-08-25 (Fri, 25 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
Log Message:
-----------
Revert "Cherry-pick 346fdad1569d. rdar://112269436"
This reverts commit 28177f10f3157a66ef22ef0508ebfe9b451494d1.
Commit: ca4f7c9b9939c77f88fea515ba6059db37d602c3
https://github.com/WebKit/WebKit/commit/ca4f7c9b9939c77f88fea515ba6059db37d602c3
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebCore/platform/graphics/Region.cpp
Log Message:
-----------
WebContent may get killed due to invalid RemoteLayerTreeDrawingAreaProxy_CommitLayerTree IPC message
https://bugs.webkit.org/show_bug.cgi?id=260757
rdar://113860744
Reviewed by Aditya Keerthi.
The fuzzer found a case where the RemoteLayerTreeDrawingAreaProxy_CommitLayerTree
IPC message may fail decoding because its contains an invalid IntRect. After some
investigation, I found that we didn't handle overflows in the arithmetics in
Region::Shape::bounds(), which means that we could end up with an IntRect that
had a negative width or height.
In the fuzzer case, we ended up with the following values:
minX=-2147483648, minY=3, maxX=62, maxY=2306
We would compute the width doing `62 - (-2147483648)` which would overflow and end
up with a negative width. We now use checkedDifference<int32_t>() to detect
overflows and clamp to std::numeric_limits<int32_t>::max() when it happens.
* Source/WebCore/platform/graphics/Region.cpp:
(WebCore::Region::Shape::bounds const):
Canonical link: https://commits.webkit.org/265870.452@safari-7616-branch
Commit: 3dca3ca587f59935bc1740d37113d7f752e35a74
https://github.com/WebKit/WebKit/commit/3dca3ca587f59935bc1740d37113d7f752e35a74
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
A LayoutTests/fast/forms/state-restore-form-associated-custom-elements-2-expected.txt
A LayoutTests/fast/forms/state-restore-form-associated-custom-elements-2.html
M LayoutTests/fast/forms/state-restore-form-associated-custom-elements.html
A LayoutTests/imported/w3c/web-platform-tests/custom-elements/form-associated/ElementInternals-setFormValue-nullish-value-expected.txt
A LayoutTests/imported/w3c/web-platform-tests/custom-elements/form-associated/ElementInternals-setFormValue-nullish-value.html
M Source/WebCore/bindings/js/JSCustomElementInterface.cpp
M Source/WebCore/bindings/js/JSElementInternalsCustom.cpp
M Source/WebCore/dom/ElementInternals.cpp
M Source/WebCore/dom/ElementInternals.h
M Source/WebCore/dom/ElementInternals.idl
M Source/WebCore/html/CustomElementFormValue.h
M Source/WebCore/html/FormAssociatedCustomElement.cpp
M Source/WebCore/html/FormAssociatedCustomElement.h
Log Message:
-----------
Cherry-pick b691e0b9a450. rdar://111802198
ElementInternals.setFormValue(<nullish value>) doesn't clear submission value
https://bugs.webkit.org/show_bug.cgi?id=258870
<rdar://problem/111802198>
Reviewed by Ryosuke Niwa.
With current bindings implementation, given an optional nullish interface / union type without default value,
it's impossible to distiungish in DOM code whether a null / undefined was passed or an argument was missing:
both compile to std::nullopt.
This was causing two bugs in ElementInternals.setFormValue() [1]:
1) nullish `value` parameter was not clearing the submission value;
2) nullish `state` parameter was perceived as missing and the `value` was used instead.
On one hand, we could revise all WebIDL files with optional nullish interface / union types to ensure that
we don't have extra / missing default values (oftentimes we do), and then make ones without defaults values
compile to std::nullopt (for missing argument) / std::nullptr_t (for nullish argument).
On the other, that would be quite massive change and this distinction isn't current needed anywhere but
ElementInternals.setFormValue(), so this change hand-rolls custom bindings just for this method, fixing
both issues by checking argument count and leveraging std::nullptr_t.
[1] https://html.spec.whatwg.org/multipage/custom-elements.html#dom-elementinternals-setformvalue
* LayoutTests/fast/forms/state-restore-form-associated-custom-elements-2-expected.txt: Added.
* LayoutTests/fast/forms/state-restore-form-associated-custom-elements-2.html: Added.
* LayoutTests/fast/forms/state-restore-form-associated-custom-elements.html:
* LayoutTests/imported/w3c/web-platform-tests/custom-elements/form-associated/ElementInternals-setFormValue-nullish-value-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/custom-elements/form-associated/ElementInternals-setFormValue-nullish-value.html: Added.
* Source/WebCore/bindings/js/JSCustomElementInterface.cpp:
(WebCore::JSCustomElementInterface::invokeFormStateRestoreCallback):
* Source/WebCore/bindings/js/JSElementInternalsCustom.cpp:
(WebCore::JSElementInternals::setFormValue):
* Source/WebCore/dom/ElementInternals.cpp:
(WebCore::ElementInternals::setFormValue):
* Source/WebCore/dom/ElementInternals.h:
* Source/WebCore/dom/ElementInternals.idl:
* Source/WebCore/html/CustomElementFormValue.h:
* Source/WebCore/html/FormAssociatedCustomElement.cpp:
(WebCore::FormAssociatedCustomElement::setFormValue):
(WebCore::FormAssociatedCustomElement::appendFormData):
(WebCore::FormAssociatedCustomElement::saveFormControlState const):
* Source/WebCore/html/FormAssociatedCustomElement.h:
Canonical link: https://commits.webkit.org/266126@main
Identifier: 265870.453 at safari-7616-branch
Commit: 079de891b2d2ec7de959ca3e543cad0e5e87caee
https://github.com/WebKit/WebKit/commit/079de891b2d2ec7de959ca3e543cad0e5e87caee
Author: Dana Estra <destra at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
A LayoutTests/http/tests/media/resources/hls/subtitles/verticalrl.vtt
A LayoutTests/http/tests/media/track/track-webvtt-vertical-multi-line-expected.txt
A LayoutTests/http/tests/media/track/track-webvtt-vertical-multi-line.html
M Source/WebCore/html/track/VTTCue.cpp
Log Message:
-----------
Cherry-pick b3d9884a0a16. rdar://112951878
WebVTT vertical multiline captions are cut off
https://bugs.webkit.org/show_bug.cgi?id=260148
rdar://112951878
Reviewed by Eric Carlson.
Currently, vertical webvtt captions (such as Japanese) are not
Displayed correctly on Safari: long cues will get cut off, rather
Than wrapping and displaying multiple lines. This is because the height
Of the div with pseudo-class webkit-media-text-track-display was
Not being calculated with the correct unit. To fix this, I changed
The unit from CQW to CQH.
Added one layout test.
* LayoutTests/http/tests/media/resources/hls/subtitles/verticalrl.vtt: Added.
* LayoutTests/http/tests/media/track/track-webvtt-vertical-multi-line-expected.txt: Added.
* LayoutTests/http/tests/media/track/track-webvtt-vertical-multi-line.html: Added.
* Source/WebCore/html/track/VTTCue.cpp:
(WebCore::VTTCueBox::applyCSSProperties)
Canonical link: https://commits.webkit.org/267162@main
Identifier: 265870.454 at safari-7616-branch
Commit: a7ce30c552ba23e638dab36e7e8a8466815030a4
https://github.com/WebKit/WebKit/commit/a7ce30c552ba23e638dab36e7e8a8466815030a4
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M LayoutTests/interaction-region/interaction-layers-culling-expected.txt
M LayoutTests/interaction-region/layer-tree-expected.txt
A LayoutTests/interaction-region/text-input-expected.txt
A LayoutTests/interaction-region/text-input.html
M Source/WebCore/page/InteractionRegion.cpp
Log Message:
-----------
Cherry-pick c8e296339bfd. rdar://112718594
Go back to using the default bounds for password and search fields' InteractionRegions
https://bugs.webkit.org/show_bug.cgi?id=260466
<rdar://112718594>
Reviewed by Tim Horton.
Remove the old workaround and add a new test so we can do more surgical
tweaks in the future if needed.
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::interactionRegionForRenderedRegion):
Remove the bounds extension for HTMLInputElements.
* LayoutTests/interaction-region/text-input-expected.txt: Added.
* LayoutTests/interaction-region/text-input.html: Added.
Add new test.
* LayoutTests/interaction-region/interaction-layers-culling-expected.txt:
* LayoutTests/interaction-region/layer-tree-expected.txt:
Test update, unrelated.
Canonical link: https://commits.webkit.org/267230@main
Identifier: 265870.455 at safari-7616-branch
Commit: 6ba81c6cd7bb5a266775c29e78929d31e3d8e0c6
https://github.com/WebKit/WebKit/commit/6ba81c6cd7bb5a266775c29e78929d31e3d8e0c6
Author: Kiet Ho <tho22 at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
A LayoutTests/svg/filters/css-filter-specified-on-svg-root-expected.html
A LayoutTests/svg/filters/css-filter-specified-on-svg-root.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/svg/SVGRenderingContext.cpp
Log Message:
-----------
Cherry-pick d4e801ecf045. rdar://114204485
REGRESSION(265135 at main): CSS filter is not applied on SVG element
https://bugs.webkit.org/show_bug.cgi?id=260152
rdar://114204485
Reviewed by Said Abou-Hallawa.
Before 265135 at main, an SVG root with a filter specified as presentation attribute
(e.g: <svg filter="...">) was filtered twice instead of once: once by SVGRenderingContext,
and another by RenderLayer. 265135 at main attempted to fix this by instructing RenderLayer
not to apply filters when rendering an SVG root. This caused a regression where an SVG root
with a filter specified using CSS filter property is not filtered, because SVGRenderingContext
is not responsible for apply CSS filters, and RenderLayer refuses to filter because it's an
SVG root. Fix the previous attempt by fixing SVGRenderingContext to not filter when rendering
an SVG root, so RenderLayer is now solely responsible for filtering SVG roots.
Test: LayoutTests/svg/filters/css-filter-specified-on-svg-root.html
* LayoutTests/svg/filters/css-filter-specified-on-svg-root-expected.html: Added.
* LayoutTests/svg/filters/css-filter-specified-on-svg-root.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintsWithFilters const):
(WebCore::RenderLayer::calculateClipRects const):
* Source/WebCore/rendering/svg/SVGRenderingContext.cpp:
(WebCore::SVGRenderingContext::prepareToRenderSVGContent):
Canonical link: https://commits.webkit.org/267236@main
Identifier: 265870.456 at safari-7616-branch
Commit: cf6f29081b898e6cc3b1264f5e09d7ebf35359ae
https://github.com/WebKit/WebKit/commit/cf6f29081b898e6cc3b1264f5e09d7ebf35359ae
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M LayoutTests/interaction-region/inline-link-expected.txt
M LayoutTests/interaction-region/inline-link.html
M Source/WebCore/page/InteractionRegion.cpp
Log Message:
-----------
Cherry-pick 351891573781. rdar://114215168
Consider HTMLAnchorElements with no href but click event listeners for Interaction Regions
https://bugs.webkit.org/show_bug.cgi?id=260657
<rdar://114215168>
Reviewed by Tim Horton.
HTMLAnchorElements with no `href` don't have the `isLink` flag set. But
we're sitll seeing instances of `<a onclick="...">`.
Since we already have the `EventListenerRegionType::MouseClick` check,
add HTMLAnchorElement to the list of elements that get
InteractionRegions even without `cursor: pointer`.
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::shouldAllowNonPointerCursorForElement):
Add HTMLAnchorElement to the list.
* LayoutTests/interaction-region/inline-link-expected.txt:
* LayoutTests/interaction-region/inline-link.html:
Update the test to cover the "onclick-only" scenario and the scenario
where a link has neither a href nor a click event listener (and doesn't
get a region).
Canonical link: https://commits.webkit.org/267267@main
Identifier: 265870.457 at safari-7616-branch
Commit: d137885842577d487e05ad402eb55589d2414a30
https://github.com/WebKit/WebKit/commit/d137885842577d487e05ad402eb55589d2414a30
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebKit/Shared/WebPreferencesDefaultValues.cpp
Log Message:
-----------
Cherry-pick ff2756001e75. rdar://114270414
Enable ManageMediaSource by default on iPhone
https://bugs.webkit.org/show_bug.cgi?id=260692
rdar://114270414
Reviewed by Youenn Fablet.
Enabled on all cocoa platforms where ENABLE_MEDIA_SOURCE is defined.
* Source/WebKit/Shared/WebPreferencesDefaultValues.cpp:
(WebKit::defaultManagedMediaSourceEnabled):
Canonical link: https://commits.webkit.org/267273@main
Identifier: 265870.458 at safari-7616-branch
Commit: 5ed016205029338fe391282422109b3884f032dd
https://github.com/WebKit/WebKit/commit/5ed016205029338fe391282422109b3884f032dd
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/ThirdParty/libwebrtc/Source/webrtc/p2p/base/tcp_port.cc
Log Message:
-----------
Cherry-pick 277cc3e4b924. rdar://113531400
LibWebRTC TCPConnection might receive packets while its port is nullptr
https://bugs.webkit.org/show_bug.cgi?id=260705
rdar://113531400
Reviewed by Jean-Yves Avenard.
According logs, we have a nullptr crash in Connection::OnReadPacket when calling Port::GetStunMessage.
The current explanation is this one:
1. The connection is live and connected to the socket (which means it is a TCPConnection).
2. The connection's port is dead, which can happen if Port::DestroyConnectionAsync is called.
To prevent the nullptr crash, we add a nullptr check in TCPConnection::OnReadPacket.
* Source/ThirdParty/libwebrtc/Source/webrtc/p2p/base/tcp_port.cc:
Canonical link: https://commits.webkit.org/267275@main
Identifier: 265870.459 at safari-7616-branch
Commit: b8ac6a995a93c65c7e26c4e959bd3757e4059cb6
https://github.com/WebKit/WebKit/commit/b8ac6a995a93c65c7e26c4e959bd3757e4059cb6
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
A LayoutTests/interaction-region/interaction-region-size-limit-expected.txt
A LayoutTests/interaction-region/interaction-region-size-limit.html
M Source/WebCore/page/InteractionRegion.cpp
Log Message:
-----------
Cherry-pick 05a5d83d6847. rdar://114216114
Adjust the size limit for Interaction Regions
https://bugs.webkit.org/show_bug.cgi?id=260659
<rdar://114216114>
Reviewed by Tim Horton.
Tweak the maximum size threshold (relative to the frame area) before we
skip Interaction Regions.
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::interactionRegionForRenderedRegion):
Make the maximum 1/3rd instead of half of the frame area.
* LayoutTests/interaction-region/interaction-region-size-limit-expected.txt: Added.
* LayoutTests/interaction-region/interaction-region-size-limit.html: Added.
Add a test with some mockup UI.
Canonical link: https://commits.webkit.org/267277@main
Identifier: 265870.460 at safari-7616-branch
Commit: 7fc598c3dc2449c58d92ded6b0fee1fad5e2f884
https://github.com/WebKit/WebKit/commit/7fc598c3dc2449c58d92ded6b0fee1fad5e2f884
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebCore/loader/HistoryController.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm
Log Message:
-----------
Cherry-pick 6fb0e85b7be0. rdar://113772385
Back button needs to be pressed twice to go back on https://www.liveilpalazzoapartments.com
https://bugs.webkit.org/show_bug.cgi?id=260682
rdar://113772385
Reviewed by Brent Fulgham.
WebKit normally ignores history entries added by the JavaScript without user
interaction when navigating back or forward.
Here, the site is adding a history entry using `history.pushState()`, without
user interaction but it was incorrectly not getting ignored when navigating
back.
The reason for this is that they are calling `history.pushState()` from a
subframe. Navigations in subframes still create a top-level back/forward
list item. However, we had a bug in HistoryController::pushState() where
we would set the `wasCreatedByJSWithoutUserInteraction` flag on m_currentItem
instead of topItem. topItem and m_currentItem are the same when
`history.pushState()` gets called on the main frame but not in this case.
* Source/WebCore/loader/HistoryController.cpp:
(WebCore::FrameLoader::HistoryController::pushState):
* Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm:
(TEST):
Canonical link: https://commits.webkit.org/267287@main
Identifier: 265870.461 at safari-7616-branch
Commit: 63d50075853598818cdc114a55a00bc23e11e15c
https://github.com/WebKit/WebKit/commit/63d50075853598818cdc114a55a00bc23e11e15c
Author: Gerald Squelart <g_squelart at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
Log Message:
-----------
Cherry-pick 3fe5ba4547a3. rdar://114583816
Ignore willCommitLayerTree and commitLayerTreeNotTriggered when reordered after a commitLayerTree
https://bugs.webkit.org/show_bug.cgi?id=259632
rdar://110498860
Reviewed by Matt Woodrow.
The normal sequence of RemoteLayerTreeDrawingAreaProxy messages should normally be:
willCommit(1) commit(1) notTriggered(next commit 2) willCommit(2) commit(2) ...
However this could be disrupted by RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState, which
waits for the first commit message and runs it immediately! This could lead to handling them in this order:
willCommit(1) commit(1) **commit(2)** notTriggered(next commit 2) willCommit(2) ...
The main issue is that the notTriggered(next commit 2) handler pauses further display refresh callbacks,
which would normally have been restarted by the later-sent commit(2), so the rendering doesn't get updated
anymore. In some applications like Mail, this may result in blank email bodies.
The solution here is to detect such re-orderings, and produce the same effects as if they had run in the
expected order. Details below:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in:
Add `nextCommitTransactionID` to CommitLayerTreeNotTriggered, to know which commit they should
precede (and hence which commit should come after).
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::displayDidRefresh):
Send the next commit transaction ID with CommitLayerTreeNotTriggered.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
Record the last processed CommitLayerTree transaction ID.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTreeNotTriggered):
If this message's next-to-commit transaction ID is lower than or equal to the last-received committed
transaction ID, this means that the commit was reordered and handled before this not-triggered, so nothing
should be done here; especially, display-refresh callbacks should not be paused, and the scrolling update
should happen in the upcoming not-triggered that corresponds to the last-received commit.
This should be rare, so a log message is appropriate to expose this event.
(WebKit::RemoteLayerTreeDrawingAreaProxy::willCommitLayerTree):
Similar to the message above, if the will-commit transaction ID is not smaller than the last-received
committed transaction ID, it means that this message was reordered and can be ignored. Its effect would
have already been handled by the commit message (see below.)
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTreeTransaction):
Update the last processed transaction ID.
Also, if the pending transaction ID is lower than this commit's transaction ID, it means this message is
being preemptively handled sooner, so the will-commit effect is simulated by updating the pending
transaction ID now -- the already sent will-commit will be ignored later on.
Canonical link: https://commits.webkit.org/266421@main
Identifier: 265870.462 at safari-7616-branch
Commit: f255dd40b82e82b5fd244f074a027c3bf7a9a0d3
https://github.com/WebKit/WebKit/commit/f255dd40b82e82b5fd244f074a027c3bf7a9a0d3
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp
M Source/WebCore/Modules/mediarecorder/MediaRecorder.h
Log Message:
-----------
CRASH in MediaRecorderPrivate::startRecording()
https://bugs.webkit.org/show_bug.cgi?id=260736
rdar://113544631
Reviewed by Brent Fulgham and Eric Carlson.
MediaRecorder can be destroyed before the completion handler passed to
MediaRecorderPrivate::startRecording() is called. Detect this state by
passing a WeakPtr into the completion handler lambda. Because MediaRecoder
has multiple base classes which are CanMakeWeakPtr subclasses, disambiguate
which subclass's WeakPtr implementation to use in the MediaRecoder class
declaration.
* Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp:
(WebCore::MediaRecorder::startRecording):
* Source/WebCore/Modules/mediarecorder/MediaRecorder.h:
Canonical link: https://commits.webkit.org/265870.463@safari-7616-branch
Commit: 577da64ec9fb6ed048aee76424ac6dcfd372294c
https://github.com/WebKit/WebKit/commit/577da64ec9fb6ed048aee76424ac6dcfd372294c
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
A LayoutTests/accessibility/editable-webpage-focused-ui-element-expected.txt
A LayoutTests/accessibility/editable-webpage-focused-ui-element.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
Log Message:
-----------
Cherry-pick 30959c84f8ab. rdar://114590398
AX: NSApplicationAccessibilityFocusedUIElement is sometimes an ignored object which breaks functionality for Voice Control in Mail
https://bugs.webkit.org/show_bug.cgi?id=260191
rdar://113689647
Reviewed by Andres Gonzalez.
Mail uses WebPage::setEditable(true) (indirectly through IPC) to make
the entire webpage of a Mail compose window be editable. One side-effect
of this is that the `body` element gains focus.
In https://bugs.webkit.org/show_bug.cgi?id=257739, we made the
assumption that any focused object is inherently unignored by way of
having focus, and removed this code from AXObjectCache::focusedObjectForNode:
if (focus->accessibilityIsIgnored())
return focus->parentObjectUnignored();
This bug reveals two pieces of information:
1. Our assumption (any focused object is inherently unignored) is
wrong, as the AXGroup associated with the `body` is ignored despite
it being focused
2. Even if this assumption were true, we would still experience the
bug, as Voice Control very specifically expects the web area to be
focused when editing a Mail message (arguably a Voice Control bug
that should be addressed later)
With this patch, we restore the above check to AXObjectCache::focusedObjectForNode,
restoring behavior for Voice Control. We may want to re-evaluate this again in the
future, as our original assumption still seems sound but clearly has some kinks that
need working out.
* LayoutTests/accessibility/editable-webpage-focused-ui-element-expected.txt: Added.
* LayoutTests/accessibility/editable-webpage-focused-ui-element.html: Added.
* LayoutTests/platform/glib/TestExpectations: Disable new test.
* LayoutTests/platform/ios/TestExpectations: Enable new test.
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::focusedObjectForNode):
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::setSelectionFromNone):
* Source/WebCore/testing/Internals.h:
* Source/WebCore/testing/Internals.idl:
Canonical link: https://commits.webkit.org/266917@main
Identifier: 265870.464 at safari-7616-branch
Commit: f8cff95a0630f3ba92092ad3acdfeb3ede040270
https://github.com/WebKit/WebKit/commit/f8cff95a0630f3ba92092ad3acdfeb3ede040270
Author: Megan Gardner <megan_gardner at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick 2b3d23d7e6dd. rdar://113862387
When crossing window boundries on visionOS drops animate from the wrong origin.
https://bugs.webkit.org/show_bug.cgi?id=260728
rdar://113862387
Reviewed by Aditya Keerthi and Wenson Hsieh
To cross window boundaries, we need to convert to coordinate spaces instead of
just to the view.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView dropInteraction:previewForDroppingItem:withDefault:]):
Canonical link: https://commits.webkit.org/267308@main
Identifier: 265870.465 at safari-7616-branch
Commit: 1f929406b48f58c2d3170a8116c93400f57034ac
https://github.com/WebKit/WebKit/commit/1f929406b48f58c2d3170a8116c93400f57034ac
Author: Dean Jackson <dino at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick 6082b4aaed9f. rdar://114412655
Interaction: When using media controls in full screen, Safari thinks we're trying to type.
https://bugs.webkit.org/show_bug.cgi?id=260754
rdar://114412655
Reviewed by Richard Robinson.
visionOS is popping up the potential phishing alert when you tap
around in the fullscreen media controls. This platform has a virtual
keyboard, but it is always in a separate window, so we don't need
the phishing protection. Turn it off for visionOS.
I left a FIXME saying it would be better to have this feature
controlled globally with a USE or HAVE.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _shouldAvoidSecurityHeuristicScoreUpdates]):
Canonical link: https://commits.webkit.org/267329@main
Identifier: 265870.466 at safari-7616-branch
Commit: 1f9e212406630ec8e5648654ba3af8d7ba40ee34
https://github.com/WebKit/WebKit/commit/1f9e212406630ec8e5648654ba3af8d7ba40ee34
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-08-28 (Mon, 28 Aug 2023)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
CloneDeserializer::readBigInt() should check for overflow when reifying JSBigInt length on 32-bit platforms.
https://bugs.webkit.org/show_bug.cgi?id=260822
rdar://114547822
Reviewed by Chris Dumez.
The serialized length is a number of Uint64 elements. On 32-bit platforms, this length gets multiplied by 2 in
order to compute the actual length of the backing store to re-construct the JSBigInt. Both the transmitted length
and the JSBigInt length is stored as uint32_t. Hence, the 2x multiplication can theoretically result in an
overflow. This patch adds an overflow check to handle this edge case.
Also renamed lengthInUint64 to numberOfUint64Elements. lengthInUint64 can be misread to mean a length stored as a
uint64_t value, which is not what it actually means. The length value is store in a uint32_t, and is a count of
the number of uint64_t sized elements.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneSerializer::dumpHeapBigIntData):
(WebCore::CloneDeserializer::readBigInt):
Canonical link: https://commits.webkit.org/265870.467@safari-7616-branch
Commit: e82f2fb01b9776173e3ba9863d8dd417066dd10c
https://github.com/WebKit/WebKit/commit/e82f2fb01b9776173e3ba9863d8dd417066dd10c
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Source/WebKit/CMakeLists.txt
M Source/WebKit/DerivedSources-input.xcfilelist
M Source/WebKit/DerivedSources.make
A Source/WebKit/Shared/GoToBackForwardItemParameters.h
A Source/WebKit/Shared/GoToBackForwardItemParameters.serialization.in
M Source/WebKit/UIProcess/ProvisionalPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
Log Message:
-----------
Cherry-pick 6c6b1e0f4c36. rdar://103697846
Safari can't open the page when navigating back from a remote HTTP URL to a local html file
https://bugs.webkit.org/show_bug.cgi?id=260504
rdar://103697846
Reviewed by Brent Fulgham.
When calling loadFile on a WKWebView, we create a sandbox extension in the UIProcess
and send it to the WebProcess. In turn the WebProcess uses this to create a temporary
extension for the network process.
Without this, sandboxed apps such as Safari would be unable to load such local files.
When doing a back/forward navigation to a history item for a file URL, we often get
lucky and load the page from the back/forward cache.
However, if the page was evicted from the cache (or wasn't cached in the first place),
we end up using a fresh new process for the navigation. However, we were not issuing
a sandbox extension and the load would fail.
To address the issue, we now create a sandbox extension in
ProvisionalPageProxy::goToBackForwardItem(), whenever we process-swap on back/forward
navigation to a file URL.
Note that Cocoa ports are only able to create sandbox extensions once the process has
finished launching (and we have its PID). As a result, the call to
maybeInitializeSandboxExtensionHandle() may fail when calling ProvisionalPageProxy::goToBackForwardItem()
if the process is still launching. In this case, the sandbox extension gets created
later on, when the process has finished launching and we're sending the queued IPC.
This is the exact same approach that we were using for WebPage::LoadRequest, but I
am now applying it to WebPage::GoToBackForwardItem IPC too. If the process is not
done launching, we send a WebPage::GoToBackForwardItemWaitingForProcessLaunch IPC
instead, which gets handled in WebProcessProxy::shouldSendPendingMessage(), similarly
to WebPage::LoadRequestWaitingForProcessLaunch. At this point, we create the sandbox
extensions and convert the IPC message into a regular WebPage::GoToBackForwardItem
one.
To simplify the code, I moved all the parameters for the WebPage::GoToBackForwardItem
IPC to a new GoToBackForwardItemParameters structure with its generated IPC coders.
I also added the new sandbox extension handle to this structure.
* Source/WebKit/CMakeLists.txt:
* Source/WebKit/DerivedSources-input.xcfilelist:
* Source/WebKit/DerivedSources.make:
* Source/WebKit/Shared/GoToBackForwardItemParameters.h: Added.
* Source/WebKit/Shared/GoToBackForwardItemParameters.serialization.in: Added.
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::goToBackForwardItem):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::launchProcessForReload):
(WebKit::WebPageProxy::goToBackForwardItem):
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::shouldSendPendingMessage):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::goToBackForwardItem):
(WebKit::WebPage::goToBackForwardItemWaitingForProcessLaunch):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
Canonical link: https://commits.webkit.org/267199@main
Identifier: 265870.468 at safari-7616-branch
Commit: fe10437bafcd423d31912cb3d49205b56775cc89
https://github.com/WebKit/WebKit/commit/fe10437bafcd423d31912cb3d49205b56775cc89
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick b938895dd213. rdar://114049859
[visionOS] Fullscreen windows do not cast shadows
https://bugs.webkit.org/show_bug.cgi?id=260620
rdar://114049859
Reviewed by Richard Robinson and Tim Horton.
Adopt UIKit SPI to add a grounding shadow to the fullscreen window. The
fullscreen window does not get a shadow by default since it's not platter-backed.
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController enterFullScreen:]):
Canonical link: https://commits.webkit.org/267201@main
Identifier: 265870.469 at safari-7616-branch
Commit: 150f27e1b3cbd2c8926660db5a2b1e29d3877935
https://github.com/WebKit/WebKit/commit/150f27e1b3cbd2c8926660db5a2b1e29d3877935
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Source/WebCore/css/parser/CSSSelectorParser.cpp
M Source/WebCore/css/parser/CSSSelectorParser.h
Log Message:
-----------
Cherry-pick 727dbe30fe5f. rdar://114287946
fast/dom/selectorAPI/caseID.html is a constant text failure (when repro steps are followed).
https://bugs.webkit.org/show_bug.cgi?id=260556
rdar://114287946
Reviewed by Antti Koivisto.
The CSSSelectorParserContext's operator==() was wrong, it was using `||` instead
of `&&` between the data member checks. Fix the issue by using the default
operator==().
* LayoutTests/TestExpectations:
* Source/WebCore/css/parser/CSSSelectorParser.cpp:
(WebCore::CSSSelectorParserContext::operator== const): Deleted.
Canonical link: https://commits.webkit.org/267237@main
Identifier: 265870.470 at safari-7616-branch
Commit: 9e90860f3f08c4b9d90e40cbfceda044a7c86202
https://github.com/WebKit/WebKit/commit/9e90860f3f08c4b9d90e40cbfceda044a7c86202
Author: Ryan Reno <rreno at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M LayoutTests/http/tests/security/referrer-policy-header.html
Log Message:
-----------
Cherry-pick d4d875b3f050. rdar://114349670
REGRESSION(266644 at main): [wk2] http/tests/security/referrer-policy-header.html is a flaky text failure, crash
https://bugs.webkit.org/show_bug.cgi?id=260632
rdar://114349670
Reviewed by Brent Fulgham.
This test wasn't waiting for completion of the iframe loads in order to
determine what the referrer was given a referrer policy. There were two
problems: one was I mistakenly added an extra call to runTests so we
were running synchronously once. The other problem was we weren't
telling the test runner to wait until we were finished loading the
iframe and receiving the messages from it with the results. The former
led to flaky results and the latter led to flaky crashes.
* LayoutTests/http/tests/security/referrer-policy-header.html:
* LayoutTests/platform/wk2/TestExpectations:
Canonical link: https://commits.webkit.org/267241@main
Identifier: 265870.471 at safari-7616-branch
Commit: df6e0a090f486ecac128ff3280fb2d48c09c2300
https://github.com/WebKit/WebKit/commit/df6e0a090f486ecac128ff3280fb2d48c09c2300
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
A LayoutTests/media/media-can-play-case-sensitive-flac-expected.txt
A LayoutTests/media/media-can-play-case-sensitive-flac.html
A LayoutTests/media/media-can-play-type-case-sensitive-expected.txt
A LayoutTests/media/media-can-play-type-case-sensitive.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/MIMETypeRegistry.cpp
M Source/WebCore/platform/MIMETypeRegistry.h
M Source/WebCore/platform/graphics/MIMETypeCache.cpp
M Source/WebCore/platform/graphics/MIMETypeCache.h
M Source/WebCore/platform/graphics/MediaPlayer.cpp
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h
M Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.h
M Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm
M Source/WebCore/platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h
M Source/WebCore/platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.h
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.h
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/mse/GStreamerRegistryScannerMSE.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/GStreamerRegistryScannerMSE.h
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h
M Source/WebCore/platform/graphics/holepunch/MediaPlayerPrivateHolePunch.cpp
M Source/WebCore/platform/graphics/holepunch/MediaPlayerPrivateHolePunch.h
M Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.cpp
M Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.h
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerMIMETypeCache.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerMIMETypeCache.h
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.h
M Source/WebKitLegacy/mac/WebView/WebHTMLRepresentation.mm
Log Message:
-----------
Cherry-pick 73b6e9fe2ab4. rdar://114276660
REGRESSION (Safari 17 beta): [MSE] Can no longer play .FLAC inside MP4
https://bugs.webkit.org/show_bug.cgi?id=260491
rdar://114276660
Reviewed by Eric Carlson.
In iOS 17 and macOS Sonoma, -[AVURLAsset isPlayableExtendedMIMEType:] is much more restrictive when
reporting which codec types are supported. Previously, any CoreMedia FourCC code was listed as
playable when paired with an ISO BMFF container type such as "video/mp4". Now, only those codec
strings listed with the MP4 registration authority are considered valid. Since the official MP4RA
string for the Flac audio codec is "fLaC", this means that whereas `audio/mp4; codecs="flac"` would
previously succeed, those queries will now fail.
While it is technically "correct" to reject the "flac" codec string when paired with ISO BMFF, there
are a number of pages which are currently broken due to this change, so transform "flac" to "fLaC"
at the WebCore layer.
Additionally, while MIME container types are case-insensitive, the codec parameters on those
container types are case-sensitive, so every Hash container where WebKit caches media MIME types
must be changed from ASCIICaseInsensitiveHash to the default StringHash. This prevents both false
positives and false negatives if the correct or incorrectly-cased versions are queried first.
* LayoutTests/media/media-can-play-case-sensitive-flac-expected.txt: Added.
* LayoutTests/media/media-can-play-case-sensitive-flac.html: Added.
* LayoutTests/media/media-can-play-type-case-sensitive-expected.txt: Added.
* LayoutTests/media/media-can-play-type-case-sensitive.html: Added.
* Source/WebCore/platform/MIMETypeRegistry.cpp:
(WebCore::MIMETypeRegistry::supportedMediaMIMETypes):
* Source/WebCore/platform/MIMETypeRegistry.h:
* Source/WebCore/platform/graphics/MIMETypeCache.cpp:
(WebCore::MIMETypeCache::supportedTypes):
(WebCore::MIMETypeCache::canDecodeType):
(WebCore::MIMETypeCache::addSupportedTypes):
(WebCore::MIMETypeCache::initializeCache):
* Source/WebCore/platform/graphics/MIMETypeCache.h:
* Source/WebCore/platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::getSupportedTypes):
* Source/WebCore/platform/graphics/MediaPlayer.h:
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::staticMIMETypeList):
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
* Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.h:
* Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:
(WebCore::AVAssetMIMETypeCache::canDecodeExtendedType):
(WebCore::AVAssetMIMETypeCache::initializeCache):
* Source/WebCore/platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h:
* Source/WebCore/platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.mm:
(WebCore::AVStreamDataParserMIMETypeCache::supportedTypes):
(WebCore::AVStreamDataParserMIMETypeCache::initializeCache):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::getSupportedTypes):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::getSupportedTypes):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::getSupportedTypes):
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.h:
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm:
(WebCore::mimeTypeCache):
(WebCore::MediaPlayerPrivateWebM::getSupportedTypes):
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp:
(WebCore::mimeTypeCache):
(WebCore::MockMediaPlayerMediaSource::getSupportedTypes):
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp:
(WebKit::RemoteMediaPlayerManagerProxy::getSupportedTypes):
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerMIMETypeCache.cpp:
(WebKit::RemoteMediaPlayerMIMETypeCache::supportedTypes):
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerMIMETypeCache.h:
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.cpp:
(WebKit::RemoteMediaPlayerManager::getSupportedTypes):
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.h:
* Source/WebKitLegacy/mac/WebView/WebHTMLRepresentation.mm:
(createNSArray): Deleted.
Canonical link: https://commits.webkit.org/267250@main
Identifier: 265870.472 at safari-7616-branch
Commit: a34bc252d5bb7da77572b82a94f3929617504297
https://github.com/WebKit/WebKit/commit/a34bc252d5bb7da77572b82a94f3929617504297
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Source/WebCore/Modules/mediasource/MediaSource.cpp
M Source/WebCore/Modules/mediasource/MediaSource.h
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/Modules/mediasource/SourceBuffer.h
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/platform/graphics/MediaPlayer.cpp
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebCore/platform/graphics/MediaPlayerPrivate.h
M Source/WebCore/platform/graphics/MediaSourcePrivate.h
M Source/WebCore/platform/graphics/MediaSourcePrivateClient.h
M Source/WebCore/platform/graphics/SourceBufferPrivate.cpp
M Source/WebCore/platform/graphics/SourceBufferPrivate.h
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.h
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h
M Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.h
M Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.cpp
M Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.h
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.h
M Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.h
M Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.cpp
M Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.messages.in
M Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.h
M Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.messages.in
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.h
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.messages.in
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h
M Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.h
M Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.messages.in
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.h
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.serialization.in
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.h
Log Message:
-----------
Cherry-pick ee5de7a0c1f2. rdar://113881009
REGRESSION(262173 at main): media/media-source/media-source-fastseek.html is a flaky text failure
https://bugs.webkit.org/show_bug.cgi?id=260185
rdar://113881009
Reviewed by Youenn Fablet.
fastSeek and normal Seek followed different paths and the flow between
GPU process and content process was disconnected. This leads to a racy
behaviour where the HTMLMediaElement in the content process could assume
that the seek operation in the GPU process had completed when it hadn't.
There's been a few workarounds put in place for this problem but none
fixed the core issue: we can only complete the seek operation once the
media source has received all the data and we must wait rather than
expect the player to keep retrying.
fastSeek time target calculation was also left to each of the MediaPlayerPrivate
to handle.
This change move part of the seek operation back to the content process,
where the MediaSource element will ensure that there is data to continue
the seek.
It will also handle the fastSeek calculation.
Once the MediaSource has seeked each of the SourceBuffer and has determined
the final time destination, a CompletionHandler will be resolved with the
exact to seeked to location. From that point, each MediaPlayerPrivate can
resume the seek operation and once complete notify the HTMLMediaElement so
that it can fire the appropriate events.
This also gets us closer to having the handling of the SourceBuffer's content
back to the content process, so that all unsafe demuxing operations can
be performed there.
In this change, the various seek methods (from float, double, MediaTime),
accurate and fast are combined into a single seekToTarget with a new
SeekTarget object that can be used for all types.
We remove the need for SourceBufferPrivate and MediaSourcePrivate's having
to track if it is currently seeking or not and the need for
waitForSeekCompleted/willSeek/seekCompleted calls.
Platform specific changes:
- MediaPlayerPrivateMediaSourceAVFObjC: the seeking internal logic was broken.
m_synchronizerSeeking which is supposed to monitor the AVSampleBufferRenderSynchronizer
seeking state was always set to false. As such, we would fire the timeupdate/seeked event even
before the proper frame was displayed and the new time was set.
This likely explains several intermittent failures with video reftest.
- MediaPlayerPrivateGStreamerMSE: The structure of the code doesn’t permit an easy migration
to the new asynchronous flow. This is tracked in bug 260607 to be done at a later stage.
Covered by existing tests.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::MediaSource):
(WebCore::MediaSource::currentTime const):
(WebCore::MediaSource::seekToTarget):
(WebCore::MediaSource::completeSeek):
(WebCore::MediaSource::monitorSourceBuffers):
(WebCore::MediaSource::detachFromElement):
(WebCore::MediaSource::seekToTime): Deleted.
* Source/WebCore/Modules/mediasource/MediaSource.h:
(WebCore::MediaSource::isSeeking const):
* Source/WebCore/Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::seekToTarget):
(WebCore::SourceBuffer::seekToTime): Deleted.
* Source/WebCore/Modules/mediasource/SourceBuffer.h:
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::setReadyState):
(WebCore::HTMLMediaElement::fastSeek):
(WebCore::HTMLMediaElement::seek):
(WebCore::HTMLMediaElement::seekInternal):
(WebCore::HTMLMediaElement::seekWithTolerance):
(WebCore::HTMLMediaElement::seekTask):
(WebCore::HTMLMediaElement::setCurrentTimeWithTolerance):
* Source/WebCore/html/HTMLMediaElement.h:
(WebCore::HTMLMediaElement::PendingSeek::PendingSeek):
* Source/WebCore/platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::seekToTarget):
(WebCore::MediaPlayer::seekToTime):
(WebCore::MediaPlayer::seekWhenPossible):
(WebCore::MediaPlayer::readyStateChanged):
(WebCore::SeekTarget::toString const):
(WebCore::MediaPlayer::seekWithTolerance): Deleted.
(WebCore::MediaPlayer::seek): Deleted.
* Source/WebCore/platform/graphics/MediaPlayer.h:
(WebCore::SeekTarget::SeekTarget):
(WebCore::SeekTarget::zero):
(WTF::LogArgument<WebCore::SeekTarget>::toString):
* Source/WebCore/platform/graphics/MediaPlayerPrivate.h:
(WebCore::MediaPlayerPrivateInterface::hasClosedCaptions const):
(WebCore::MediaPlayerPrivateInterface::seek): Deleted.
(WebCore::MediaPlayerPrivateInterface::seekDouble): Deleted.
(WebCore::MediaPlayerPrivateInterface::seekWithTolerance): Deleted.
* Source/WebCore/platform/graphics/MediaSourcePrivate.h:
(WebCore::MediaSourcePrivate::setIsSeeking): Deleted.
(WebCore::MediaSourcePrivate::isSeeking const): Deleted.
* Source/WebCore/platform/graphics/MediaSourcePrivateClient.h:
* Source/WebCore/platform/graphics/SourceBufferPrivate.cpp:
(WebCore::SourceBufferPrivate::seekToTarget):
(WebCore::SourceBufferPrivate::fastSeekTimeForMediaTime): Deleted.
* Source/WebCore/platform/graphics/SourceBufferPrivate.h:
(WebCore::SourceBufferPrivate::setMaximumQueueDepthForTrackID):
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::seekToTarget):
(WebCore::MediaPlayerPrivateAVFoundation::seek): Deleted.
(WebCore::MediaPlayerPrivateAVFoundation::seekWithTolerance): Deleted.
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::seekToTargetInternal):
(WebCore::MediaPlayerPrivateAVFoundationObjC::seekToTime): Deleted.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::PendingSeek::PendingSeek): Deleted.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::convertEnumerationToString):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::MediaPlayerPrivateMediaSourceAVFObjC):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekToTarget):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekInternal):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekCompleted):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seeking const):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::setHasAvailableVideoFrame):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekWithTolerance): Deleted.
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::waitForSeekCompleted): Deleted.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm:
(WebCore::MediaSourcePrivateAVFObjC::seekToTarget):
(WebCore::MediaSourcePrivateAVFObjC::waitForSeekCompleted): Deleted.
(WebCore::MediaSourcePrivateAVFObjC::seekCompleted): Deleted.
(WebCore::MediaSourcePrivateAVFObjC::seekToTime): Deleted.
(WebCore::MediaSourcePrivateAVFObjC::fastSeekTimeForMediaTime): Deleted.
* Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.h:
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm:
(WebCore::MediaPlayerPrivateWebM::play):
(WebCore::MediaPlayerPrivateWebM::seekToTarget):
(WebCore::MediaPlayerPrivateWebM::seek): Deleted.
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::MediaPlayerPrivateGStreamer):
(WebCore::MediaPlayerPrivateGStreamer::play):
(WebCore::MediaPlayerPrivateGStreamer::doSeek):
(WebCore::MediaPlayerPrivateGStreamer::seekToTarget):
(WebCore::MediaPlayerPrivateGStreamer::updatePlaybackRate):
(WebCore::MediaPlayerPrivateGStreamer::currentMediaTime const):
(WebCore::MediaPlayerPrivateGStreamer::playbackPosition const):
(WebCore::MediaPlayerPrivateGStreamer::finishSeek):
(WebCore::MediaPlayerPrivateGStreamer::updateStates):
(WebCore::MediaPlayerPrivateGStreamer::seek): Deleted.
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::seekToTarget):
(WebCore::MediaPlayerPrivateGStreamerMSE::doSeek):
(WebCore::MediaPlayerPrivateGStreamerMSE::seek): Deleted.
* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h:
* Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.cpp:
(WebCore::MediaSourcePrivateGStreamer::seekToTarget):
(WebCore::MediaSourcePrivateGStreamer::seekCompleted): Deleted.
* Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.h:
* Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.cpp:
(WebCore::SourceBufferPrivateGStreamer::isSeeking const): Deleted.
* Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.h:
* Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.cpp:
(WebCore::MediaPlayerPrivateMediaFoundation::seekToTarget):
(WebCore::MediaPlayerPrivateMediaFoundation::seek): Deleted.
* Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.h:
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp:
(WebCore::MockMediaPlayerMediaSource::seekToTarget):
(WebCore::MockMediaPlayerMediaSource::seekWithTolerance): Deleted.
(WebCore::MockMediaPlayerMediaSource::waitForSeekCompleted): Deleted.
(WebCore::MockMediaPlayerMediaSource::seekCompleted): Deleted.
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.h:
(WebCore::MockMediaPlayerMediaSource::mediaPlayerLogIdentifier): Deleted.
(WebCore::MockMediaPlayerMediaSource::mediaPlayerLogger): Deleted.
* Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.cpp:
(WebCore::MockMediaSourcePrivate::seekToTarget):
(WebCore::MockMediaSourcePrivate::waitForSeekCompleted): Deleted.
(WebCore::MockMediaSourcePrivate::seekCompleted): Deleted.
(WebCore::MockMediaSourcePrivate::seekToTime): Deleted.
* Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.h:
* Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.cpp:
(WebCore::MockSourceBufferPrivate::isSeeking const): Deleted.
* Source/WebCore/platform/mock/mediasource/MockSourceBufferPrivate.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp:
(WebKit::RemoteMediaPlayerProxy::seekToTarget):
(WebKit::RemoteMediaPlayerProxy::updateCachedState):
(WebKit::RemoteMediaPlayerProxy::seek): Deleted.
(WebKit::RemoteMediaPlayerProxy::seekWithTolerance): Deleted.
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.messages.in:
* Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.cpp:
(WebKit::RemoteMediaSourceProxy::seekToTarget):
(WebKit::RemoteMediaSourceProxy::seekToTime): Deleted.
(WebKit::RemoteMediaSourceProxy::setIsSeeking): Deleted.
(WebKit::RemoteMediaSourceProxy::waitForSeekCompleted): Deleted.
(WebKit::RemoteMediaSourceProxy::seekCompleted): Deleted.
* Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.h:
* Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.messages.in:
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.cpp:
(WebKit::RemoteSourceBufferProxy::seekToTarget):
(WebKit::RemoteSourceBufferProxy::seekToTime): Deleted.
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.h:
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.messages.in:
* Source/WebKit/Scripts/webkit/messages.py:
(headers_for_type):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:
(WebKit::MediaPlayerPrivateRemote::seekToTarget):
(WebKit::MediaPlayerPrivateRemote::timeChanged):
(WebKit::MediaPlayerPrivateRemote::seeking const):
(WebKit::MediaPlayerPrivateRemote::seek): Deleted.
(WebKit::MediaPlayerPrivateRemote::seekWithTolerance): Deleted.
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h:
* Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.cpp:
(WebKit::MediaSourcePrivateRemote::seekToTarget):
(WebKit::MediaSourcePrivateRemote::setIsSeeking): Deleted.
(WebKit::MediaSourcePrivateRemote::waitForSeekCompleted): Deleted.
(WebKit::MediaSourcePrivateRemote::seekCompleted): Deleted.
(WebKit::MediaSourcePrivateRemote::seekToTime): Deleted.
* Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.h:
* Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.messages.in:
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.h:
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.serialization.in:
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.cpp:
(WebKit::SourceBufferPrivateRemote::seekToTarget):
(WebKit::SourceBufferPrivateRemote::seekToTime): Deleted.
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.h:
Canonical link: https://commits.webkit.org/267279@main
Identifier: 265870.473 at safari-7616-branch
Commit: 4a89fd75218f3f897b7cc5112bb52c3bf186c960
https://github.com/WebKit/WebKit/commit/4a89fd75218f3f897b7cc5112bb52c3bf186c960
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Source/WebCore/Configurations/WebCore.xcconfig
Log Message:
-----------
Cherry-pick 028e6dbdd9c6. rdar://114653694
Unreviewed, fix the libnetcore build after 266789 at main
https://bugs.webkit.org/show_bug.cgi?id=260024
Link against Network.framework to avoid missing symbols on tvOS; this doesn't affect macOS or other
iOS-family platforms, since we link against NetworkExtension already in WebCore.
* Source/WebCore/Configurations/WebCore.xcconfig:
Canonical link: https://commits.webkit.org/266834@main
Canonical link: https://commits.webkit.org/265870.474@safari-7616-branch
Commit: 48fc6ac7af9e1b733fefae2df106c7c274047383
https://github.com/WebKit/WebKit/commit/48fc6ac7af9e1b733fefae2df106c7c274047383
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.5
Canonical link: https://commits.webkit.org/265870.475@safari-7616-branch
Commit: 5cfdf9b1cbac2ff7ef71f1aaaf633347010f8018
https://github.com/WebKit/WebKit/commit/5cfdf9b1cbac2ff7ef71f1aaaf633347010f8018
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Source/WebCore/html/HTMLInputElement.cpp
M Source/WebCore/html/HTMLInputElement.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/Shared/FocusedElementInformation.h
M Source/WebKit/Shared/FocusedElementInformation.serialization.in
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm
M Tools/TestWebKitAPI/ios/UIKitSPI.h
Log Message:
-----------
[iOS] Keyboard should not learn autocorrections after revealing password in Gmail login flow
https://bugs.webkit.org/show_bug.cgi?id=260864
rdar://111393742
Reviewed by Aditya Keerthi.
When focusing and editing secure inputs (i.e. input type="password"), we set `isSecureTextEntry` on
`UITextInputTraits` to `YES`, which disables autocorrection learning when the user types in this
field, suppresses the keyboard in screen recordings, and more.
However, some webpages (e.g. Gmail login) offer the ability to reveal the password as plain text as
a convenience to the user — this typically works by changing the input type from `"password"` to
just `"text"`. This currently causes all of the secure text entry behaviors to be disabled, which
includes disabling correction learning; this is undesirable, since the password may be offered as an
autocorrection candidate when editing in other plain text fields in the future, in non-secure
contexts.
Because the user opted to reveal the input, it doesn't really make sense to treat the input as fully
secure (for instance, there's no reason to suppress keyboard visibility in screen recordings if the
password text itself is fully visible). However, we need to (at least) prevent the keyboard from
learning suggestions when typing in this field. To achieve this, we add a flag on `HTMLInputElement`
to remember whether it was ever a password field; if so, we set the `-learnsCorrections` property on
text input traits to `NO`.
Test: AutocorrectionTests.DoNotLearnCorrectionsAfterChangingInputTypeFromPassword
* Source/WebCore/html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::runPostTypeUpdateTasks):
Set `m_hasEverBeenPasswordField` here.
* Source/WebCore/html/HTMLInputElement.h:
(WebCore::HTMLInputElement::hasEverBeenPasswordField const):
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/Shared/FocusedElementInformation.h:
* Source/WebKit/Shared/FocusedElementInformation.serialization.in:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _updateTextInputTraits:]):
Consult `hasEverBeenPasswordField` on the focused element information, and disable learning from
corrections if it's set.
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
Propagate `hasEverBeenPasswordField` state to the UI process when focusing an input element.
(WebKit::WebPage::focusedElementInformation):
* Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:
Add an API test to exercise the change.
* Tools/TestWebKitAPI/ios/UIKitSPI.h:
Canonical link: https://commits.webkit.org/265870.476@safari-7616-branch
Commit: fbf193b73bbe8fde629673d3cf6ca5bfaa59745b
https://github.com/WebKit/WebKit/commit/fbf193b73bbe8fde629673d3cf6ca5bfaa59745b
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-08-29 (Tue, 29 Aug 2023)
Changed paths:
M Tools/Scripts/webkitpy/xcode/simulated_device.py
Log Message:
-----------
Cherry-pick 267428 at main (d6f0fede47d0). rdar://114626133
[run-webkit-tests] Surpress exception when terminating settings app
https://bugs.webkit.org/show_bug.cgi?id=260860
rdar://114626133
Reviewed by Ryan Haddad.
* Tools/Scripts/webkitpy/xcode/simulated_device.py:
(SimulatedDevice.is_usable): Combine exit codes from starting and stopping Settings app.
Canonical link: https://commits.webkit.org/267428@main
Canonical link: https://commits.webkit.org/265870.477@safari-7616-branch
Commit: bd8988b5b5928193ec58339b63b7b4056ca561ef
https://github.com/WebKit/WebKit/commit/bd8988b5b5928193ec58339b63b7b4056ca561ef
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-30 (Wed, 30 Aug 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Revert "Cherry-pick ad4d214a77c0. rdar://110354414"
This reverts commit a04291c8431c2b6ed7bcc23dc35b349a2c521dc2.
Identifier: 265423.925 at safari-7616-branch
Commit: 368b703b4b19775791467d8eaafaf5f4c5187e61
https://github.com/WebKit/WebKit/commit/368b703b4b19775791467d8eaafaf5f4c5187e61
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-08-30 (Wed, 30 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
Log Message:
-----------
Cherry-pick 346fdad1569d. rdar://112269436
RemoteLayerTreeDrawingAreaProxy needs to hold use-count for IOSurfaces until CA commits.
https://bugs.webkit.org/show_bug.cgi?id=260374
<rdar://112269436>
Reviewed by Simon Fraser.
CoreAnimation doesn't guarantee to have marked the IOSurface as in-use until the transaction is committed, not once the layer mutation happens.
This code was removed in 266557 at main (rdar://111986083) with the belief that it was no longer necessary.
This adds it back, but replaces kCATransactionPhasePostSynchronize with kCATransactionPhasePostCommit.
Waiting for the synchronize phase was a performance regression, and is unnecessary with the latest CoreAnimation, but we
still need to wait for the commit to happen. WebKit doesn't explicitly commit the CoreAnimation transaction, so the implicit
transaction commit might happen significantly later, and we need to ensure that we continue to mark any IOSurfaces as in-use (by
retaining the wrapping mach_port) in the interim.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
Canonical link: https://commits.webkit.org/267204@main
Identifier: 265423.926 at safari-7616-branch
Commit: d3c0bdc44628794eb1d0d92228beed480ebdd7af
https://github.com/WebKit/WebKit/commit/d3c0bdc44628794eb1d0d92228beed480ebdd7af
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-30 (Wed, 30 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
Log Message:
-----------
Apply patch. rdar://112269436
Apply Patch rdar://112269436
Identifier: 265423.927 at safari-7616-branch
Commit: 382b02a5fc1015d7f6d8c0929e138411eaf23623
https://github.com/WebKit/WebKit/commit/382b02a5fc1015d7f6d8c0929e138411eaf23623
Author: Antti Koivisto <antti at apple.com>
Date: 2023-08-31 (Thu, 31 Aug 2023)
Changed paths:
A LayoutTests/fast/css/style-scope-destruction-crash-expected.txt
A LayoutTests/fast/css/style-scope-destruction-crash.html
M Source/WebCore/rendering/PathOperation.cpp
M Source/WebCore/rendering/PathOperation.h
M Source/WebCore/style/StyleScope.cpp
Log Message:
-----------
heap-use-after-free | Style::Scope::removeStyleSheetCandidateNode; WebCore::SVGStyleElement::~SVGStyleElement; WebCore::ContainerNode::~ContainerNode
https://bugs.webkit.org/show_bug.cgi?id=260896
rdar://114231775
Reviewed by Alan Baradlay.
* LayoutTests/fast/css/style-scope-destruction-crash-expected.txt: Added.
* LayoutTests/fast/css/style-scope-destruction-crash.html: Added.
* Source/WebCore/rendering/PathOperation.cpp:
(WebCore::ReferencePathOperation::ReferencePathOperation):
(WebCore::ReferencePathOperation::element const): Deleted.
Get rid of the unused element field. This creates a RenderStyle -> DOM ownership cycle which
allows this crash to happen.
* Source/WebCore/rendering/PathOperation.h:
* Source/WebCore/style/StyleScope.cpp:
(WebCore::Style::Scope::~Scope):
Ensure we revoke weak pointers at the start of the destructor to avoid this class of problems.
Canonical link: https://commits.webkit.org/265870.481@safari-7616-branch
Commit: aae3b70b0eff5a764364564e406093eb080ed7ce
https://github.com/WebKit/WebKit/commit/aae3b70b0eff5a764364564e406093eb080ed7ce
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-08-31 (Thu, 31 Aug 2023)
Changed paths:
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/platform/audio/SincResampler.h
Log Message:
-----------
Make WebCore::SincResampler testable
https://bugs.webkit.org/show_bug.cgi?id=260933
<rdar://114732348>
Reviewed by Chris Dumez.
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
- Make SincResampler.h a private header.
* Source/WebCore/platform/audio/SincResampler.h:
(WebCore::SincResampler::processBuffer):
- Export static class method.
Canonical link: https://commits.webkit.org/265870.482@safari-7616-branch
Commit: 0b3c33c1757d5cc25883582b4020f9650016f86b
https://github.com/WebKit/WebKit/commit/0b3c33c1757d5cc25883582b4020f9650016f86b
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-31 (Thu, 31 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.h
M Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.mm
M Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm
Log Message:
-----------
Cherry-pick ccf8724c8c34. rdar://114047664
Remote list updates for link decoration filtering fail in Safari 17
https://bugs.webkit.org/show_bug.cgi?id=260391
rdar://114047664
Reviewed by Tim Horton.
On macOS Monterey (but not macOS Ventura or later), calling:
```
dlopen("/System/Library/PrivateFrameworks/WebPrivacy.framework/WebPrivacy", RTLD_NOW);
```
...fails to load WebPrivacy.framework from the Safari staged framework directory. This causes
`PAL::isWebPrivacyFrameworkAvailable()` to return `false`, which in turn breaks link decoration
filtering when advanced privacy protections are enabled. In comparison, the main built-in tracker
blocker loaded by Safari actually *successfully* loads, because we only use `objc_getClass` to look
up `WPResources`, and don't depend on a successful `dlopen`.
On downlevels, this call to `dlopen` is actually unnecessary, since we already link WebPrivacy via
`-weak_framework`; as such, it's sufficient to simply check whether any one of the framework API
classes (e.g. `WPResources`) have been loaded.
* Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.h:
* Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.mm:
* Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm:
Also, remove unnecessary soft link helpers for `WPNetworkAddressRange` (we don't need this because
we never need to create one of these in WebKit).
(WebKit::canUseWebPrivacyFramework):
(WebKit::resourceDataChangedNotificationName):
(WebKit::notificationUserInfoResourceTypeKey):
(-[WKWebPrivacyNotificationListener init]):
(-[WKWebPrivacyNotificationListener dealloc]):
(-[WKWebPrivacyNotificationListener didUpdate:]):
(WebKit::LinkDecorationFilteringController::updateStrings):
(WebKit::requestLinkDecorationFilteringData):
(WebKit::TrackerAddressLookupInfo::populateIfNeeded):
(WebKit::TrackerDomainLookupInfo::populateIfNeeded):
Canonical link: https://commits.webkit.org/267051@main
Identifier: 265870.483 at safari-7616-branch
Commit: 7fc573bfae2014d0117ef22421edb7e58e151e39
https://github.com/WebKit/WebKit/commit/7fc573bfae2014d0117ef22421edb7e58e151e39
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-08-31 (Thu, 31 Aug 2023)
Changed paths:
M Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.h
M Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.mm
Log Message:
-----------
Cherry-pick 546db343245a. rdar://114288616
[iOS 17+, Sonoma] REGRESSION (267051 at main): Safari no longer responds to WebPrivacy list changes
https://bugs.webkit.org/show_bug.cgi?id=260569
rdar://114288616
Reviewed by Aditya Keerthi.
Several API tests in `TestWebKitAPI.AdvancedPrivacyProtections` began to fail after the changes in
267051 at main; in particular, they're failing because I changed the `SOFT_LINK_CONSTANT_FOR_HEADER`
around `WPNotificationUserInfoResourceTypeKey` to `SOFT_LINK_CONSTANT_MAY_FAIL_FOR_HEADER`, the
latter of which never attempts to load will return `nil` unless we call
`PAL::canLoad_WebPrivacy_WPResourceDataChangedNotificationName()` first (the full macro expands to
the following):
```
namespace PAL {
static NSNotificationName constantWebPrivacyWPResourceDataChangedNotificationName;
bool init_WebPrivacy_WPResourceDataChangedNotificationName();
bool init_WebPrivacy_WPResourceDataChangedNotificationName()
{
void* constant = dlsym(WebPrivacyLibrary(), "WPResourceDataChangedNotificationName");
if (!constant)
return false;
constantWebPrivacyWPResourceDataChangedNotificationName = *static_cast<NSNotificationName const *>(constant);
return true;
}
PAL_EXPORT bool canLoad_WebPrivacy_WPResourceDataChangedNotificationName();
bool canLoad_WebPrivacy_WPResourceDataChangedNotificationName()
{
static bool loaded = init_WebPrivacy_WPResourceDataChangedNotificationName();
return loaded;
}
PAL_EXPORT NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName();
NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName()
{
return constantWebPrivacyWPResourceDataChangedNotificationName;
}
}
```
...in contrast, the original macro `SOFT_LINK_CONSTANT_FOR_HEADER` expands to:
```
namespace PAL {
PAL_EXPORT NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName();
NSNotificationName get_WebPrivacy_WPResourceDataChangedNotificationName()
{
static NSNotificationName constantWebPrivacyWPResourceDataChangedNotificationName;
static dispatch_once_t once;
dispatch_once(&once, ^{
void* constant = dlsym(WebPrivacyLibrary(), "WPResourceDataChangedNotificationName");
RELEASE_ASSERT_WITH_MESSAGE(constant, "%s", dlerror());
constantWebPrivacyWPResourceDataChangedNotificationName = *static_cast<NSNotificationName const *>(constant);
});
return constantWebPrivacyWPResourceDataChangedNotificationName;
}
}
```
This exposes a real bug caused by 267051 at main, where we no longer listen for the resource data
changed notification from WebPrivacy in WebKit since the soft-linking helper now always returns
`nil`. Fix this by reverting to the original `SOFT_LINK_CONSTANT_FOR_HEADER` for these two symbols,
which should be fine (i.e. not `RELEASE_ASSERT`) as long as we only ever call them from inside a
`canUseWebPrivacyFramework()` check.
* Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.h:
* Source/WebCore/PAL/pal/cocoa/WebPrivacySoftLink.mm:
Canonical link: https://commits.webkit.org/267181@main
Identifier: 265870.484 at safari-7616-branch
Commit: e89f320a2e6dfe8cd854a548e6200306db062f0f
https://github.com/WebKit/WebKit/commit/e89f320a2e6dfe8cd854a548e6200306db062f0f
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-08-31 (Thu, 31 Aug 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Revert "Revert "Cherry-pick ad4d214a77c0. rdar://110354414""
This reverts commit bd8988b5b5928193ec58339b63b7b4056ca561ef.
Identifier: 265870.485 at safari-7616-branch
Commit: 3fc6931dcc2c041d058153e789eb585b6185645f
https://github.com/WebKit/WebKit/commit/3fc6931dcc2c041d058153e789eb585b6185645f
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-08-31 (Thu, 31 Aug 2023)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/fast/frames/frame-append-body-child-crash-expected.txt
A LayoutTests/fast/frames/frame-append-body-child-crash.html
M Source/WebCore/html/HTMLBodyElement.cpp
Log Message:
-----------
Crash under HTMLBodyElement::didFinishInsertingNode()
https://bugs.webkit.org/show_bug.cgi?id=260907
rdar://114177696
Reviewed by Ryosuke Niwa.
When a <body> is inserted into the document, `HTMLBodyElement::insertedIntoAncestor()`
gets called. This function would only return `InsertedIntoAncestorResult::NeedsPostInsertionCallback`
if `is<HTMLFrameElementBase>(document().ownerElement())`, causing `HTMLBodyElement::didFinishInsertingNode()`
to get called later on. We would then assume in didFinishInsertingNode() that the document's owner element
is a non-null HTMLFrameElementBase.
However, as proven by the test, DOM manipulations can happen in between the 2 calls
causing the assertion to no longer hold. To address the issue we now early return
if `is<HTMLFrameElementBase>(document().ownerElement())` is no longer true in
`HTMLBodyElement::didFinishInsertingNode()`.
In the case of the test, `document().frame()` becomes null because the frame gets
detached, causing `document().ownerElement()` to return null as well.
* LayoutTests/fast/frames/frame-append-body-child-crash-expected.txt: Added.
* LayoutTests/fast/frames/frame-append-body-child-crash.html: Added.
* Source/WebCore/html/HTMLBodyElement.cpp:
(WebCore::HTMLBodyElement::didFinishInsertingNode):
Canonical link: https://commits.webkit.org/265870.486@safari-7616-branch
Commit: 44934cbbb05bc90721b1387d7138fac7d1ef4b04
https://github.com/WebKit/WebKit/commit/44934cbbb05bc90721b1387d7138fac7d1ef4b04
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
A .submitproject
Log Message:
-----------
Update project submission metadata
rdar://114650948 (Update project submission metadata)
Reviewed by Jonathan Bedard.
* .submitproject: Added.
(cherry picked from commit fb1274371441d2a2a4c3c2ee9b6354cfe184092a)
Canonical link: https://commits.webkit.org/265870.487@safari-7616-branch
Commit: 92fe34f6d28497fb48a6054824a3dc582c5d90c4
https://github.com/WebKit/WebKit/commit/92fe34f6d28497fb48a6054824a3dc582c5d90c4
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebCore/platform/graphics/ca/PlatformCALayer.h
M Source/WebCore/platform/graphics/ca/PlatformCALayer.mm
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm
Log Message:
-----------
Cherry-pick 49aa2ac7ade4. rdar://113041840
Have PlatformCALayer keep a strong ref to its mask layer
https://bugs.webkit.org/show_bug.cgi?id=259605
rdar://113041840
Reviewed by Tim Horton.
PlatformCALayerRemote holds a raw pointer to its mask layer. This layer is retained by other means,
but it's simpler to have it hold a strong reference. Rather than give PlatformCALayerRemote different
ownership behavior to PlatformCALayerCocoa, move the ownership of m_maskLayer into the base class.
Also rename setMask -> setMaskLayer which is more descriptive.
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::updateClippingStrategy):
(WebCore::GraphicsLayerCA::updateContentsRects):
(WebCore::GraphicsLayerCA::updateMaskLayer):
* Source/WebCore/platform/graphics/ca/PlatformCALayer.h:
* Source/WebCore/platform/graphics/ca/PlatformCALayer.mm:
(WebCore::PlatformCALayer::setMaskLayer):
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.h:
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::setMaskLayer):
(WebCore::PlatformCALayerCocoa::setMask): Deleted.
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.mm:
(WebKit::PlatformCALayerRemote::recursiveBuildTransaction):
(WebKit::PlatformCALayerRemote::setMaskLayer):
(WebKit::PlatformCALayerRemote::setMask): Deleted.
Canonical link: https://commits.webkit.org/266405@main
Identifier: 265870.488 at safari-7616-branch
Commit: 728b640c383715363a4f600f904cb7ffefb36d36
https://github.com/WebKit/WebKit/commit/728b640c383715363a4f600f904cb7ffefb36d36
Author: Alex Christensen <achristensen at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WTF/wtf/ThreadSafeWeakHashSet.h
M Source/WTF/wtf/WeakHashMap.h
M Source/WTF/wtf/WeakHashSet.h
M Source/WTF/wtf/WeakListHashSet.h
M Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp
Log Message:
-----------
Cherry-pick 4d7698241f39. rdar://114710938
Simplify amortized cleanup algorighm for weak hash structures
https://bugs.webkit.org/show_bug.cgi?id=259847
rdar://113419306
Reviewed by Chris Dumez.
In 266594 at main Chris fixed an important bug where if you only add to a
ThreadSafeHashSet, you never hit the cleanup condition of the container.
Other containers had this same issue. This simplifies the algorithm used
to determine whether to clean up the container to just this:
1. Increase the operation count when an add/remove operation happens.
2. If the operation count has exceeded the threshold, clean up.
3. When cleaning up, set the threshold to 2 * the current size.
That is still amortized, doesn't have the issue Chris fixed, and is simpler
to reason about and easier to see what is going on.
* Source/WTF/wtf/ThreadSafeWeakHashSet.h:
* Source/WTF/wtf/WeakHashMap.h:
* Source/WTF/wtf/WeakHashSet.h:
* Source/WTF/wtf/WeakListHashSet.h:
Canonical link: https://commits.webkit.org/266713@main
Identifier: 265870.489 at safari-7616-branch
Commit: cf156672498e2e01918e58bf2b525c988c016a63
https://github.com/WebKit/WebKit/commit/cf156672498e2e01918e58bf2b525c988c016a63
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/JavaScriptCore/runtime/JSArray.cpp
M Source/JavaScriptCore/runtime/JSGlobalObjectInlines.h
Log Message:
-----------
Cherry-pick ddd9cbc5f5a7. rdar://114202373
[JSC] Throw OOM error if constructArrayNegativeIndexed() fails to allocate
https://bugs.webkit.org/show_bug.cgi?id=260559
<rdar://114202373>
Reviewed by Mark Lam.
This change leverages AllocationFailureMode to throw an OOM error if constructArrayNegativeIndexed()
fails to allocate an array, which does happen in the wild (iOS apps).
All clients of constructArrayNegativeIndexed() were updated to correctly handle thrown exception.
* Source/JavaScriptCore/runtime/JSArray.cpp:
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* Source/JavaScriptCore/runtime/JSGlobalObjectInlines.h:
(JSC::constructArrayNegativeIndexed):
Canonical link: https://commits.webkit.org/267300@main
Identifier: 265870.490 at safari-7616-branch
Commit: 6ae731d5c8c1ea3828d08f25958a7ad9c4900ea4
https://github.com/WebKit/WebKit/commit/6ae731d5c8c1ea3828d08f25958a7ad9c4900ea4
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.mm
Log Message:
-----------
Cherry-pick 855292ca7929. rdar://114467908
[Cocoa] Window/screen picker is not shown when another SCStream is active
https://bugs.webkit.org/show_bug.cgi?id=260735
rdar://114467908
Reviewed by Jer Noble.
`SCContentSharingPicker.maximumStreamCount` controls the maximum number of SCStreams that
can be active in a process. WebKit should allow an arbitrary number of window/screen
streams to be created, so set it to std::numeric_limits<unsigned>::max().
* Source/WebCore/platform/mediastream/mac/ScreenCaptureKitSharingSessionManager.mm:
(WebCore::ScreenCaptureKitSharingSessionManager::promptWithSCContentSharingPicker):
Canonical link: https://commits.webkit.org/267301@main
Identifier: 265870.491 at safari-7616-branch
Commit: 8cae7a57d0e79623b488e006b08f354d62c60a06
https://github.com/WebKit/WebKit/commit/8cae7a57d0e79623b488e006b08f354d62c60a06
Author: Antti Koivisto <antti at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/style/RuleFeature.cpp
M Source/WebCore/style/RuleFeature.h
M Source/WebCore/style/StyleInvalidationFunctions.h
M Source/WebCore/style/StyleInvalidator.cpp
Log Message:
-----------
Cherry-pick 7b40932f6b2a. rdar://114480735
Add fine-grained invalidation support for selectors containing :slotted()
https://bugs.webkit.org/show_bug.cgi?id=260755
rdar://114480735
Reviewed by Alan Baradlay.
* Source/WebCore/style/RuleFeature.cpp:
(WebCore::Style::isSiblingOrSubject):
(WebCore::Style::computeNextMatchElement):
ShadowSlotted shadow-piercing combinator generates HostChild match element for invalidation purposes.
(WebCore::Style::computeHasPseudoClassMatchElement):
(WebCore::Style::RuleFeatureSet::recursivelyCollectFeaturesFromSelector):
* Source/WebCore/style/RuleFeature.h:
* Source/WebCore/style/StyleInvalidationFunctions.h:
(WebCore::Style::traverseRuleFeatures):
Remove now-unnessary slotted test that would lead to large invalidations.
* Source/WebCore/style/StyleInvalidator.cpp:
(WebCore::Style::Invalidator::invalidateStyleWithMatchElement):
Traverse host children for the HostChild match element.
Canonical link: https://commits.webkit.org/267326@main
Identifier: 265870.492 at safari-7616-branch
Commit: 6f5a946dbf1cd638328aa74bf040c86d343a609a
https://github.com/WebKit/WebKit/commit/6f5a946dbf1cd638328aa74bf040c86d343a609a
Author: Antti Koivisto <antti at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/style/AttributeChangeInvalidation.cpp
M Source/WebCore/style/ClassChangeInvalidation.cpp
M Source/WebCore/style/IdChangeInvalidation.cpp
M Source/WebCore/style/PseudoClassChangeInvalidation.cpp
M Source/WebCore/style/RuleFeature.cpp
M Source/WebCore/style/StyleInvalidationFunctions.h
M Source/WebCore/style/StyleInvalidator.cpp
M Source/WebCore/style/StyleInvalidator.h
Log Message:
-----------
Cherry-pick 321396c31ca5. rdar://114560066
Fine-grained invalidation for :host pseudo-class in non-subject position
https://bugs.webkit.org/show_bug.cgi?id=260791
rdar://problem/114560066
Reviewed by Alan Baradlay.
Handle invalidation of cases like
:host(.foo) bar
efficiently.
* Source/WebCore/style/AttributeChangeInvalidation.cpp:
(WebCore::Style::AttributeChangeInvalidation::invalidateStyle):
Collect any host rules from the shadow tree. This pattern repeats for attribute/id/class/pseudo-class cases.
* Source/WebCore/style/ClassChangeInvalidation.cpp:
(WebCore::Style::ClassChangeInvalidation::computeInvalidation):
* Source/WebCore/style/IdChangeInvalidation.cpp:
(WebCore::Style::IdChangeInvalidation::invalidateStyle):
* Source/WebCore/style/PseudoClassChangeInvalidation.cpp:
(WebCore::Style::PseudoClassChangeInvalidation::collectRuleSets):
* Source/WebCore/style/RuleFeature.cpp:
(WebCore::Style::computeNextMatchElement):
(WebCore::Style::computeHasPseudoClassMatchElement):
(WebCore::Style::RuleFeatureSet::recursivelyCollectFeaturesFromSelector):
* Source/WebCore/style/StyleInvalidationFunctions.h:
(WebCore::Style::traverseRuleFeaturesInShadowTree):
Don't force full shadow tree style recalc by returning mayAffectShadowTree bit in these cases.
* Source/WebCore/style/StyleInvalidator.cpp:
(WebCore::Style::Invalidator::collectRuleInformation):
Collect host rules for id invalidation.
(WebCore::Style::Invalidator::invalidateInShadowTreeIfNeeded):
Traverse the shadow tree if needed.
* Source/WebCore/style/StyleInvalidator.h:
Canonical link: https://commits.webkit.org/267355@main
Identifier: 265870.493 at safari-7616-branch
Commit: 5c7b94f196ecc4ab110ae19cc309e1ad8a1ede7a
https://github.com/WebKit/WebKit/commit/5c7b94f196ecc4ab110ae19cc309e1ad8a1ede7a
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
A LayoutTests/fast/viewport/ios/wide-desktop-viewport-in-enhanced-windowing-mode-expected.txt
A LayoutTests/fast/viewport/ios/wide-desktop-viewport-in-enhanced-windowing-mode.html
M Source/WebCore/page/ViewportConfiguration.cpp
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Tools/WebKitTestRunner/TestController.h
M Tools/WebKitTestRunner/TestOptions.cpp
M Tools/WebKitTestRunner/TestOptions.h
M Tools/WebKitTestRunner/ios/TestControllerIOS.mm
Log Message:
-----------
Cherry-pick 85d3ed836d99. rdar://109158566
[iPadOS] Google search results page may be clipped in portrait mode with stage manager enabled
https://bugs.webkit.org/show_bug.cgi?id=260773
rdar://109158566
Reviewed by Tim Horton.
When stage manager is enabled (i.e. `-[UIWindowScene _enhancedWindowingEnabled]` is `YES`) and we're
loading desktop-class websites with no meta viewport, our viewport configuration strategy is:
1. If the web view is wider than 980 pt, shrink to fit the view.
2. If the web view is narrower than 980 pt, shrink to fit 980 pt, and then let the rest of the page
overflow horizontally. This was devised as a way to avoid extremely awkward viewport sizing
behaviors when resizing windows on iPad to very narrow widths in stage manager, since the entire
page would be scaled down so much, that it would be left with no legible text.
To achieve (2), 250431 at main adjusted some logic when shrinking the viewport to fit, so that we'd
shrink down to fit 980 pt instead of the actual view width when computing the initial scale, when
the stage manager window is smaller than 980 pt. However, this means that on some models of iPad
where portrait mode is as narrow as 820 pt, we get horizontal scrolling in portrait mode, even when
Safari is fullscreen. At the same time, shrinking down to 980 pt also breaks layout on Google search
results, due to (what appears to be) an issue with the site itself when determining which search
results layout to use.
To mitigate both the horizontal scrolling and the site issue on Google search results for now,
simply adjust the (arbitrarily chosen) desktop viewport width of 980 to 820, which is the width of
the narrowest iPad in portrait mode that currently supports Stage Manager, iPad Air (5th gen).
Test: fast/viewport/ios/wide-desktop-viewport-in-enhanced-windowing-mode.html
* LayoutTests/fast/viewport/ios/wide-desktop-viewport-in-enhanced-windowing-mode-expected.txt: Added.
* LayoutTests/fast/viewport/ios/wide-desktop-viewport-in-enhanced-windowing-mode.html: Added.
Add a layout test that enables stage manager and desktop-class website viewport behaviors, to verify
that we shrink a very wide webpage (1280pt) down to 820, and let the remainder overflow
horizontally. Note that this test runs and yields the same results on both iPhone and iPad, since
it doesn't matter what the actual viewport length is — as long as it's below 820pt. Running this on
iPhone effectively simulates changing the stage manager window width on iPad to the narrowest
possible setting, and verifying that it scrolls horizontally instead of scaling down to comically
small proportions.
* Source/WebCore/page/ViewportConfiguration.cpp:
(WebCore::ViewportConfiguration::initialScaleFromSize const):
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _isWindowResizingEnabled]):
Drive-by fix: remove a runtime selector check that's no longer required.
* Tools/WebKitTestRunner/TestController.h:
* Tools/WebKitTestRunner/TestOptions.cpp:
(WTR::TestOptions::defaults):
(WTR::TestOptions::keyTypeMapping):
* Tools/WebKitTestRunner/TestOptions.h:
(WTR::TestOptions::enhancedWindowingEnabled const):
Add a mechanism to simulate stage manager being enabled, by swizzling `-_enhancedWindowingEnabled`
and returning `YES`.
* Tools/WebKitTestRunner/ios/TestControllerIOS.mm:
(overrideEnhancedWindowingEnabled):
(WTR::TestController::platformResetStateToConsistentValues):
Canonical link: https://commits.webkit.org/267365@main
Identifier: 265870.494 at safari-7616-branch
Commit: ac6978f5eb33d4305fbde2ac95a5193724c201d8
https://github.com/WebKit/WebKit/commit/ac6978f5eb33d4305fbde2ac95a5193724c201d8
Author: Charlie Wolfe <charliew at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/bindings/js/ScriptController.cpp
M Source/WebCore/dom/UserGestureIndicator.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ResourceLoadStatistics.mm
Log Message:
-----------
Cherry-pick e2a9577bb29b. rdar://113989281
ITP treats client injected JavaScript as user interaction
https://bugs.webkit.org/show_bug.cgi?id=260807
rdar://113989281
Reviewed by Brent Fulgham and John Wilander.
JavaScript evaluated by the client app is treated as if it was from a user gesture, so ITP
currently logs this as a user interaction. This leads to cases where a page can be granted
storage privileges without a meaningful user interaction.
The enum ProcessInteractionStyle already exists to indicate that logging user interaction
for a key press should be delayed until the key press is actually handled. Add another value
to this enum to indicate that a user gesture should never be logged as user interaction by ITP.
* Source/WebCore/bindings/js/ScriptController.cpp:
(WebCore::ScriptController::executeScriptInWorld):
* Source/WebCore/dom/UserGestureIndicator.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ResourceLoadStatistics.mm:
(TEST):
Canonical link: https://commits.webkit.org/267381@main
Identifier: 265870.495 at safari-7616-branch
Commit: 11e9669d122e0429592bd115a91e6f18c97104d7
https://github.com/WebKit/WebKit/commit/11e9669d122e0429592bd115a91e6f18c97104d7
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/JavaScriptCore/runtime/RegExpCachedResult.h
M Source/JavaScriptCore/runtime/RegExpGlobalData.h
M Source/JavaScriptCore/runtime/RegExpGlobalDataInlines.h
M Source/JavaScriptCore/runtime/StringPrototype.cpp
M Source/JavaScriptCore/runtime/StringReplaceCache.h
M Source/JavaScriptCore/runtime/StringReplaceCacheInlines.h
Log Message:
-----------
Cherry-pick 8224c0710a83. rdar://111910989
[JSC] Speculative fix for wrong MatchResult in StringReplaceCache
https://bugs.webkit.org/show_bug.cgi?id=260839
rdar://111910989
Reviewed by Mark Lam.
StringReplaceCache needs to setup RegExpCachedResult as if we do matching actually.
But it is wrongly setting MatchResult with the last failed matching. This is fine if
ovector is not updated in the last matching, but it is wrong if it gets updated even
in the failed RegExp matching. Failed to create such a test case, but anyway, there is no
guarantee not doing this. So, let's save and restore the actual RegExpCachedResult's MatchResult.
* Source/JavaScriptCore/runtime/RegExpCachedResult.h:
(JSC::RegExpCachedResult::result const):
* Source/JavaScriptCore/runtime/RegExpGlobalData.h:
* Source/JavaScriptCore/runtime/RegExpGlobalDataInlines.h:
(JSC::RegExpGlobalData::matchResult const):
(JSC::RegExpGlobalData::resetResultFromCache):
* Source/JavaScriptCore/runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearchWithCache):
* Source/JavaScriptCore/runtime/StringReplaceCache.h:
* Source/JavaScriptCore/runtime/StringReplaceCacheInlines.h:
(JSC::StringReplaceCache::set):
Canonical link: https://commits.webkit.org/267393@main
Identifier: 265870.496 at safari-7616-branch
Commit: 50d3f8125550b7df20936ff42de6561799db5c55
https://github.com/WebKit/WebKit/commit/50d3f8125550b7df20936ff42de6561799db5c55
Author: Alex Christensen <achristensen at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm
Log Message:
-----------
Cherry-pick df817dbe1509. rdar://114119254
Include ObjC class name of decode failures in crash logs' register values
https://bugs.webkit.org/show_bug.cgi?id=260871
rdar://114119254
Reviewed by David Kilzer.
Logs in rdar://113527046 indicate something occasionally crashes here, but we don't know what.
This will help gather information about what occasionally crashes.
* Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm:
(checkIfClassIsAllowed):
Canonical link: https://commits.webkit.org/267425@main
Identifier: 265870.497 at safari-7616-branch
Commit: 687bbccc494a3a4366f72075feb6a1d1719de28c
https://github.com/WebKit/WebKit/commit/687bbccc494a3a4366f72075feb6a1d1719de28c
Author: Megan Gardner <megan_gardner at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
Cherry-pick 4cde644bbab2. rdar://113924534
Obscured input fields are not obscured in the keyboard on visionOS.
https://bugs.webkit.org/show_bug.cgi?id=260838
rdar://113924534
Reviewed by Wenson Hsieh.
We need to look at the flag that is set on input fields that indicates that
they are obscured and use that information to determine if we should
emit all the of text. We started emitting text in
https://github.com/WebKit/WebKit/commit/e1c274e43bdde86eea8fdd34ccc7789fdc279511
so that we would show password in the keyboard field on visionOS,
but if the isAutoFilledAndObscured flag is set, we do not want to display
that information in the keyboard. We look at the start and end of the selected range,
and if either one is in an obscured input field, we do not emit all text.
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::requestDocumentEditingContext):
Canonical link: https://commits.webkit.org/267436@main
Identifier: 265870.498 at safari-7616-branch
Commit: 663a00d9697fc956de2feb952f3c614d2f285897
https://github.com/WebKit/WebKit/commit/663a00d9697fc956de2feb952f3c614d2f285897
Author: Tim Horton <thorton at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm
Log Message:
-----------
Cherry-pick a33d2c717ecb. rdar://112799115
updateRendering() gets stuck at the wrong framerate when thermal throttling changes
https://bugs.webkit.org/show_bug.cgi?id=260846
rdar://112799115
Reviewed by Wenson Hsieh and Simon Fraser.
It turns out that `maximumRefreshRate` is actually "the maximum frame rate you can
achieve given current throttling behaviors", not "the frame rate of the display".
That means that, when throttling states change, maximumRefreshRate can change too.
We currently do not respond to changes in maximumRefreshRate. This means that we
can get stuck with an incorrect `maximumRefreshRate` (and `preferredFramesPerSecond`,
which is downstream of it).
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm:
(-[WKDisplayLinkHandler initWithDrawingAreaProxy:]):
(-[WKDisplayLinkHandler invalidate]):
(-[WKDisplayLinkHandler observeValueForKeyPath:ofObject:change:context:]):
(-[WKDisplayLinkHandler didChangeNominalFramesPerSecond]):
When the CADisplayLink's CADisplay's `refreshRate` changes, reconfigure the display, which
results in communicating the new maximum frame rate back to WebCore and also (indirectly)
updating the CADisplayLink's `preferredFramesPerSecond`.
* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
Add CADisplay SPI.
Canonical link: https://commits.webkit.org/267440@main
Identifier: 265870.499 at safari-7616-branch
Commit: d1f7dabe5be512f27f40bd7acc7252fe5b9d099b
https://github.com/WebKit/WebKit/commit/d1f7dabe5be512f27f40bd7acc7252fe5b9d099b
Author: Antti Koivisto <antti at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
A LayoutTests/fast/has-sibling-without-parent-crash-expected.html
A LayoutTests/fast/has-sibling-without-parent-crash.html
M Source/WebCore/style/StyleInvalidator.cpp
Log Message:
-----------
Cherry-pick 82d7f771ca51. rdar://110129945
Nullptr crash with :has(~sibling) invalidation in shadow tree
https://bugs.webkit.org/show_bug.cgi?id=260902
rdar://110129945
Reviewed by Chris Dumez.
* LayoutTests/fast/has-sibling-without-parent-crash-expected.html: Added.
* LayoutTests/fast/has-sibling-without-parent-crash.html: Added.
* Source/WebCore/style/StyleInvalidator.cpp:
(WebCore::Style::Invalidator::invalidateStyleWithMatchElement):
Elements with siblings don't have a parent element when they are parented to a shadow root.
Canonical link: https://commits.webkit.org/267454@main
Identifier: 265870.500 at safari-7616-branch
Commit: d64464ad3e65f638d0c0782af4eafc35e2afc843
https://github.com/WebKit/WebKit/commit/d64464ad3e65f638d0c0782af4eafc35e2afc843
Author: Myles C. Maxfield <mmaxfield at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/coretext/FontPlatformDataCoreText.cpp
Log Message:
-----------
Cherry-pick 9de3b434f4b0. rdar://113706205
[Cocoa] font-family:system-ui results in totally garbled text when the user has a user-installed system font
https://bugs.webkit.org/show_bug.cgi?id=260886
rdar://113706205
Reviewed by Cameron McCormack.
When we serialize fonts across IPC, we aren't precise enough in our description of the system font.
This was causing the web process to use the real system font, while the GPU process uses the user-
installed system font.
This patch does 2 things to mitigate this:
1. Refuses to use a font if its location on disk ("reference URL") is different than the desired
location on disk
2. If we end up in this situation where we refuse to use a font, fall back to trying to create it
from the file on-disk rather than the higher-level font descriptor
This patch is untestable, as it requires a system-wide installation of a user-installed system font
that shadows the real system font.
* Source/WebCore/platform/graphics/coretext/FontPlatformDataCoreText.cpp:
(WebCore::findFontDescriptor):
(WebCore::createCTFont):
Canonical link: https://commits.webkit.org/267463@main
Identifier: 265870.501 at safari-7616-branch
Commit: a02ae7db53baae4973c1562e724d3fdafb123bd4
https://github.com/WebKit/WebKit/commit/a02ae7db53baae4973c1562e724d3fdafb123bd4
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm
Log Message:
-----------
Cherry-pick 2e3f11b2736f. rdar://109165939
[visionOS] Find in HTML note obscures matches when they are at the top
https://bugs.webkit.org/show_bug.cgi?id=260982
rdar://109165939
Reviewed by Wenson Hsieh.
On visionOS, the find bar initially appears in the scroll view's inset area.
As the scroll view is scrolled, the find bar's frame is adjusted to ensure
it is always at the top of the currently visible rect. Both these behaviors are
implemented by UIKit.
When matches are found, scrolling is performed to make them visible. This is
achieved by using `-[WKWebView _scrollToRect:origin:minimumScrollDistance:]`.
However, that method always enforces a minimum content offset of (0, 0). This
is incompatible with the find bar's position, since for matches at the top of
the scroll view, a scroll to (0, 0) is forced, even when match is already visible.
The forced scroll to (0, 0) then ends up obscuring the match, as the find bar's
position is adjusted to keep it at the top.
Fix by accounting for content insets when determining the minimum content offset
for targeted scrolling.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _initialContentOffsetForScrollView]):
(constrainContentOffset):
(-[WKWebView _scrollToRect:origin:minimumScrollDistance:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(TEST):
Use a 500ms delay to ensure that scrolling did not occur. Waiting for two
presentation updates is unfortunately insufficient.
Canonical link: https://commits.webkit.org/267539@main
Identifier: 265870.502 at safari-7616-branch
Commit: a7f6caecf68a0f4cd842294867eac0ee1b6d9834
https://github.com/WebKit/WebKit/commit/a7f6caecf68a0f4cd842294867eac0ee1b6d9834
Author: Karl Rackler <rackler at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M LayoutTests/platform/mac/TestExpectations
Log Message:
-----------
Cherry-pick fbe822a7df67. rdar://114472398
Cherry-pick 267302 at main (fbe822a7df67). rdar://114472398
[Gardening]: REGRESSION (267279 at main): [ macOS Debug ] ASSERTION FAILED: WebCore::MediaSource::completeSeek()::SeeksCallbackAggregator::SeeksCallbackAggregator
https://bugs.webkit.org/show_bug.cgi?id=260742
rdar://114472398
Unreviewed test gardening.
Add tests expectations.
* LayoutTests/platform/mac/TestExpectations:
Canonical link: https://commits.webkit.org/267302@main
Identifier: 265870.503 at safari-7616-branch
Commit: 6bb178acd45b7dec437ff3aacd6d96daf1d37da3
https://github.com/WebKit/WebKit/commit/6bb178acd45b7dec437ff3aacd6d96daf1d37da3
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-09-01 (Fri, 01 Sep 2023)
Changed paths:
M LayoutTests/platform/mac/TestExpectations
M Source/WebCore/Modules/mediasource/MediaSource.cpp
Log Message:
-----------
Cherry-pick f005b556a611. rdar://114472398
REGRESSION (267279 at main): [ macOS Debug ] ASSERTION FAILED: WebCore::MediaSource::completeSeek()::SeeksCallbackAggregator::SeeksCallbackAggregator
https://bugs.webkit.org/show_bug.cgi?id=260742
rdar://114472398
Reviewed by Richard Robinson and Alan Baradlay.
Fix incorrect assertion.
Covered by tests.
* LayoutTests/platform/mac/TestExpectations:
* Source/WebCore/Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::completeSeek):
Canonical link: https://commits.webkit.org/267314@main
Identifier: 265870.504 at safari-7616-branch
Commit: b6638698dc942b7b563aa2deb7b3a7bf6d0fd45b
https://github.com/WebKit/WebKit/commit/b6638698dc942b7b563aa2deb7b3a7bf6d0fd45b
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-05 (Tue, 05 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp
M Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
Log Message:
-----------
Cherry-pick 8b79cd47f0ad. rdar://107376322
[visionOS] Find overlay is missing behind find bar
https://bugs.webkit.org/show_bug.cgi?id=260815
rdar://107376322
Reviewed by Wenson Hsieh.
On visionOS, the find bar appears in the scroll view's inset area. Currently,
WebKit does not display a find overlay in the inset area, as the overlay is
tied to the web content. Specifically, the find overlay is a `PageOverlay` in
the web process, since the overlay must appear behind the highlights (which are
drawn in Web process).
To fix, add another overlay layer to the scroll view, designed to cover the
inset area. The UI process-side overlay is inserted behind the content view, to
avoid a double overlay, while still covering the inset area. Additionally,
the overlay is sized to match the scroll view's bounds, and its position is
adjusted as the scroll view is scrolled, to avoid creating an unnecessarily
large layer. In order to synchronize the animation between the `PageOverlay`
originated layer, and the new UI process-originated layer, existing SPI is
leveraged, and the animation is fully driven from the UI process.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _didCommitLayerTree:]):
(-[WKWebView scrollViewDidScroll:]):
(-[WKWebView _frameOrBoundsMayHaveChanged]):
(-[WKWebView _animationForFindOverlay:]):
(-[WKWebView _updateFindOverlayPosition]):
Update the overlay whenever the scroll position or scroll view size changes.
(-[WKWebView _showFindOverlay]):
Some clients may attempt to show an overlay when one is already visible. Handle
that scenario by cancelling any existing animations.
(-[WKWebView _hideFindOverlay]):
Only remove layers after the animation is complete.
(-[WKWebView _didAddLayerForFindOverlay:]):
(-[WKWebView _didRemoveLayerForFindOverlay]):
(-[WKWebView _removeLayerForFindOverlay]):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didEndTextSearchOperation): Deleted.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView didBeginTextSearchOperation]):
(-[WKContentView didEndTextSearchOperation]):
* Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.cpp:
(WebKit::WebFoundTextRangeController::didEndTextSearchOperation): Deleted.
* Source/WebKit/WebProcess/WebPage/WebFoundTextRangeController.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didEndTextSearchOperation): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
Canonical link: https://commits.webkit.org/267443@main
Identifier: 265870.505 at safari-7616-branch
Commit: 0a43c0df5dba63f33e1e777354f51a51bb1c1c62
https://github.com/WebKit/WebKit/commit/0a43c0df5dba63f33e1e777354f51a51bb1c1c62
Author: Tim Horton <thorton at apple.com>
Date: 2023-09-05 (Tue, 05 Sep 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebCore/Sources.txt
M Source/WebCore/SourcesCocoa.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/page/DOMTimer.h
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
A Source/WebCore/platform/ThermalMitigationNotifier.cpp
A Source/WebCore/platform/ThermalMitigationNotifier.h
M Source/WebCore/platform/audio/cocoa/AudioUtilitiesCocoa.h
M Source/WebCore/platform/cocoa/LowPowerModeNotifier.mm
A Source/WebCore/platform/cocoa/ThermalMitigationNotifier.mm
M Source/WebCore/platform/graphics/AnimationFrameRate.cpp
M Source/WebCore/platform/graphics/AnimationFrameRate.h
M Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm
M Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm
M Source/WebCore/platform/network/mac/UTIUtilities.mm
Log Message:
-----------
Cherry-pick 30884546903f. rdar://112725366
Cherry-pick 267480 at main (30884546903f). rdar://112725366
Timers are not coalesced during thermal throttling; should match low power mode
https://bugs.webkit.org/show_bug.cgi?id=260931
rdar://112725366
Reviewed by Aditya Keerthi.
* Source/WebCore/platform/ThermalMitigationNotifier.cpp: Added.
(WebCore::ThermalMitigationNotifier::ThermalMitigationNotifier):
(WebCore::ThermalMitigationNotifier::thermalMitigationEnabled const):
* Source/WebCore/platform/ThermalMitigationNotifier.h: Added.
* Source/WebCore/platform/cocoa/ThermalMitigationNotifier.mm: Added.
(-[WebThermalMitigationObserver initWithNotifier:]):
(-[WebThermalMitigationObserver dealloc]):
(-[WebThermalMitigationObserver thermalStateDidChange]):
(-[WebThermalMitigationObserver thermalMitigationEnabled]):
(WebCore::ThermalMitigationNotifier::ThermalMitigationNotifier):
(WebCore::ThermalMitigationNotifier::~ThermalMitigationNotifier):
(WebCore::ThermalMitigationNotifier::thermalMitigationEnabled const):
(WebCore::ThermalMitigationNotifier::notifyThermalMitigationChanged):
(WebCore::notifyThermalMitigationChanged):
Add an observer for thermal state. Assume that we want to mitigate our contribution
to high thermals when the state is Serious or above.
This has the same shape as LowPowerModeNotifier.
* Source/WTF/wtf/PlatformHave.h:
* Source/WebCore/Sources.txt:
* Source/WebCore/SourcesCocoa.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/page/DOMTimer.h:
* Source/WebCore/page/Page.cpp:
(WebCore::m_thermalMitigationNotifier):
(WebCore::m_badgeClient):
(WebCore::Page::didChangeThrottlingReasons):
(WebCore::Page::setIsVisuallyIdleInternal):
(WebCore::Page::handleLowModePowerChange):
(WebCore::Page::handleThermalMitigationChange):
(WebCore::Page::updateDOMTimerAlignmentInterval):
* Source/WebCore/page/Page.h:
(WebCore::Page::isThermalMitigationEnabled const):
* Source/WebCore/platform/graphics/AnimationFrameRate.cpp:
(WebCore::operator<<):
* Source/WebCore/platform/graphics/AnimationFrameRate.h:
When thermal mitigation is enabled, align DOM timers to 30ms like we do in low power mode.
* Source/WebCore/platform/graphics/avfoundation/objc/AVAssetMIMETypeCache.mm:
* Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm:
(WebCore::transformationMatrixForVideoFrame):
(WebCore::LocalSampleBufferDisplayLayer::enqueueVideoFrame):
(WebCore::videoTransformationMatrix): Deleted.
* Source/WebCore/platform/network/mac/UTIUtilities.mm:
* Source/WebCore/platform/audio/cocoa/AudioUtilitiesCocoa.h:
Unrelated unified sources fixes.
Canonical link: https://commits.webkit.org/267480@main
Identifier: 265870.506 at safari-7616-branch
Commit: 16da03015fa8ea9400170304c266ce50c494640d
https://github.com/WebKit/WebKit/commit/16da03015fa8ea9400170304c266ce50c494640d
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-09-05 (Tue, 05 Sep 2023)
Changed paths:
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
Log Message:
-----------
Cherry-pick a36f0d120d30. rdar://113994918
Cherry-pick 267562 at main (a36f0d120d30). rdar://113994918
AX: Sometimes web content becomes inaccessible to VoiceOver
https://bugs.webkit.org/show_bug.cgi?id=261006
rdar://113994918
Reviewed by Tyler Wilcock.
The problem is caused by the following sequence of events:
1. An AXObjectCache and AXIsolatedTree exist for the current page.
2. When the page is reloaded, the cache is destroyed and the isolated tree ActivityState is set to an empty set. The isolated tree is also queued to be destroyed.
3. VoiceOver queries for the focus off the main thread, but no isolated tree with focus is found sin the ActivityState is now empty or the tree was completely removed at that point.
4. A new AXObjectcache is created, but no new isolated object is created because this new AXObjectCache does not receive any request for the focus, which is one of the triggers of creating a new isolated tree.
The solution in this patch is to dispatch to the main thread the request for the focus in this scenario, which will result in the creation of a new isolated tree.
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::accessibilityFocusedUIElement):
Canonical link: https://commits.webkit.org/267562@main
Identifier: 265870.507 at safari-7616-branch
Commit: 566abf81035c04ada29845145e64a78838c7c142
https://github.com/WebKit/WebKit/commit/566abf81035c04ada29845145e64a78838c7c142
Author: Remy Demarest <rdemarest at apple.com>
Date: 2023-09-05 (Tue, 05 Sep 2023)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/page/Chrome.cpp
M Source/WebCore/page/LocalDOMWindow.cpp
M Source/WebCore/page/WindowFeatures.cpp
M Source/WebCore/page/WindowFeatures.h
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/API/C/WKPage.cpp
M Source/WebKit/UIProcess/API/Cocoa/WKWindowFeatures.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWindowFeaturesPrivate.h
M Source/WebKit/UIProcess/API/glib/WebKitWindowProperties.cpp
M Source/WebKitLegacy/mac/WebCoreSupport/WebChromeClient.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/OpenAndCloseWindow.mm
Log Message:
-----------
Cherry-pick 301fe8a7cb26. rdar://112086061
REGRESSION (Safari 16.3): Passing "noopener" as third argument opens tabs into new window
https://bugs.webkit.org/show_bug.cgi?id=259093
rdar://112086061
Reviewed by BJ Burg and Chris Dumez.
The changes herein bring WebKit up to the HTML specs for window.open().
First, this commit now parses the popup field which is specified in the specs but
was missing in our parser. We also start parsing the resizable field which is defined
in our API but was never parsed. Finally, we mark all other member fields of optional
rather than setting a default value for each of them.
Second, this adds the member fields wantsPopup and hasAdditionalFeatures:
hasAdditionalFeatures is serialized and sent to the UI Process to indicate that we
detected other strings than the ones we normally parse.
The field wantsPopup implements the algorithm described here:
https://html.spec.whatwg.org/multipage/nav-history-apis.html#apis-for-creating-and-navigating-browsing-contexts-by-name
aimed at determining whether we should display a popup or not. Its value is determined
in the following way:
- features noopener and noreferrer do not count towards the tested feature string.
- empty features (two commas in a row), strings made of spaces only do not towards
the tested feature string. So spaces and commas don't make the string not empty.
- every other words or characters are counted.
As such the first test to determine the value of wantsPopup is to check whether any
feature is defined or if the string contains additional features, the latter flag is
only set if the string contains anything but spaces and commas. This matches the
behavior from other browsers and prescribed by the specs.
Finally, despite being declared as nullable, the corresponding properties in WKWindowFeatures
could never be in fact nil; changing all member fields in WindowFeatures to std::optional
allows us to return nil in the corresponding properties when those features are missing.
We also add private properties for the corresponding WindowFeatures member fields.
These changes ostensibly fixes the issue in question since we needed the ability to check
for the absence of the window features. However, to be correct a browser should adopt the
new properties as well.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::createWindow):
* Source/WebCore/page/Chrome.cpp:
(WebCore::Chrome::createWindow):
* Source/WebCore/page/LocalDOMWindow.cpp:
(WebCore::LocalDOMWindow::createWindow):
* Source/WebCore/page/WindowFeatures.cpp:
(WebCore::WindowFeatures::wantsPopup const):
Implements the specs algorithm to check if we need to get a popup. No features declared
besides noopener and noreferrer means we do not want a popup.
(WebCore::parseWindowFeatures):
Stop setting default values for the window features to avoid indicating that those features
were declared in the string. Compute wantsPopup after we are done parsing the string.
(WebCore::setWindowFeature):
Add a parse step for the popup feature and set the additional features when they are not empty
strings or strings made of spaces.
(WebCore::parseDialogFeatures):
Dialogs are always popups.
* Source/WebCore/page/WindowFeatures.h:
Make all potential features optional. Add convenience member functions to use instead of
using noopener and noreferrer directly.
(WebCore::WindowFeatures::wantsNoOpener const):
(WebCore::WindowFeatures::wantsNoReferrer const):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Match the declaration above. Serialize the three new fields.
* Source/WebKit/UIProcess/API/C/WKPage.cpp:
(WKPageSetPageUIClient):
Save the new fields in the window feature dictionary for legacy clients.
* Source/WebKit/UIProcess/API/Cocoa/WKWindowFeatures.mm:
(-[WKWindowFeatures menuBarVisibility]):
(-[WKWindowFeatures statusBarVisibility]):
(-[WKWindowFeatures toolbarsVisibility]):
(-[WKWindowFeatures allowsResizing]):
(-[WKWindowFeatures _wantsPopup]):
(-[WKWindowFeatures _hasAdditionalFeatures]):
(-[WKWindowFeatures _popup]):
(-[WKWindowFeatures _locationBarVisibility]):
(-[WKWindowFeatures _scrollbarsVisibility]):
(-[WKWindowFeatures _fullscreenDisplay]):
(-[WKWindowFeatures _dialogDisplay]):
* Source/WebKit/UIProcess/API/Cocoa/WKWindowFeaturesPrivate.h:
Check if the value is defined and return it as a boolean otherwise return nil.
* Source/WebKit/UIProcess/API/glib/WebKitWindowProperties.cpp:
Convert optional features into glib API.
(webkitWindowPropertiesSetGeometry):
(webkitWindowPropertiesSetWantsPopup):
* Source/WebKitLegacy/mac/WebCoreSupport/WebChromeClient.mm:
(WebChromeClient::createWindow):
Write the new fields in the window feature dictionary for legacy clients.
Only write optional fields if they are not null.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/OpenAndCloseWindow.mm:
(TEST(WebKit, OpenWindowFeatures)):
- Reenable the tests checking for the nil case when the string is empty.
- Add checks for the new fields in the API.
- Add tests for noopener and noreferrer features.
- Add test for hasAdditionalFeatures.
- Add test for a string containing only separators.
Canonical link: https://commits.webkit.org/267354@main
Identifier: 265870.508 at safari-7616-branch
Commit: d08de0641c8f863620402899bd17d4901c9f1a79
https://github.com/WebKit/WebKit/commit/d08de0641c8f863620402899bd17d4901c9f1a79
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-05 (Tue, 05 Sep 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
Log Message:
-----------
Cherry-pick f4af2e26b34e. rdar://113459873
[visionOS] YouTube audio in background tab stops after looking away from Safari for one minute
https://bugs.webkit.org/show_bug.cgi?id=261050
rdar://113459873
Reviewed by Tim Horton.
On visionOS, scenes are backgrounded after they are out of the user's field of
view for one minute. This is similar to iPadOS, where the device is locked when
looking away from the screen for two minutes (configurable via Settings).
However, unlike iPadOS, visionOS has no device-level idle state, as the display
is always on when the device is in use, and always off when it is not.
The only way to prevent the aforementioned scene backgrounding is to disable
the application-level idle timer. This timer is currently only disabled when the
document containing a playing media element is visible. If the media element is
playing and in a hidden document (as is the case in a background tab), a system
sleep assertion is taken instead. This assertion has no meaning as there is no
"user-idle" state while the device is in use. Consequently, the idle timer is
active, the scene gets backgrounded after one minute, and playback is paused
by WebKit as the notification is received.
To fix, ensure the idle timer remains disabled when media is playing in a
hidden document.
* Source/WTF/wtf/PlatformHave.h:
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::shouldDisableSleep const):
* Source/WebCore/html/HTMLMediaElement.h:
Drive-by: Specify the smallest underlying type for the `SleepType` enum class.
Canonical link: https://commits.webkit.org/267615@main
Identifier: 265870.509 at safari-7616-branch
Commit: d82d295dab7a100189e6abade47e6d9920437538
https://github.com/WebKit/WebKit/commit/d82d295dab7a100189e6abade47e6d9920437538
Author: Matthew Finkel <sysrqb at apple.com>
Date: 2023-09-06 (Wed, 06 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/NavigationState.mm
M Source/WebKit/UIProcess/WebFramePolicyListenerProxy.cpp
M Source/WebKit/UIProcess/WebFramePolicyListenerProxy.h
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Source/WebKit/UIProcess/WebFrameProxy.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm
Log Message:
-----------
Cherry-pick 6bf1ccd096fb. rdar://105809792
Inform client if intercepted navigation failed
https://bugs.webkit.org/show_bug.cgi?id=260638
rdar://105809792
Reviewed by Brent Fulgham and J Pascoe.
A client may allow a navigation, but that navigation is ignored anyway. In this
situation, the client may never learn that the navigation was canceled. In the
specific case for SOAuthentication, the client may allow the navigation but
then that decision is overridden by SOAuthentication and the request is
cancelled. When this happens, WebKit doesn't dispatch a failure because we
never reach the provisional load stage.
This change addresses this issue by identifying when a policy decision was
intercepted and the resulting decision is PolicyAction::Ignore. In this case,
we dispatch didFailProvisionalNavigation. We make this call in
WebPageProxy::receivedNavigationPolicyDecision because if we call it earlier
then WKWebView::isLoading returns true and this is wrong and confuses clients.
Most of this patch is just plumbing.
This change extends the existing test and resolves the FIXME.
* Source/WebKit/UIProcess/Cocoa/NavigationState.mm:
(WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction):
* Source/WebKit/UIProcess/WebFramePolicyListenerProxy.cpp:
(WebKit::WebFramePolicyListenerProxy::didReceiveAppBoundDomainResult):
(WebKit::WebFramePolicyListenerProxy::didReceiveSafeBrowsingResults):
(WebKit::WebFramePolicyListenerProxy::didReceiveInitialLinkDecorationFilteringData):
(WebKit::WebFramePolicyListenerProxy::use):
(WebKit::WebFramePolicyListenerProxy::download):
(WebKit::WebFramePolicyListenerProxy::ignore):
* Source/WebKit/UIProcess/WebFramePolicyListenerProxy.h:
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::setUpPolicyListenerProxy):
* Source/WebKit/UIProcess/WebFrameProxy.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::receivedNavigationPolicyDecision):
(WebKit::WebPageProxy::decidePolicyForNavigationAction):
(WebKit::WebPageProxy::decidePolicyForNewWindowAction):
(WebKit::WebPageProxy::decidePolicyForResponseShared):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm:
(-[TestSOAuthorizationDelegate webView:didFailProvisionalNavigation:withError:]):
(resetState):
(TestWebKitAPI::TEST):
Originally-landed-as: 267360 at main (d417f615be0e). rdar://105809792
Identifier: 265870.510 at safari-7616-branch
Commit: 4f18046301c361e0728c631d76d4189b30507fc6
https://github.com/WebKit/WebKit/commit/4f18046301c361e0728c631d76d4189b30507fc6
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-09-06 (Wed, 06 Sep 2023)
Changed paths:
M LayoutTests/interaction-region/full-page-overlay-expected.txt
M LayoutTests/interaction-region/full-page-overlay.html
M LayoutTests/interaction-region/interaction-layers-culling-expected.txt
M LayoutTests/interaction-region/layer-tree-expected.txt
M LayoutTests/interaction-region/layer-tree.html
M LayoutTests/interaction-region/overlay-expected.txt
M LayoutTests/interaction-region/position-only-update-expected.txt
M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
M Source/WebCore/page/InteractionRegion.cpp
M Source/WebCore/page/scrolling/ScrollingStateNode.cpp
M Source/WebCore/page/scrolling/ScrollingStateNode.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.mm
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.mm
M Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.mm
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.h
M Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.mm
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeNode.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeNode.mm
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm
M Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm
Log Message:
-----------
Cherry-pick 0b4a949b311f. rdar://102758344
Cherry-pick b6bfbe1b5821. rdar://102758344
Cherry-pick 267441 at main (b6bfbe1b5821). <rdar://102758344>
Weave the InteractionRegion layers into the content layer tree
https://bugs.webkit.org/show_bug.cgi?id=260386
<rdar://102758344>
Reviewed by Tim Horton.
InteractionRegion layers lived in a "duplicated", always-on-top, layer tree.
This patch merges them back into the content's layer tree. This makes
for an overall lighter tree, but the main goal is to let content layers
partially occlude the glow effects.
When a compositing layer has Interaction Regions, we create and insert an
InteractionRegions container as one of its sublayers. *Positioning is key!*
It's always positioned below the first sublayer that contains other
Interaction Regions.
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm:
(WebKit::RemoteLayerTreePropertyApplier::applyPropertiesToLayer):
(WebKit::RemoteLayerTreePropertyApplier::applyProperties):
(WebKit::applyCommonPropertiesToLayer): Deleted.
(WebKit::applyInteractionRegionsHierarchyUpdate): Deleted.
Remove the "duplicated" layer tree code paths.
(WebKit::RemoteLayerTreePropertyApplier::applyHierarchyUpdates):
Signal the RemoteLayerTreeNode when an hierarchy update happened.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeHost.mm:
(WebKit::RemoteLayerTreeHost::updateLayerTree):
Remove the code that was keeping the "duplicated" InteractionRegion layer
tree always on top.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::isAnyInteractionRegionLayer): Deleted.
(WebKit::insertInteractionRegionLayersForLayer): Deleted.
Remove the code that was maintaining the "duplicated" InteractionRegion
layer tree.
(WebKit::updateLayersForInteractionRegions):
Remove the InteractionRegions container from the node when it contains no
Interaction Region.
Re-introduce the HashSet preventing duplicated layers with the same
rect.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeNode.h:
(WebKit::RemoteLayerTreeNode::interactionRegionsLayer const): Deleted.
Rename the node's `interactionRegionsLayer` as
`interactionRegionsContainer`.
Change the API so that it's lazily created when needed.
(WebKit::RemoteLayerTreeNode::hasInteractionRegionsDescendant const):
(WebKit::RemoteLayerTreeNode::setHasInteractionRegionsDescendant):
Introduce a new `hasInteractionRegionsDescendant` flag.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeNode.mm:
(WebKit::RemoteLayerTreeNode::~RemoteLayerTreeNode):
Remove the InteractionRegions container, if any, in the destructor.
(WebKit::RemoteLayerTreeNode::detachFromParent):
Remove the InteractionRegions container, if any, when detaching.
(WebKit::RemoteLayerTreeNode::initializeLayer):
Set layers as `hitTestsContentsAlphaChannel`, this is key for the glow
effect to work properly while the InteractionRegion layers are weaved
into the content tree.
(WebKit::RemoteLayerTreeNode::ensureInteractionRegionsContainer):
Return the existing InteractionRegions container if it exists.
Create and position an InteractionRegions container otherwise.
Adding a new container can impact the positioning of containers higher
in the tree given our positioning rule.
(WebKit::RemoteLayerTreeNode::removeInteractionRegionsContainer):
Remove and release the InteractionRegions container if it exists.
Remove a container can impact the positioning of containers higher in
the tree.
(WebKit::RemoteLayerTreeNode::updateInteractionRegionAfterHierarchyChange):
React to a hierarchy change (sublayers update):
- reposition the InteractionRegions container if needed.
- update the `hasInteractionRegionsDescendant` flag if needed.
(WebKit::RemoteLayerTreeNode::hasInteractionRegions const):
A node "has interaction regions" if it owns an InteractionRegions
container or if one of its descendants does.
(WebKit::RemoteLayerTreeNode::repositionInteractionRegionsContainerIfNeeded):
Find the correct position of the InteractionRegions container and move
it here if needed.
(WebKit::RemoteLayerTreeNode::propagateInteractionRegionsChangeInHierarchy):
Traverse the node's hierarchy to maintain the containers positions and
`hasInteractionRegionsDescendant` flags.
* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
Add the SPI for `hitTestsContentsAlphaChannel`.
* Source/WebCore/page/InteractionRegion.cpp:
(WebCore::shouldGetOcclusion):
(WebCore::isOverlay): Deleted.
Rename `isOverlay` to `shouldGetOcclusion`.
(WebCore::interactionRegionForRenderedRegion):
Don't generate extra occlusion layers when the compositing layer is
already occluding.
* Source/WebCore/page/scrolling/ScrollingStateNode.cpp:
(WebCore::ScrollingStateNode::setInteractionRegionsLayer): Deleted.
* Source/WebCore/page/scrolling/ScrollingStateNode.h:
(WebCore::ScrollingStateNode::interactionRegionsLayer const): Deleted.
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeFixedNodeCocoa.mm:
(WebCore::ScrollingTreeFixedNodeCocoa::commitStateBeforeChildren):
(WebCore::ScrollingTreeFixedNodeCocoa::applyLayerPositions):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeOverflowScrollProxyNodeCocoa.mm:
(WebCore::ScrollingTreeOverflowScrollProxyNodeCocoa::commitStateBeforeChildren):
(WebCore::ScrollingTreeOverflowScrollProxyNodeCocoa::applyLayerPositions):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNodeCocoa.mm:
(WebCore::ScrollingTreePositionedNodeCocoa::commitStateBeforeChildren):
(WebCore::ScrollingTreePositionedNodeCocoa::applyLayerPositions):
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.h:
* Source/WebCore/page/scrolling/cocoa/ScrollingTreeStickyNodeCocoa.mm:
(WebCore::ScrollingTreeStickyNodeCocoa::commitStateBeforeChildren):
(WebCore::ScrollingTreeStickyNodeCocoa::applyLayerPositions):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteScrollingCoordinatorProxyIOS.mm:
(WebKit::RemoteScrollingCoordinatorProxyIOS::connectStateNodeLayers):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm:
(WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateBeforeChildren):
(WebKit::ScrollingTreeScrollingNodeDelegateIOS::repositionScrollingLayers):
Remove the code that was maintaining the "duplicated" InteractionRegion
layer tree.
* LayoutTests/interaction-region/full-page-overlay.html:
* LayoutTests/interaction-region/full-page-overlay-expected.txt:
Cover the overlay detection logic without compositing.
* LayoutTests/interaction-region/layer-tree.html:
* LayoutTests/interaction-region/layer-tree-expected.txt:
Update the layer tree test to exercise more of the RemoteLayerTreeNode
logic.
* LayoutTests/interaction-region/interaction-layers-culling-expected.txt:
Test expectation update: new layer tree structure.
* LayoutTests/interaction-region/overlay-expected.txt:
* LayoutTests/interaction-region/position-only-update-expected.txt:
Test expectation update: removed occlusion layers.
Canonical link: https://commits.webkit.org/267441@main
Identifier: 265870.510 at safari-7616.2.5-branch
Identifier: 265870.511 at safari-7616-branch
Commit: f02f51c38ed7424592d46c61534407376e24720e
https://github.com/WebKit/WebKit/commit/f02f51c38ed7424592d46c61534407376e24720e
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-09-06 (Wed, 06 Sep 2023)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/platform/graphics/MediaPlayer.cpp
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h
M Source/WebKit/WebProcess/GPU/media/cocoa/MediaPlayerPrivateRemoteCocoa.mm
Log Message:
-----------
Apply patch. rdar://110467872
Identifier: 265870.512 at safari-7616-branch
Commit: 8a8cab772afb7f1a9a9cc9f393392b2e9cc87264
https://github.com/WebKit/WebKit/commit/8a8cab772afb7f1a9a9cc9f393392b2e9cc87264
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-09-06 (Wed, 06 Sep 2023)
Changed paths:
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTreePropertyApplier.mm
Log Message:
-----------
Unreviewed build fix
Identifier: 265870.513 at safari-7616-branch
Commit: 89bddc04cb619be75d433081d6ee4d041f309694
https://github.com/WebKit/WebKit/commit/89bddc04cb619be75d433081d6ee4d041f309694
Author: Sam Sneddon <gsnedders at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/hooks/pre-commit
M Tools/Scripts/hooks/pre-push
M Tools/Scripts/hooks/prepare-commit-msg
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_hooks.py
Log Message:
-----------
Cherry-pick 266577 at main (3aa38b6cb9f2). rdar://113294324
[git-webkit] Avoid hardcoding working tree path in hooks
https://bugs.webkit.org/show_bug.cgi?id=259753
rdar://problem/113294324
Reviewed by Jonathan Bedard.
This relies on git rev-parse --show-toplevel to instead find the
top-level directory of the working tree, and just stores the path from
there in the hooks.
* Tools/Scripts/hooks/pre-commit:
* Tools/Scripts/hooks/pre-push:
* Tools/Scripts/hooks/prepare-commit-msg:
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_hooks.py:
(InstallHooks.main):
Canonical link: https://commits.webkit.org/266577@main
Canonical link: https://commits.webkit.org/265870.514@safari-7616-branch
Commit: be254ee03f5d10b98e884c62e554b7f20a52bee0
https://github.com/WebKit/WebKit/commit/be254ee03f5d10b98e884c62e554b7f20a52bee0
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/local/git.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_git_lfs.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/install_git_lfs_unittest.py
Log Message:
-----------
Cherry-pick 267294 at main (72de90fb4130). rdar://114350561
[git-webkit] Update git lfs version
https://bugs.webkit.org/show_bug.cgi?id=260634
rdar://114350561
Reviewed by Dewei Zhu.
'git lfs' fixed an issue which broke DNS when on VPN on AppleSilicon.
Update to the newest version of 'git lfs'.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/mocks/local/git.py: Bump mock lfs version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_git_lfs.py:
(InstallGitLFS): Bump lfs version.
(InstallGitLFS.url): Handle trailing 0 in lfs version, use correct binary for architecture.
(InstallGitLFS.install): Handle trailing 0 in lfs version, handle new package format.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/install_git_lfs_unittest.py:
(TestInstallGitLFS.test_url): Bump lfs version
(TestInstallGitLFS.test_install): Ditto.
(TestInstallGitLFS.test_configure): Ditto.
(TestInstallGitLFS.test_no_op): Ditto.
(TestInstallGitLFS.test_no_repo): Ditto.
Canonical link: https://commits.webkit.org/267294@main
Canonical link: https://commits.webkit.org/265870.515@safari-7616-branch
Commit: 69862b66f32a3867cfd579c6520b0da1f3ab1e16
https://github.com/WebKit/WebKit/commit/69862b66f32a3867cfd579c6520b0da1f3ab1e16
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_hooks.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/install_hooks_unittest.py
Log Message:
-----------
Cherry-pick 267372 at main (981a048eebf4). rdar://114566642
[git-webkit] Handle existing symlink hooks
https://bugs.webkit.org/show_bug.cgi?id=260799
rdar://114566642
Reviewed by Dewei Zhu.
Some repositories use symlinks to configure hooks. Overwriting
these is usually wrong.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_hooks.py:
(InstallHooks.main): Warn user when hooks contain symlinks and do not overwrite them.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/install_hooks_unittest.py:
(TestInstallHooks.test_install_hook):
(TestInstallHooks.test_security_level_in_hook):
Canonical link: https://commits.webkit.org/267372@main
Canonical link: https://commits.webkit.org/265870.516@safari-7616-branch
Commit: a41bfada98a4e2561fe7c41d88c8f1919d144f32
https://github.com/WebKit/WebKit/commit/a41bfada98a4e2561fe7c41d88c8f1919d144f32
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/pull_request.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py
Log Message:
-----------
Cherry-pick 267409 at main (9f045b69d7e0). rdar://114593055
[git-webkit] Correctly parse EWS data in PR body
https://bugs.webkit.org/show_bug.cgi?id=260831
rdar://114593055
Reviewed by Aakash Jain.
Exclude EWS data when parsing PR bodies.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/pull_request.py:
(PullRequest): Expand regexes to match EWS data.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/pull_request_unittest.py:
Canonical link: https://commits.webkit.org/267409@main
Canonical link: https://commits.webkit.org/265870.517@safari-7616-branch
Commit: 1ac0ab91ab0d1a793d0a3f90269359a10e40e0db
https://github.com/WebKit/WebKit/commit/1ac0ab91ab0d1a793d0a3f90269359a10e40e0db
Author: Michael Catanzaro <mcatanzaro at redhat.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py
Log Message:
-----------
Cherry-pick 267415 at main (cb4faa2a3ee3). https://bugs.webkit.org/show_bug.cgi?id=260726
python autoinstaller is broken with python 3.12
https://bugs.webkit.org/show_bug.cgi?id=260726
Reviewed by Jonathan Bedard.
Currently git-webkit is broken with python 3.12 due to various problems
with dependencies that are already fixed in newer upstream versions. So,
update a few things.
Unfortunately, the newer library versions are incompatible with other
Python versions, so this means more conditional versions.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py:
Canonical link: https://commits.webkit.org/267415@main
Canonical link: https://commits.webkit.org/265870.518@safari-7616-branch
Commit: fda73a566760afc75aa56eb66b880772ae42779e
https://github.com/WebKit/WebKit/commit/fda73a566760afc75aa56eb66b880772ae42779e
Author: Michael Catanzaro <mcatanzaro at redhat.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py
Log Message:
-----------
Cherry-pick 267461 at main (160f1a456bf4). https://bugs.webkit.org/show_bug.cgi?id=260889
REGRESSION(267415 at main): Broke python autoinstaller for python 3.11
https://bugs.webkit.org/show_bug.cgi?id=260889
Reviewed by Jonathan Bedard.
All of these python libraries are quite interdependent. Apparently
beautifulsoup4 depends on functionality removed from the newer
setuptools.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py:
Canonical link: https://commits.webkit.org/267461@main
Canonical link: https://commits.webkit.org/265870.519@safari-7616-branch
Commit: 20d84ff40023973cc73601b309b31398254c8763
https://github.com/WebKit/WebKit/commit/20d84ff40023973cc73601b309b31398254c8763
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/setup.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/github_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/branch.py
Log Message:
-----------
Cherry-pick 267537 at main (0f288bbe5ec0). rdar://114272849
[git-webkit] Dupe CCed bug when racing bug importer
https://bugs.webkit.org/show_bug.cgi?id=260747
rdar://114272849
Reviewed by Aakash Jain.
In some situations, git-webkit ends up racing our bug importer.
In that case, take the radar created by our bug importer and dupe it
to the radar provided by the contributor.
* Tools/Scripts/libraries/webkitbugspy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py:
(Tracker.populate): Populate bug dupe status.
(Tracker.set): Allow for bug to be closed as a dupe.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/github.py:
(Tracker.set): Link closed bug to a dupe, if applicable.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py:
(Issue.__init__): Add _original value.
(Issue.close): Allow caller to close bug as a duplicate.
(Issue.original): Return the original bug, if closed as a dupe.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/bugzilla.py:
(Bugzilla._issue): Support duping.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py:
(RadarModel.__init__): Support duping.
(RadarModel.commit_changes): Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py:
(Tracker.populate): Populate bug dupe status.
(Tracker.set): Allow for bug to be closed as a dupe.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py:
(TestBugzilla.test_duplicate):
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/github_unittest.py:
(TestGitHub.test_duplicate):
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py:
(TestRadar.test_duplicate):
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/branch.py:
(Branch.main): If the cced radar and provided radar don't match, close the cced radar
as a dupe of the provided radar.
Canonical link: https://commits.webkit.org/267537@main
Canonical link: https://commits.webkit.org/265870.520@safari-7616-branch
Commit: d777376b511c28b3601dc5938c64225fffe7e677
https://github.com/WebKit/WebKit/commit/d777376b511c28b3601dc5938c64225fffe7e677
Author: Sam Sneddon <gsnedders at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py
Log Message:
-----------
Cherry-pick 267552 at main (d94691e07a31). https://bugs.webkit.org/show_bug.cgi?id=260997
Ensure AutoInstall.install_everything succeeds with implicit_deps
https://bugs.webkit.org/show_bug.cgi?id=260997
Reviewed by Jonathan Bedard.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py:
(AutoInstall.install_everything):
Canonical link: https://commits.webkit.org/267552@main
Canonical link: https://commits.webkit.org/265870.521@safari-7616-branch
Commit: cd9767bd25acd82b1ba9498a2b68bfa8abe8230f
https://github.com/WebKit/WebKit/commit/cd9767bd25acd82b1ba9498a2b68bfa8abe8230f
Author: Fujii Hironori <Hironori.Fujii at sony.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/hooks/prepare-commit-msg
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_hooks.py
Log Message:
-----------
Cherry-pick 267649 at main (662e3790e0b6). https://bugs.webkit.org/show_bug.cgi?id=261097
prepare-commit-msg hook doesn't generate a changed file list with Windows Git
https://bugs.webkit.org/show_bug.cgi?id=261097
Reviewed by Jonathan Bedard.
prepare-ChangeLog reproted "Can't locate VCSUtils.pm in @INC" error if
it was executed from prepare-commit-msg hook of Windows Git. It failed
to set a library path to 'Tools/Scripts' directory.
Windows Git includes msys perl. prepare-commit-msg hook unexpectedly
executed it. It should execute Windows Perl.
Use shutil.which to get perl's absolute path. But, it's available for
Python 3.3 or newer. Windows port developers have been switched to
Python 3. Use the original relative command name 'perl' for older
Python.
* Tools/Scripts/hooks/prepare-commit-msg:
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/install_hooks.py:
* (InstallHooks.main): Added a new template variable 'perl' to set
perl's absolute path.
Canonical link: https://commits.webkit.org/267649@main
Canonical link: https://commits.webkit.org/265870.522@safari-7616-branch
Commit: 9c83539b389c2d904643c1b3cd540bb21fdf62f7
https://github.com/WebKit/WebKit/commit/9c83539b389c2d904643c1b3cd540bb21fdf62f7
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/contributor.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/contributor_unittest.py
Log Message:
-----------
Cherry-pick 267702 at main (767f671b3873). rdar://114570779
[git-webkit] Recognize self in Bitbucket PRs
https://bugs.webkit.org/show_bug.cgi?id=260802
rdar://114570779
Reviewed by Dewei Zhu.
We should include the Bitbucket username in contributor objects returned
from Bitbucket APIs, so that `git-webkit pr` can recognize PRs uploaded
by the current user.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/contributor.py:
(Contributor.Mapping.create): Allow github and bitbucket usernames to be specified.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/remote/bitbucket.py:
(BitBucket.PRGenerator.PullRequest): Include Bitbucket username in contributor object.
(BitBucket.PRGenerator.update): Ditto.
(BitBucket.PRGenerator.comments): Ditto.
(BitBucket.commit): Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/test/contributor_unittest.py:
(TestContributor.test_github):
(TestContributor.test_bitbucket):
Canonical link: https://commits.webkit.org/267702@main
Canonical link: https://commits.webkit.org/265870.523@safari-7616-branch
Commit: 5a87cf9c496fd74c2de9d2d3fac03025b252436d
https://github.com/WebKit/WebKit/commit/5a87cf9c496fd74c2de9d2d3fac03025b252436d
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp
M Source/WebCore/Modules/mediarecorder/MediaRecorder.h
M Source/WebCore/Modules/mediarecorder/MediaRecorderProvider.cpp
M Source/WebCore/Modules/mediarecorder/MediaRecorderProvider.h
M Source/WebCore/loader/EmptyClients.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivate.h
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateAVFImpl.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateAVFImpl.h
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.h
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateMock.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateMock.h
M Source/WebCore/testing/Internals.cpp
M Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderPrivate.cpp
M Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderPrivate.h
M Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderProvider.cpp
M Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderProvider.h
Log Message:
-----------
Regression(264919 at main) Use-after-free of MediaRecorderPrivate in GPUProcessConnection::didClose()
https://bugs.webkit.org/show_bug.cgi?id=261224
rdar://114807341
Reviewed by Alex Christensen.
264919 at main made WebKit::MediaRecorderPrivate subclass ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr.
However, MediaRecorderPrivate is stored in std::unique_ptr<> throughout our code base, thus not obeying
the refcount when managing its lifetime. This was the source of use-after-frees in
GPUProcessConnection::didClose(), which held a strong Ref<> to the MediaRecorderPrivate but it wouldn't
prevent the object from dying.
To address the issue, we now use Ref<> / RefPtr<> everywhere for MediaRecorderPrivate. I also moved
ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr to the base class (WebCore::MediaRecorderPrivate) since
WebCore needs to know it can hold a Ref<> / RefPtr<> to such objects.
* Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp:
(WebCore::MediaRecorder::createMediaRecorderPrivate):
(WebCore::MediaRecorder::fetchData):
* Source/WebCore/Modules/mediarecorder/MediaRecorder.h:
* Source/WebCore/Modules/mediarecorder/MediaRecorderProvider.cpp:
(WebCore::MediaRecorderProvider::createMediaRecorderPrivate):
* Source/WebCore/Modules/mediarecorder/MediaRecorderProvider.h:
* Source/WebCore/loader/EmptyClients.cpp:
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivate.h:
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateAVFImpl.cpp:
(WebCore::MediaRecorderPrivateAVFImpl::create):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateAVFImpl.h:
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:
(WebCore::MediaRecorderPrivateGStreamer::create):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.h:
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateMock.cpp:
(WebCore::MediaRecorderPrivateMock::create):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateMock.h:
* Source/WebCore/testing/Internals.cpp:
(WebCore::createRecorderMockSource):
* Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderPrivate.cpp:
(WebKit::MediaRecorderPrivate::create):
* Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderPrivate.h:
* Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderProvider.cpp:
(WebKit::MediaRecorderProvider::createMediaRecorderPrivate):
* Source/WebKit/WebProcess/GPU/webrtc/MediaRecorderProvider.h:
Canonical link: https://commits.webkit.org/265870.524@safari-7616-branch
Commit: 7aeb4db0bda5c726bc99255ec332a365f3739fe5
https://github.com/WebKit/WebKit/commit/7aeb4db0bda5c726bc99255ec332a365f3739fe5
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebCore/Modules/websockets/WebSocket.cpp
Log Message:
-----------
Cherry-pick 30120862ed93. rdar://75425816
nullptr dereference in WebCore::WebSocket::close()
https://bugs.webkit.org/show_bug.cgi?id=261037
<rdar://75425816>
Reviewed by Alex Christensen.
* Source/WebCore/Modules/websockets/WebSocket.cpp:
(WebCore::WebSocket::close):
- Add `nullptr` check for `m_channel`.
Canonical link: https://commits.webkit.org/267575@main
Identifier: 265870.525 at safari-7616-branch
Commit: 91531afb6921d4b9c8c03691be671947277eee53
https://github.com/WebKit/WebKit/commit/91531afb6921d4b9c8c03691be671947277eee53
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.cpp
Log Message:
-----------
Cherry-pick df7a74a8f788. rdar://114795818
RemoteImageBufferProxy::ensureBackendCreated can wait for a message that isn't pending.
https://bugs.webkit.org/show_bug.cgi?id=261091
<rdar://114795818>
Reviewed by Kimmo Kinnunen.
Currently, we clear the backend in response to a GPUP clear, which calls prepareForBackingStoreChange.
That can trigger ensureBackendCreated if we didn't yet have a backend, which will wait for the original backend (from the crashed process),
but does so by forcing creation of the new GPUP. This message never arrives.
clearBackend doesn't need to call prepareForBackingStoreChange if we didn't have a backend yet.
* Source/WebKit/WebProcess/GPU/graphics/RemoteImageBufferProxy.cpp:
(WebKit::RemoteImageBufferProxy::clearBackend):
Canonical link: https://commits.webkit.org/267619@main
Identifier: 265870.526 at safari-7616-branch
Commit: 01a539340488df745cccc9032bc5b1aba473aa13
https://github.com/WebKit/WebKit/commit/01a539340488df745cccc9032bc5b1aba473aa13
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebCore/platform/audio/ios/AudioSessionIOS.mm
Log Message:
-----------
Cherry-pick f9b6f9288501. rdar://114802443
[iOS] Don't crash if -[LSBundleProxy bundleIdentifier] returns nil
https://bugs.webkit.org/show_bug.cgi?id=261162
rdar://114802443
Reviewed by Andy Estes.
(WebCore::AudioSessionIOS::setHostProcessAttribution): Log an error message and return
early if -[LSBundleProxy bundleIdentifier] returns nil.
Canonical link: https://commits.webkit.org/267659@main
Identifier: 265870.527 at safari-7616-branch
Commit: 798c698f9b5be7ab4f966563a3c18fcf9585e1b6
https://github.com/WebKit/WebKit/commit/798c698f9b5be7ab4f966563a3c18fcf9585e1b6
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebKit/Configurations/WebKit.xcconfig
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Source/WebKit/Platform/spi/visionos/MRUIKitSPI.h
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm
Log Message:
-----------
Cherry-pick 5d4cdbee487c. rdar://114793136
[visionOS] System chrome autohides while resizing or repositioning fullscreen video
https://bugs.webkit.org/show_bug.cgi?id=261176
rdar://114793136
Reviewed by Tim Horton.
266191 at main made system chrome autohide alongside WebKit's controls in fullscreen.
However, autohide is currently not prevented while the user is interacting with
system chrome, resulting in a poor experience.
To fix, listen for notifications that indicate system chrome is being used. If
it is, reset the autohide timer.
* Source/WebKit/Configurations/WebKit.xcconfig:
Link MRUIKit, as the scene positioning notification comes from there.
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Source/WebKit/Platform/spi/visionos/MRUIKitSPI.h:
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenViewController.mm:
Drive-by: Drop 'm_' from an Objective-C instance variable.
(-[WKFullScreenViewController initWithWebView:]):
(-[WKFullScreenViewController hideUI]):
(-[WKFullScreenViewController videoControlsManagerDidChange]):
(-[WKFullScreenViewController hideCustomControls:]):
(-[WKFullScreenViewController _didBeginInteractionWithSystemChrome:]):
(-[WKFullScreenViewController _didEndInteractionWithSystemChrome:]):
Canonical link: https://commits.webkit.org/267661@main
Identifier: 265870.528 at safari-7616-branch
Commit: f623dca74aeb42f318eaba42bf98dda5f21ac93e
https://github.com/WebKit/WebKit/commit/f623dca74aeb42f318eaba42bf98dda5f21ac93e
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm
Log Message:
-----------
Cherry-pick 6f953477b997. rdar://114552141
Crash under -[NSEvent _trackSwipeEventWithOptions:dampenAmountThresholdMin:max:trackingDistance:axis:velocityFilterClass:usingHandler:]
https://bugs.webkit.org/show_bug.cgi?id=261174
rdar://114552141
Reviewed by Tim Horton.
AppKit is throwing an exception for some reason about the event type or phase, but it's not clear why.
For now, just catch the exception.
* Source/WebKit/UIProcess/mac/ViewGestureControllerMac.mm:
(WebKit::ViewGestureController::trackSwipeGesture):
Canonical link: https://commits.webkit.org/267673@main
Identifier: 265870.529 at safari-7616-branch
Commit: f4740a8c448ab1425b79013689ae1ac5da1414cf
https://github.com/WebKit/WebKit/commit/f4740a8c448ab1425b79013689ae1ac5da1414cf
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/FrameLoadState.cpp
M Source/WebKit/UIProcess/PageLoadState.cpp
Log Message:
-----------
Cherry-pick 648f84844d05. rdar://113459568
Crash under NavigationState::NavigationClient::didCommitNavigation()
https://bugs.webkit.org/show_bug.cgi?id=261172
rdar://113459568
Reviewed by Sihui Liu.
The crash in the wild seems to indicate that WKFrameCopyURL() may return null
when called from the didCommitLoadForFrame() navigation delegate. It seems
unexpected for the committed URL to be null when we've just committed a load
in the frame.
I have not been able to reproduce the issue with our tests or regular browsing
so I am adding assertions and defaulting the committed URL to "about:blank" if
it is null upon commit.
* Source/WebKit/UIProcess/FrameLoadState.cpp:
(WebKit::FrameLoadState::didExplicitOpen):
(WebKit::FrameLoadState::didCommitLoad):
(WebKit::FrameLoadState::didSameDocumentNotification):
* Source/WebKit/UIProcess/PageLoadState.cpp:
(WebKit::PageLoadState::commitChanges):
Canonical link: https://commits.webkit.org/267696@main
Identifier: 265870.530 at safari-7616-branch
Commit: 9c55a4993f35d22bb15e4e7f34758a7c945ffc7d
https://github.com/WebKit/WebKit/commit/9c55a4993f35d22bb15e4e7f34758a7c945ffc7d
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp
Log Message:
-----------
Cherry-pick 241b0674d6de. rdar://106547410
Crash under ScrollingStateStickyNode::reconcileLayerPositionForViewportRect()
https://bugs.webkit.org/show_bug.cgi?id=261170
rdar://106547410
Reviewed by Wenson Hsieh.
Crash data suggest that the graphicsLayer can be null, so add a null check (and assert so if anyone sees this
in a debug build, we can analyze it).
* Source/WebCore/page/scrolling/ScrollingStateStickyNode.cpp:
(WebCore::ScrollingStateStickyNode::reconcileLayerPositionForViewportRect):
Canonical link: https://commits.webkit.org/267700@main
Identifier: 265870.531 at safari-7616-branch
Commit: dc9feeb1f59676bee2cbda5ad5df4340218efeec
https://github.com/WebKit/WebKit/commit/dc9feeb1f59676bee2cbda5ad5df4340218efeec
Author: Robert Jenner <jenner at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Tools/Scripts/webkitpy/layout_tests/controllers/manager.py
Log Message:
-----------
Cherry-pick 267745 at main (6407ddd51d28). rdar://114782178
Limit amount of workers to 1 when re-running iOS tests for iPad specific platforms
https://bugs.webkit.org/show_bug.cgi?id=261175
rdar://114782178
Reviewed by Jonathan Bedard.
Limit number of simulators booted for iPad testing to one in order to not overload systems with too many booted simulator instances.
* Tools/Scripts/webkitpy/layout_tests/run_webkit_tests_integrationtest.py:
(RunTest.test_ipad_test_division):
Canonical link: https://commits.webkit.org/267745@main
Canonical link: https://commits.webkit.org/265870.532@safari-7616-branch
Commit: f5992c6c284833f97ad47e96f5e40e6375dd5b0a
https://github.com/WebKit/WebKit/commit/f5992c6c284833f97ad47e96f5e40e6375dd5b0a
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
M Source/JavaScriptCore/wasm/WasmWorklist.cpp
M Source/JavaScriptCore/wasm/WasmWorklist.h
M Source/WTF/wtf/StdLibExtras.h
M Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.cpp
M Source/WebCore/Modules/push-api/ServiceWorkerRegistrationPushAPI.cpp
M Source/WebCore/css/CSSGroupingRule.cpp
M Source/WebCore/css/CSSKeyframesRule.cpp
M Source/WebCore/css/CSSStyleRule.cpp
M Source/WebCore/dom/DataTransfer.cpp
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Element.cpp
M Source/WebCore/html/HTMLAnchorElement.cpp
M Source/WebCore/html/HTMLCanvasElement.cpp
M Source/WebCore/html/HTMLFormElement.cpp
M Source/WebCore/html/HTMLIFrameElement.cpp
M Source/WebCore/html/HTMLLinkElement.cpp
M Source/WebCore/html/HTMLOutputElement.cpp
M Source/WebCore/svg/SVGAElement.cpp
M Source/WebCore/xml/XMLHttpRequest.cpp
M Source/WebKit/WebProcess/GPU/GPUProcessConnection.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteImageDecoderAVFManager.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteImageDecoderAVFManager.h
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.cpp
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebProcess.cpp
M Source/WebKit/WebProcess/WebProcess.h
M Tools/TestWebKitAPI/Tests/WTF/HashMap.cpp
M Tools/TestWebKitAPI/Tests/WTF/HashSet.cpp
M Tools/TestWebKitAPI/Tests/WTF/RobinHoodHashMap.cpp
M Tools/TestWebKitAPI/Tests/WTF/RobinHoodHashSet.cpp
Log Message:
-----------
Fix bad cases of refcounted objects being stored in std::unique_ptr
https://bugs.webkit.org/show_bug.cgi?id=261280
rdar://115122287
Reviewed by David Kilzer and Alex Christensen.
In Bug 261224, I fixed a security bug where an object was refcounted but was
incorrectly stored in a std::unique_ptr<>, leading to use-after-frees.
In this patch, I am adding a check to WTF::makeUnique<T>() to fail if T::ref()
exists. This founds bugs / unsafe code, which I am fixing in this patch.
There is also a common pattern in our code where an object implements ref() &
deref() to forward the refcounting to their owner. In turn, the owner then owns
the object via a std::unique_ptr<>. This is obviously tripping my check and yet
this is usually safe. As a result, I am introducing a
makeUniqueWithoutRefCountedCheck() for these cases.
* Source/JavaScriptCore/wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::Worklist):
* Source/JavaScriptCore/wasm/WasmWorklist.h:
* Source/WTF/wtf/StdLibExtras.h:
(WTF::makeUnique):
(WTF::makeUniqueWithoutRefCountedCheck):
(WTF::makeUniqueWithoutFastMallocCheck):
* Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.cpp:
(WebCore::IDBClient::IDBConnectionToServer::IDBConnectionToServer):
* Source/WebCore/Modules/push-api/ServiceWorkerRegistrationPushAPI.cpp:
(WebCore::ServiceWorkerRegistrationPushAPI::pushManager):
* Source/WebCore/css/CSSGroupingRule.cpp:
(WebCore::CSSGroupingRule::cssRules const):
* Source/WebCore/css/CSSKeyframesRule.cpp:
(WebCore::CSSKeyframesRule::cssRules):
* Source/WebCore/css/CSSStyleRule.cpp:
(WebCore::CSSStyleRule::cssRules const):
* Source/WebCore/dom/DataTransfer.cpp:
(WebCore::DataTransfer::items):
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::implementation):
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::attributes const):
(WebCore::Element::classList):
(WebCore::Element::part):
(WebCore::Element::dataset):
(WebCore::Element::ensureFormAssociatedCustomElement):
* Source/WebCore/html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::relList):
* Source/WebCore/html/HTMLCanvasElement.cpp:
(WebCore::HTMLCanvasElement::transferControlToOffscreen):
* Source/WebCore/html/HTMLFormElement.cpp:
(WebCore::HTMLFormElement::relList):
* Source/WebCore/html/HTMLIFrameElement.cpp:
(WebCore::HTMLIFrameElement::sandbox):
* Source/WebCore/html/HTMLLinkElement.cpp:
(WebCore::HTMLLinkElement::sizes):
(WebCore::HTMLLinkElement::relList):
* Source/WebCore/html/HTMLOutputElement.cpp:
(WebCore::HTMLOutputElement::htmlFor):
* Source/WebCore/svg/SVGAElement.cpp:
(WebCore::SVGAElement::relList):
* Source/WebCore/xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::upload):
* Source/WebKit/WebProcess/GPU/GPUProcessConnection.cpp:
(WebKit::GPUProcessConnection::mediaPlayerManager):
(WebKit::GPUProcessConnection::dispatchMessage):
* Source/WebKit/WebProcess/GPU/media/RemoteImageDecoderAVFManager.cpp:
(WebKit::RemoteImageDecoderAVFManager::create):
(WebKit::RemoteImageDecoderAVFManager::RemoteImageDecoderAVFManager): Deleted.
(WebKit::RemoteImageDecoderAVFManager::supplementName): Deleted.
* Source/WebKit/WebProcess/GPU/media/RemoteImageDecoderAVFManager.h:
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.cpp:
(WebKit::RemoteMediaPlayerManager::create):
(WebKit::RemoteMediaPlayerManager::RemoteMediaPlayerManager): Deleted.
(WebKit::RemoteMediaPlayerManager::~RemoteMediaPlayerManager): Deleted.
(WebKit::RemoteMediaPlayerManager::supplementName): Deleted.
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerManager.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::updatePreferences):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::WebProcess):
(WebKit::WebProcess::initializeWebProcess):
* Source/WebKit/WebProcess/WebProcess.h:
(WebKit::WebProcess::remoteMediaPlayerManager):
(WebKit::WebProcess::remoteImageDecoderAVFManager):
* Tools/TestWebKitAPI/Tests/WTF/RobinHoodHashMap.cpp:
(TestWebKitAPI::TEST):
* Tools/TestWebKitAPI/Tests/WTF/RobinHoodHashSet.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/265870.533@safari-7616-branch
Commit: 3be781681be09afc19e2ea914592b9a71a9ad010
https://github.com/WebKit/WebKit/commit/3be781681be09afc19e2ea914592b9a71a9ad010
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-07 (Thu, 07 Sep 2023)
Changed paths:
A LayoutTests/webaudio/audioworklet-bad-array-type-expected.txt
A LayoutTests/webaudio/audioworklet-bad-array-type.html
A LayoutTests/webaudio/bad-array-type-processor.js
M Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp
Log Message:
-----------
Bad jsCast<>() in copyDataFromJSArrayToBuses() in AudioWorkletProcessor.cpp
https://bugs.webkit.org/show_bug.cgi?id=261289
rdar://115042475
Reviewed by Ryosuke Niwa.
Use jsDynamicCast<>() instead of jsCast<>() in AudioWorkletProcessor.cpp for
safety.
* LayoutTests/webaudio/audioworklet-bad-array-type-expected.txt: Added.
* LayoutTests/webaudio/audioworklet-bad-array-type.html: Added.
* LayoutTests/webaudio/bad-array-type-processor.js: Added.
(CustomProcessor.prototype.process):
(CustomProcessor):
* Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp:
(WebCore::toJSArray):
(WebCore::toJSObject):
(WebCore::copyDataFromJSArrayToBuses):
(WebCore::AudioWorkletProcessor::process):
Canonical link: https://commits.webkit.org/265870.534@safari-7616-branch
Commit: 049d074c4b1b4e923b9aa7332e598203757255d9
https://github.com/WebKit/WebKit/commit/049d074c4b1b4e923b9aa7332e598203757255d9
Author: Alexey Shvayka <ashvayka at apple.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
A JSTests/stress/regress-114860483.js
M Source/JavaScriptCore/runtime/JSObject.cpp
M Source/JavaScriptCore/runtime/JSObjectInlines.h
Log Message:
-----------
JSObject::anyObjectInChainMayInterceptIndexedAccesses and JSObject::didBecomePrototype need to account for JSGlobalProxy
https://bugs.webkit.org/show_bug.cgi?id=261287
rdar://114860483
Reviewed by Yusuke Suzuki.
Since JSObject::anyObjectInChainMayInterceptIndexedAccesses() walks up the [[Prototype]] chain,
whenever an indexed property is defined on a JSGlobalObject, we should add MayHaveIndexedAccessors
flag to JSGlobalProxy instead.
Currently, mayInterceptIndexedAccesses() is never queried on JSGlobalObject instances.
This change also fixes mayBePrototype() to be queried from JSGlobalProxy rather than JSGlobalObject,
which is correct given setPrototypeDirect() used to call didBecomePrototype() only on the proxy.
However, for extra robustness, this we propagate didBecomePrototype() to the global object as well.
* JSTests/stress/regress-114860483.js: Added.
* Source/JavaScriptCore/runtime/JSObjectInlines.h:
(JSC::JSObject::didBecomePrototype):
* Source/JavaScriptCore/runtime/JSObject.cpp:
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
Canonical link: https://commits.webkit.org/265870.535@safari-7616-branch
Commit: 6d865c4bf3da0458146cfc52d994578cbdbc0f42
https://github.com/WebKit/WebKit/commit/6d865c4bf3da0458146cfc52d994578cbdbc0f42
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-09-09 (Sat, 09 Sep 2023)
Changed paths:
A LayoutTests/animations/resolve-animation-should-not-execute-scripts-expected.txt
A LayoutTests/animations/resolve-animation-should-not-execute-scripts.html
M LayoutTests/platform/ios/imported/w3c/web-platform-tests/screen-orientation/active-lock-expected.txt
M Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp
M Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp
M Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp
M Source/WebCore/animation/WebAnimation.cpp
M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
M Source/WebCore/dom/TaskSource.h
M Source/WebCore/page/ScreenOrientation.cpp
Log Message:
-----------
ScriptDisallowedScope bypass via a `then` getter in Document::updateStyleIfNeeded
https://bugs.webkit.org/show_bug.cgi?id=261256
<rdar://114545310>
Reviewed by Ryosuke Niwa.
This PR addresses several bugs:
1. There is a ScriptDisallowedScope bypass via DeferredPromise::callFunction.
2. WebAnimation::resolve() tries to execute scripts by rejecting promises during updateStyle.
3. WebAnimation::cancel() and WebAnimation::resetPendingTasks() also tries to execute scripts by
rejecting promises during updateStyle.
4. PaymentRequest and PaymentResponse try to reject promises during active DOM object suspension
as well as the script execution context is being stopped.
5. WebAudio tries to reject promises during active DOM object suspension.
For (1), this PR adds a release assertion in DeferredPromise::callFunction like the one we have in
ScriptController::canExecuteScripts. Note this has to be a thread safe variant since this code can be
executed in a worker thread.
For (2), this PR makes WebAnimation::resolve call updateFinishedState with SynchronouslyNotify::No
instead of SynchronouslyNotify::Yes. Note that in the spec [1], the only scenario in which this flag
is set to yes is when the author script calls finish() on an Animation object.
For (3), (4), and (5), this PR makes these actions asynchronous by scheduling a task / microtask
instead of synchronously rejecting promises.
[1] https://drafts.csswg.org/web-animations-1/#update-an-animations-finished-state
Based on original patch by Ryosuke Niwa.
* LayoutTests/animations/resolve-animation-should-not-execute-scripts-expected.txt: Added.
* LayoutTests/animations/resolve-animation-should-not-execute-scripts.html: Added.
* Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp:
(WebCore::PaymentRequest::~PaymentRequest): Now allows pending activity to exist when the associated
script execution context had been stopped.
(WebCore::PaymentRequest::stop): Don't try to settle the promise in the middle of stopping this
active DOM object.
(WebCore::PaymentRequest::suspend): Ditto for suspension. Schedule a task to settle promise instead.
* Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp:
(WebCore::PaymentResponse::~PaymentResponse): Now allows pending activity to exist when
the associated script execution context had been stopped.
(WebCore::PaymentResponse::suspend): Don't try to settle the promise in the middle of stopping this
active DOM object.
* Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp:
(WebCore::OfflineAudioContext::uninitialize): Don't reject the promise when the active DOM objects
had already been stopped.
* Source/WebCore/animation/WebAnimation.cpp:
(WebCore::WebAnimation::cancel): Reject the finished promise in a newly scheduled task instead of
synchronously rejecting it, which would result in script execution.
(WebCore::WebAnimation::resolve): Resolve the promise asynchronously.
* Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
(WebCore::DeferredPromise::callFunction): Added a release assertion.
* Source/WebCore/dom/TaskSource.h:
Canonical link: https://commits.webkit.org/265870.536@safari-7616-branch
Commit: 9c1f377498c24268fb26589ad76878a56787703c
https://github.com/WebKit/WebKit/commit/9c1f377498c24268fb26589ad76878a56787703c
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-09 (Sat, 09 Sep 2023)
Changed paths:
M Source/WTF/wtf/Algorithms.h
M Source/WebCore/platform/audio/AudioArray.h
M Source/WebCore/platform/audio/AudioBus.cpp
M Source/WebCore/platform/audio/AudioChannel.h
M Source/WebCore/platform/audio/MultiChannelResampler.cpp
M Source/WebCore/platform/audio/MultiChannelResampler.h
M Source/WebCore/platform/audio/SincResampler.cpp
M Source/WebCore/platform/audio/SincResampler.h
Log Message:
-----------
Security hardening for SincResampler
https://bugs.webkit.org/show_bug.cgi?id=261317
rdar://105650262
Reviewed by David Kilzer and Darin Adler.
Do security hardening for SincResampler as we have evidence that we're getting
the logic wrong in some cases and doing a heap-buffer overflow WRITE.
This patch updates SincResampler to use `std::span<float>` instead of `float*` and
to leverage new memcpySpans() / memsetSpan() functions
I added to WTF.
This had several benefits:
- Using std::span means we don't lose tracks of our buffer bounds so we can do
extra bounds checks.
- We benefit from std::span's bounds checks too which are already enabled on trunk
via `-D_LIBCPP_ENABLE_ASSERTIONS=1`. Those checks apply to subspan() and operator[]
in particular, both of which are used by SincResampler.
* Source/WTF/WTF.xcodeproj/project.pbxproj:
* Source/WTF/wtf/Algorithms.h:.
(WTF::memcpySpans):
(WTF::memsetSpan):
* Source/WebCore/platform/audio/AudioArray.h:
(WebCore::AudioArray::toSpan):
(WebCore::AudioArray::toSpan const):
* Source/WebCore/platform/audio/AudioBus.cpp:
(WebCore::AudioBus::createBySampleRateConverting):
* Source/WebCore/platform/audio/AudioChannel.h:
* Source/WebCore/platform/audio/MultiChannelResampler.cpp:
(WebCore::MultiChannelResampler::process):
(WebCore::MultiChannelResampler::provideInputForChannel):
* Source/WebCore/platform/audio/MultiChannelResampler.h:
* Source/WebCore/platform/audio/SincResampler.cpp:
(WebCore::SincResampler::SincResampler):
(WebCore::SincResampler::updateRegions):
(WebCore::SincResampler::processBuffer):
(WebCore::SincResampler::process):
* Source/WebCore/platform/audio/SincResampler.h:
Canonical link: https://commits.webkit.org/265870.537@safari-7616-branch
Commit: 1c1eb5533daf0e96e53a53da0f7abac32bf82055
https://github.com/WebKit/WebKit/commit/1c1eb5533daf0e96e53a53da0f7abac32bf82055
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.6
Identifier: 265870.538 at safari-7616-branch
Commit: fb62585509250ea3d0b8585a91e8e1c72ded8f05
https://github.com/WebKit/WebKit/commit/fb62585509250ea3d0b8585a91e8e1c72ded8f05
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/graphics/MediaPlayer.cpp
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.messages.in
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.h
M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.serialization.in
Log Message:
-----------
Cherry-pick 939ec6849c62. rdar://114594559
Cherry-pick 267723 at main (939ec6849c62). rdar://114594559
REGRESSION(267279 at main): [ macOS wk2 ] imported/w3c/web-platform-tests/media-source/mediasource-play-then-seek-back.html is a consistent text failure.
https://bugs.webkit.org/show_bug.cgi?id=260833
rdar://114594559
Reviewed by Jer Noble.
The `seeked` event wasn't received by the test as expected.
There were multiple reasons for this to occur:
1- The content processed assumed that the first timeUpdate message received
from the GPU process indicated that the pending seek operation had completed.
However, this wasn't always the case as timeUpdate can be send from the GPU
to the CP outside seeking (when playback has started and currentTime as progressed,
when playback has reached the end, when playback has skipped a gap etc)
Those messages are sent asynchronously from the GPU to the CP and could
have been received after the CP had started seeking, it would
incorrectly link this message to the end of the seek operation. So we
add a new IPC message `seeked` to no longer link seeking to timeUpdate and
uniquely identifies when the seek operation has been completed.
We only need to deal with this new event when the GPU process is involved
as when there's no GPU process seek/timeupdate are properly matched.
2- The MediaPlayerPrivateMediaSourceAVFObjC implementation was waiting
for a callback from the AVSampleBufferRenderSynchronizer after the seek
to complete the seek operation. However, if we seeked to the same location
as what the current time is, no callback occured. The code compared the
synchronizer's "timeBase" vs currentTime.
There is an extra issue with the test itself, it always assumes that the
`seeked` event will be fired in a different event loop that fired the
`seeking` event. The fixes above avoid this problem for now.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::seeked):
* Source/WebCore/platform/graphics/MediaPlayer.h:
(WebCore::MediaPlayerClient::mediaPlayerSeeked):
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::seekToTarget):
(WebCore::MediaPlayerPrivateAVFoundation::seekCompleted):
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekInternal):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekCompleted):
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm:
(WebCore::MediaPlayerPrivateWebM::seekToTarget):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::seekToTarget):
(WebCore::MediaPlayerPrivateGStreamer::timeChanged):
(WebCore::MediaPlayerPrivateGStreamer::finishSeek):
(WebCore::MediaPlayerPrivateGStreamer::didEnd):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::propagateReadyStateToPlayer):
(WebCore::MediaPlayerPrivateGStreamerMSE::asyncStateChangeDone):
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp:
(WebCore::MockMediaPlayerMediaSource::seekToTarget):
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp:
(WebKit::RemoteMediaPlayerProxy::seekToTarget):
(WebKit::RemoteMediaPlayerProxy::mediaPlayerSeeked):
(WebKit::RemoteMediaPlayerProxy::updateCachedState):
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h:
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:
(WebKit::MediaPlayerPrivateRemote::seekToTarget): Add logging.
(WebKit::MediaPlayerPrivateRemote::setReadyState): Add logging.
(WebKit::MediaPlayerPrivateRemote::readyStateChanged): Add logging.
(WebKit::MediaPlayerPrivateRemote::seeked):
(WebKit::MediaPlayerPrivateRemote::timeChanged): Add logging.
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h:
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.messages.in:
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.h: Remove the seeking
attribute. It is no longer needed as "seeked" as its own IPC message.
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerState.serialization.in:
Canonical link: https://commits.webkit.org/267723@main
Identifier: 265870.539 at safari-7616-branch
Commit: f68332942a13458ca3ea1faedc52243467da8890
https://github.com/WebKit/WebKit/commit/f68332942a13458ca3ea1faedc52243467da8890
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WKContentView.h
M Source/WebKit/UIProcess/ios/WKContentView.mm
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/UIProcess/mac/TiledCoreAnimationDrawingAreaProxy.mm
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h
M Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm
Log Message:
-----------
Cherry-pick 0de5d9cf8395. rdar://113771996
Cherry-pick 267652 at main (0de5d9cf8395). rdar://113771996
When releasing a resize in full screen video, the video content briefly flashes to its original size
https://bugs.webkit.org/show_bug.cgi?id=260558
rdar://113771996
Reviewed by Tim Horton.
When releasing a resize of a window on visionOS that contains a fixed-position element, the element's size
briefly becomes its original size.
In `_endLiveResize`, we create a snapshot view and put it on top of the web content. The snapshot is then
removed in the completion handler of a `doAfterNextPresentationUpdate` call.
However, by the time the transaction commit happens in the presentation update, two important
updates have yet to happen:
1. A visible content rect update
2. A geometry update
The visible content rect update needs to happen before the commit so that all the new sizes are updated.
However, `doAfterNextPresentationUpdate` does not ensure this. To fix, bundle a VCR update inside the
`UpdateGeometry` message, and then have the web page update the VCRs when receiving the message.
The geometry update of the drawing area was not happening because its size was never being set. When a
geometry uodate is deferred, `_frameOrBoundsMayHaveChanged` skips setting all the relevant new values.
Instead, all these values are (theoretically) set in `_didStopDeferringGeometryUpdates`. However,
`_didStopDeferringGeometryUpdates` was missing setting the size of the drawing area.
As a result, in `sendUpdateGeometry`, the layout size and other changes were being updated, but the
drawing area size was the old value. It then eventually does get updated on the next UIKit layout via
`frameOrBoundsMayHaveChanged`, but by that point the snapshot view has already been removed.
Fix by simply ensuring that `_didStopDeferringGeometryUpdates` also updates the drawing area size.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.h:
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _createVisibleRectUpdateInfo]):
(-[WKWebView _didStopDeferringGeometryUpdates]):
* Source/WebKit/UIProcess/PageClient.h:
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
(WebKit::RemoteLayerTreeDrawingAreaProxy::setLastVisibleContentRectUpdate):
(WebKit::RemoteLayerTreeDrawingAreaProxy::lastVisibleContentRectUpdate const):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::sendUpdateGeometry):
* Source/WebKit/UIProcess/ios/PageClientImplIOS.h:
* Source/WebKit/UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::createVisibleRectUpdateInfo):
* Source/WebKit/UIProcess/ios/WKContentView.h:
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView createVisibleRectUpdateInfoFromVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:viewStability:enclosedInScrollableAncestorView:sendEvenIfUnchanged:]):
(-[WKContentView didUpdateVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:viewStability:enclosedInScrollableAncestorView:sendEvenIfUnchanged:]):
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
* Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h:
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::updateGeometry):
Canonical link: https://commits.webkit.org/267652@main
Identifier: 265870.540 at safari-7616-branch
Commit: 08797fb3b3860b359bf67144123acece62005169
https://github.com/WebKit/WebKit/commit/08797fb3b3860b359bf67144123acece62005169
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentView.mm
Log Message:
-----------
Cherry-pick 663e5ddde8a7. rdar://113771996
Unreviewed, fix catalyst build
https://bugs.webkit.org/show_bug.cgi?id=261211
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView createVisibleContentRectUpdateInfoFromVisibleRect:unobscuredRect:contentInsets:unobscuredRectInScrollViewCoordinates:obscuredInsets:unobscuredSafeAreaInsets:inputViewBounds:scale:minimumScale:viewStability:enclosedInScrollableAncestorView:sendEvenIfUnchanged:]):
Canonical link: https://commits.webkit.org/267680@main
Identifier: 265870.541 at safari-7616-branch
Commit: e2be950af5f81e7d09920efe58f3a196c99a12fc
https://github.com/WebKit/WebKit/commit/e2be950af5f81e7d09920efe58f3a196c99a12fc
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
A JSTests/stress/object-assign-empty.js
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/ftl/FTLAbstractHeapRepository.h
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/heap/TinyBloomFilter.h
M Source/JavaScriptCore/runtime/Structure.h
Log Message:
-----------
Cherry-pick fcd2b898ec08. rdar://114990534
[JSC] Object.assign empty object optimization should check seenProperties instead of propertyHash
https://bugs.webkit.org/show_bug.cgi?id=261303
rdar://114990534
Reviewed by Mark Lam.
While seenProperties are monotonically increasing field with all the past possible property uids,
propertyHash is xor-ed past hash of properties. This means that we can accidentally hit 0 even though
we have actual properties. We should check seenProperties for quick check of emptiness of objects
instead of propertyHash.
* JSTests/stress/object-assign-empty.js: Added.
(shouldBe):
(test):
(i.shouldBe.JSON.stringify.test):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/ftl/FTLAbstractHeapRepository.h:
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileObjectAssign):
* Source/JavaScriptCore/heap/TinyBloomFilter.h:
(JSC::TinyBloomFilter::offsetOfBits):
* Source/JavaScriptCore/runtime/Structure.h:
(JSC::Structure::seenPropertiesOffset):
Canonical link: https://commits.webkit.org/267762@main
Identifier: 265870.542 at safari-7616-branch
Commit: 1c562e89aa308f71d1caa1deffe9e76ddbb91128
https://github.com/WebKit/WebKit/commit/1c562e89aa308f71d1caa1deffe9e76ddbb91128
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebCore/Modules/webxr/WebXRSession.cpp
Log Message:
-----------
Apply patch. rdar://115122287
Identifier: 265870.543 at safari-7616-branch
Commit: 5a36d0cc7c4c9cdef9e4a11667d06506d73f01e7
https://github.com/WebKit/WebKit/commit/5a36d0cc7c4c9cdef9e4a11667d06506d73f01e7
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebKit/Configurations/WebKit.xcconfig
Log Message:
-----------
Cherry-pick d192a5a8745c. rdar://115202809
Fix the visionOS build
https://bugs.webkit.org/show_bug.cgi?id=261369
rdar://115202809
Reviewed by Tim Horton.
* Source/WebKit/Configurations/WebKit.xcconfig:
Use `-weak_framework` to link MRUIKit, since the framework is not present in all configurations.
Canonical link: https://commits.webkit.org/267826@main
Identifier: 265870.544 at safari-7616-branch
Commit: 39d4c9b64f399885fb6351d1cb8bb40a1b1191fd
https://github.com/WebKit/WebKit/commit/39d4c9b64f399885fb6351d1cb8bb40a1b1191fd
Author: hoffmanjoshua <jhoffman23 at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
A LayoutTests/accessibility/ios-simulator/aria-details-toggle-summary-expected.txt
A LayoutTests/accessibility/ios-simulator/aria-details-toggle-summary.html
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp
M Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h
M Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl
M Tools/WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm
Log Message:
-----------
Cherry-pick 2bd294b77186. rdar://109684906
AX: iOS VO+Safari does not read <summary> role or state
https://bugs.webkit.org/show_bug.cgi?id=257162
rdar://109684906
Reviewed by Chris Fleizach.
This patch fixes the calculation for AccessibilityObject::supportsExpanded() so that <summary> elements
describe their state when using iOS voiceover. For <details> elements, we cannot rely on checking the
aria-expanded attribute since that does not exist on details elements (the attribute 'open' is used instead).
This affects <summary> elements as they use their <detail> parents to calculate accessibilitySupportsARIAExpanded().
iOS AX tests were also added to confirm that this is the case.
* Source/WebCore/accessibility/AccessibilityObject.cpp:
Update AccessibilityObject::supportsExpanded().
* Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:
* Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
* Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
* Tools/WebKitTestRunner/InjectedBundle/ios/AccessibilityUIElementIOS.mm:
Expose method for testing.
* LayoutTests/accessibility/ios-simulator/aria-details-toggle-summary-expected.txt:
* LayoutTests/accessibility/ios-simulator/aria-details-toggle-summary.html:
New test for checking isExpanded, supportsExpanded.
Canonical link: https://commits.webkit.org/267635@main
Identifier: 265870.545 at safari-7616-branch
Commit: 228a79d0039c26053199a8977e269bb1f5bd199c
https://github.com/WebKit/WebKit/commit/228a79d0039c26053199a8977e269bb1f5bd199c
Author: Dean Jackson <dino at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm
M Source/WebKit/UIProcess/SystemPreviewController.h
Log Message:
-----------
Cherry-pick 8c3dd61568c9. rdar://114172309
Seeing 5 windows opened, even though only tapped on 3 model links from Safari
https://bugs.webkit.org/show_bug.cgi?id=261232
rdar://114172309
Reviewed by Mike Wyrzykowski.
On iOS the AR Quick Look feature is modal, which means only one preview
is open at a time. On visionOS the preview opens in a separate app, allowing
for the case where the user can tap many times and multiple windows open.
Furthermore, the communication with the system is a bit limited, which
can create a situation where more windows open than the user requested.
Limit this so that only one Quick Look can be downloading at a time. This
will still allow the user to open multiple models, but not get into this
confusing situation.
It isn't a great fix. A future change would be to keep a list of
active previews, with an upper limit, so that the user isn't blocked
from opening another file while a large file is being downloaded.
* Source/WebKit/UIProcess/Cocoa/SystemPreviewControllerCocoa.mm:
* Source/WebKit/UIProcess/SystemPreviewController.h:
Canonical link: https://commits.webkit.org/267708@main
Identifier: 265870.546 at safari-7616-branch
Commit: 4abcf922731f71bdbb6483604e45fe4576ad0dd7
https://github.com/WebKit/WebKit/commit/4abcf922731f71bdbb6483604e45fe4576ad0dd7
Author: Tim Horton <thorton at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm
Log Message:
-----------
Cherry-pick 1696f58ed17a. rdar://115129147
Adjust visionOS fullscreen scene dimming level
https://bugs.webkit.org/show_bug.cgi?id=261284
rdar://115129147
Reviewed by Aditya Keerthi.
* Source/WebKit/UIProcess/ios/fullscreen/WKFullScreenWindowControllerIOS.mm:
(-[WKFullScreenWindowController _performSpatialFullScreenTransition:completionHandler:]):
(-[WKFullScreenWindowController toggleSceneDimming]):
"VeryDark" is too dark.
Canonical link: https://commits.webkit.org/267749@main
Identifier: 265870.547 at safari-7616-branch
Commit: 0097818242c5e4e3749605d9c7c7c4a6f02aa754
https://github.com/WebKit/WebKit/commit/0097818242c5e4e3749605d9c7c7c4a6f02aa754
Author: Tim Horton <thorton at apple.com>
Date: 2023-09-11 (Mon, 11 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCAFiltersCocoa.mm
Log Message:
-----------
Cherry-pick 780a84bad82a. rdar://112798317
visionOS: backdrop-filter in a transparent web view on top of material background renders black
https://bugs.webkit.org/show_bug.cgi?id=261419
rdar://112798317
Reviewed by Mike Wyrzykowski.
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCAFiltersCocoa.mm:
(WebCore::PlatformCAFilters::setFiltersOnLayer):
Use the visionOS-specific `normalizeEdgesTransparent` filter option in order
to make backdrops render correctly on top of material backgrounds.
Technically we only need this in cases where we're on top of a material, and could
use the cheaper `normalizeEdges` in the opaque-web-view case, but that would
require plumbing that knowledge through the fairly-distant filter application code.
Canonical link: https://commits.webkit.org/267875@main
Identifier: 265870.548 at safari-7616-branch
Commit: 4d4aff965150270e46f99c50ed2a15a2fc31cb41
https://github.com/WebKit/WebKit/commit/4d4aff965150270e46f99c50ed2a15a2fc31cb41
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2023-09-12 (Tue, 12 Sep 2023)
Changed paths:
M Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.GPU.sb.in
Log Message:
-----------
Cherry-pick 1499ac30c107. rdar://115177854
[iOS][GPUP] Allow required syscalls
https://bugs.webkit.org/show_bug.cgi?id=261414
rdar://115177854
Reviewed by Chris Dumez.
Allow required syscalls related to audio playback in the GPU process sandbox on iOS.
* Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.GPU.sb.in:
Canonical link: https://commits.webkit.org/267871@main
Canonical link: https://commits.webkit.org/265870.549@safari-7616-branch
Commit: 79ce64f85e2a6d5f6581ea23cd1b70659625a99c
https://github.com/WebKit/WebKit/commit/79ce64f85e2a6d5f6581ea23cd1b70659625a99c
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-12 (Tue, 12 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/setup.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/bugzilla.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py
Log Message:
-----------
Cherry-pick 267822 at main (55b5ca6ddf2f). rdar://114842008
[git-webkit] Check original and duplicate security status
https://bugs.webkit.org/show_bug.cgi?id=261049
rdar://114842008
Rubber-stamped by Aakash Jain.
To prevent a contributor from accidentally publishing code for a redacted
issue, treat an issue as redacted if it is the original or duplicate of
a redacted issue.
* Tools/Scripts/libraries/webkitbugspy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/bugzilla.py:
(Tracker.BugzillaPageParser): Add class to parse bugzilla HTML.
(Tracker.populate): Populate duplicates.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/issue.py:
(Issue.__init__): Add duplicate.
(Issue.duplicates):
(Issue._redaction_match): Break out of redaction function.
(Issue.redacted): Check if original or duplicates are redacted.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/bugzilla.py:
(Bugzilla._bug_html): Generate reduce bugzilla html for testing.
(Bugzilla.request): Support show_bug.cgi?id= endpoint.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py:
(RadarModel.relationships): Return list of relationships.
(Radar.Relationship): Mock Radar.Relationship class.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py:
(Tracker.populate): Populate duplicates.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/bugzilla_unittest.py:
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/tests/radar_unittest.py:
Canonical link: https://commits.webkit.org/267822@main
Canonical link: https://commits.webkit.org/265870.550@safari-7616-branch
Commit: 721c3654c6b03da5da810dde2b6d3d728c3d8e91
https://github.com/WebKit/WebKit/commit/721c3654c6b03da5da810dde2b6d3d728c3d8e91
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-12 (Tue, 12 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/setup.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/data.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/clone.py
Log Message:
-----------
Cherry-pick 267913 at main (6ba3165c0feb). rdar://115370971
[webkitbugspy] Handle Radar rate limits
https://bugs.webkit.org/show_bug.cgi?id=261469
rdar://115370971
Reviewed by Dewei Zhu.
* Tools/Scripts/libraries/webkitbugspy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/__init__.py: Ditto
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/data.py: protectedAccessGroups is a list.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py:
(RadarModel.Milestone): Update function call with AccessGroups.
(RadarModel.RadarGroup): Added.
(Radar.RetryPolicy): Added.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/radar.py:
(Tracker.__init__): Add retry policy.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/clone.py:
(Clone.main): Use new AccessGroups.
Canonical link: https://commits.webkit.org/267913@main
Canonical link: https://commits.webkit.org/265870.551@safari-7616-branch
Commit: 97b0fd8597c774dbcd64121f3f8a522f9a2f94db
https://github.com/WebKit/WebKit/commit/97b0fd8597c774dbcd64121f3f8a522f9a2f94db
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-12 (Tue, 12 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/clone.py
Log Message:
-----------
Cherry-pick 267926 at main (ad55bd4e665a). rdar://115370971
[webkitbugspy] Handle Radar rate limits (Follow-up fix)
https://bugs.webkit.org/show_bug.cgi?id=261469
rdar://115370971
Unreviewed follow-up fix.
* Tools/Scripts/libraries/webkitbugspy/webkitbugspy/mocks/radar.py:
(RadarModel.RadarGroup): Use name instead of id.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/clone.py:
(Clone.main): Use group name instead of id.
Canonical link: https://commits.webkit.org/267926@main
Canonical link: https://commits.webkit.org/265870.552@safari-7616-branch
Commit: 1393b618ad01cae2ca79043153e2af6c0cefb2d0
https://github.com/WebKit/WebKit/commit/1393b618ad01cae2ca79043153e2af6c0cefb2d0
Author: Abigail Fox <abigail_fox at apple.com>
Date: 2023-09-13 (Wed, 13 Sep 2023)
Changed paths:
M Source/WTF/wtf/Vector.h
Log Message:
-----------
WTF::Vector cross-container overflow ASAN support
https://bugs.webkit.org/show_bug.cgi?id=261220
rdar://113692853
Reviewed by David Kilzer.
Added check in ASAN builds for container overflow
* Source/WTF/wtf/Vector.h:
(WTF::Malloc>::asanBufferSizeWillChangeTo):
(WTF::Malloc>::uncheckedAppend):
* Tools/TestWebKitAPI/Tests/WTF/Vector.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/265870.553@safari-7616-branch
Commit: 2e31b89504c52a29edab05c5eeea7b48d66a2a3d
https://github.com/WebKit/WebKit/commit/2e31b89504c52a29edab05c5eeea7b48d66a2a3d
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2023-09-13 (Wed, 13 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/DragDropInteractionState.h
M Source/WebKit/UIProcess/ios/DragDropInteractionState.mm
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Cherry-pick d3dc96cb1d7b. rdar://113867128
Cherry-pick 267819 at main (d3dc96cb1d7b). rdar://113867128
Interaction: Drags from twitter.com (after scrolling down the page) have the wrong origin
https://bugs.webkit.org/show_bug.cgi?id=261354
rdar://113867128
Reviewed by Tim Horton.
When performing a drag-and-drop interaction while a context menu is currently present, UIKit expects
that both the context menu preview and the drag preview have the same size and origin. However, this
is not currently the case.
This is because in some cases, the context menu preview is created from a snapshot, which has a y-position
corresponding to the position relative to the entire page. However, the drag preview uses the drag
source directly, and it's position is relative to the view.
To fix, adopt the same snapshotting mechanism in the drag preview that is currently used in the context
menu preview, when applicable.
* Source/WebKit/UIProcess/ios/DragDropInteractionState.h:
* Source/WebKit/UIProcess/ios/DragDropInteractionState.mm:
(WebKit::DragDropInteractionState::previewForLifting const):
(WebKit::DragDropInteractionState::previewForCancelling):
(WebKit::DragDropInteractionState::createDragPreviewInternal const):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _createTargetedContextMenuHintPreviewIfPossible]):
Detect when the snapshotting case happens, and save the indicator data for use later on by the drag preview.
(-[WKContentView dragInteraction:previewForLiftingItem:session:]):
Canonical link: https://commits.webkit.org/267819@main
Commit: 677a9270d3f8430f588c71990086430a2ccb59c2
https://github.com/WebKit/WebKit/commit/677a9270d3f8430f588c71990086430a2ccb59c2
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-09-13 (Wed, 13 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/DragDropInteractionState.mm
Log Message:
-----------
Apply patch. rdar://113867128
Apply patch. rdar://113867128
rdar://113867128 (Interaction: Drags from twitter.com (after scrolling down the page) have the wrong origin)
* Source/WebKit/UIProcess/ios/DragDropInteractionState.mm:
(WebKit::DragDropInteractionState::previewForDragItem const):
Canonical link: https://commits.webkit.org/265870.555@safari-7616-branch
Commit: e28e46dcc8a91f64eaf634f114e247f0b5f20499
https://github.com/WebKit/WebKit/commit/e28e46dcc8a91f64eaf634f114e247f0b5f20499
Author: Robert Jenner <Jenner at apple.com>
Date: 2023-09-13 (Wed, 13 Sep 2023)
Changed paths:
M LayoutTests/TestExpectations
Log Message:
-----------
[GARDENING]REGRESSION(265506 at Main): [ Monterey+ Release ] fast/layoutformattingcontext (Layout-Tests) are a constant crash
https://bugs.webkit.org/show_bug.cgi?id=259342
rdar://112540099
Unreviewed test gardening.
* LayoutTests/TestExpectations:
Canonical link: https://commits.webkit.org/265870.556@safari-7616-branch
Commit: 5dd0bac29991909beaec2db07580524c11cc90be
https://github.com/WebKit/WebKit/commit/5dd0bac29991909beaec2db07580524c11cc90be
Author: Youenn Fablet <youennf at gmail.com>
Date: 2023-09-14 (Thu, 14 Sep 2023)
Changed paths:
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp
M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.h
Log Message:
-----------
NetworkRTCProvider::doSocketTaskOnRTCNetworkThread should protect iself
https://bugs.webkit.org/show_bug.cgi?id=261200
rdar://112521277
Reviewed by Eric Carlson.
Make sure to ref NetworkRTCProvider before hopping to another thread.
We mark NetworkRTCProvider as DestructionThread::MainRunLoop to ensure it gets destroyed in main run loop.
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:
(WebKit::NetworkRTCProvider::createClientTCPSocket):
(WebKit::NetworkRTCProvider::doSocketTaskOnRTCNetworkThread):
* Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.h:
Canonical link: https://commits.webkit.org/265870.557@safari-7616-branch
Commit: 47e039ffd68925f0a5b816af67655b7438b04845
https://github.com/WebKit/WebKit/commit/47e039ffd68925f0a5b816af67655b7438b04845
Author: Keith Miller <keith_miller at apple.com>
Date: 2023-09-14 (Thu, 14 Sep 2023)
Changed paths:
A JSTests/stress/getbyoffset-cse-consistency.js
A JSTests/stress/multigetbyoffset-cse-consistency.js
M Source/JavaScriptCore/dfg/DFGCSEPhase.cpp
M Source/JavaScriptCore/dfg/DFGClobberize.h
M Source/JavaScriptCore/dfg/DFGHeapLocation.h
Log Message:
-----------
clobberize needs to be more precise with the *ByOffset nodes
https://bugs.webkit.org/show_bug.cgi?id=261544
rdar://115399657
Reviewed by Yusuke Suzuki and Mark Lam.
CSE phase uses clobberize to figure out if it's safe to merge two operations that
def the same HeapLocation. Since HeapLocation does not currently have a way to
track the offset used by the various *ByOffset nodes it can get confused and
think that two ByOffset instructions produce the same value even if they don't
use the same offset. This patch solves this by adding a new field to HeapLocation,
which takes the metadata associated with the corresponding *ByOffset node. If two
*ByOffset operations don't share the same metadata then they cannot be CSEed.
* Source/JavaScriptCore/dfg/DFGCSEPhase.cpp:
* Source/JavaScriptCore/dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* Source/JavaScriptCore/dfg/DFGHeapLocation.h:
(JSC::DFG::HeapLocation::HeapLocation):
(JSC::DFG::HeapLocation::extraState const):
(JSC::DFG::HeapLocation::hash const):
Canonical link: https://commits.webkit.org/265870.558@safari-7616-branch
Commit: 8e9332694594255f7a86090b772aa829f4c679dd
https://github.com/WebKit/WebKit/commit/8e9332694594255f7a86090b772aa829f4c679dd
Author: Brandon Stewart <brandonstewart at apple.com>
Date: 2023-09-15 (Fri, 15 Sep 2023)
Changed paths:
M Source/WebCore/crypto/SubtleCrypto.cpp
Log Message:
-----------
SubtleCrypto:wrapKey ensure promise is not garbage collected
https://bugs.webkit.org/show_bug.cgi?id=261519
rdar://115349445
Reviewed by Tim Nguyen.
We need to ensure that the promise always remains alive when in use.
Adding a RefPtr guarantees that it will not be garbage collected.
* Source/WebCore/crypto/SubtleCrypto.cpp:
(WebCore::SubtleCrypto::wrapKey):
Canonical link: https://commits.webkit.org/265870.559@safari-7616-branch
Commit: 0f4469003671397b5b9519de250c0c22331e9a55
https://github.com/WebKit/WebKit/commit/0f4469003671397b5b9519de250c0c22331e9a55
Author: Andres Gonzalez <andresg_22 at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.cpp
Log Message:
-----------
AX: Heap-use-after-free in WebCore::AXObjectCache::get(WebCore::Node*)+0x41c
rdar://113770369
Reviewed by Ryosuke Niwa.
This UAF is most likely caused by a mutation in the WeakListHashSet while iterating over it. This patch avoids the problem by copying the set to a Vector and iterating over the Vector.
The same technique is applied to another iteration over a WeakListHashsSet, m_deferredNodeAddedOrRemovedList, in the same method.
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::performDeferredCacheUpdate):
Canonical link: https://commits.webkit.org/265870.560@safari-7616-branch
Commit: 0a6ca7f3df1a9cdf2dee17707f1204b6dd384aa2
https://github.com/WebKit/WebKit/commit/0a6ca7f3df1a9cdf2dee17707f1204b6dd384aa2
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/LayoutRect.cpp
Log Message:
-----------
Cherry-pick 0ab891185786. rdar://115707089
unionRect(const Vector<LayoutRect>&) behaves incorrectly with empty rects
https://bugs.webkit.org/show_bug.cgi?id=259674
rdar://113183595
Reviewed by Alan Baradlay.
unionRect(const Vector<LayoutRect>&) behaves incorrectly if the input vector contains
a single zero-size rect with a non-zero location; it will union with the empty rect,
and therefore return the empty rect.
This is not known to change any behavior, but a future change in bug 259672
will exercise this code.
* Source/WebCore/platform/graphics/LayoutRect.cpp:
(WebCore::unionRect):
Canonical link: https://commits.webkit.org/266479@main
Canonical link: https://commits.webkit.org/265870.560@safari-7616-branch
Commit: e5883e463dbb1adde3f9e5db8c7468928252863c
https://github.com/WebKit/WebKit/commit/e5883e463dbb1adde3f9e5db8c7468928252863c
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/Modules/mediasource/MediaSource.cpp
Log Message:
-----------
Cherry-pick f790c5f884db. rdar://115055098
REGRESSION(267279 at main): media/media-source/media-source-seek-detach-crash.html causes a crash
https://bugs.webkit.org/show_bug.cgi?id=261202
rdar://115055098
Reviewed by Youenn Fablet.
Call completionHandler immediately when MediaSource is closed.
* Source/WebCore/Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::seekToTarget):
(WebCore::MediaSource::completeSeek): Fly-by fix, exit loop early when an error has occurred.
Canonical link: https://commits.webkit.org/267675@main
Canonical link: https://commits.webkit.org/265870.561@safari-7616-branch
Commit: bb7b9114332c8bd4471e677d9fa59c55658c9c22
https://github.com/WebKit/WebKit/commit/bb7b9114332c8bd4471e677d9fa59c55658c9c22
Author: Etienne Segonzac <sgz at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm
Log Message:
-----------
Cherry-pick 5d9124497dac. rdar://114722247
InteractionRegion masked corners don't always reset properly
https://bugs.webkit.org/show_bug.cgi?id=261506
<rdar://114722247>
Reviewed by Tim Horton.
When a layer goes from having some corners with a radius to all corners
with a radius we need to reset the `maskedCorners` property.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeInteractionRegionLayers.mm:
(WebKit::updateLayersForInteractionRegions):
Canonical link: https://commits.webkit.org/267961@main
Canonical link: https://commits.webkit.org/265870.562@safari-7616-branch
Commit: dd895364820e2432a1f2133e8422be287d041bb5
https://github.com/WebKit/WebKit/commit/dd895364820e2432a1f2133e8422be287d041bb5
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
A LayoutTests/fast/scrolling/ios/video-scrolling-expected.txt
A LayoutTests/fast/scrolling/ios/video-scrolling.html
M Source/WebKit/SourcesCocoa.txt
M Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.h
M Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm
M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeHostIOS.mm
A Source/WebKit/UIProcess/ios/WKVideoView.h
A Source/WebKit/UIProcess/ios/WKVideoView.mm
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick 960e0d109099. rdar://114720841
[iOS] Cannot scroll page by dragging on a bare <video> element
https://bugs.webkit.org/show_bug.cgi?id=261563
rdar://114720841
Reviewed by Simon Fraser.
The UI-side compositing subsystem relies on UIViews of particular classes or conforming to
particular protocols for collecting the appropriate views during hit testing. WebAVPlayerLayerView
is not one of those clasess, nor can it conform to the protocols defined in WebKit (as it's a
product of WebCore). So to the hit testing logic of UI-side compositing, it's a black hole.
Add a new class, WKVideoView, which is a WKCompositingView as well as WKNativelyInteractible, to
host the WebAVPlayerLayerView.
* Source/WebKit/SourcesCocoa.txt:
* Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.h:
* Source/WebKit/UIProcess/Cocoa/VideoFullscreenManagerProxy.mm:
(WebKit::VideoFullscreenManagerProxy::createViewWithID):
* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeHostIOS.mm:
* Source/WebKit/UIProcess/ios/WKVideoView.h: Added.
* Source/WebKit/UIProcess/ios/WKVideoView.mm: Added.
(+[WKVideoView layerClass]):
(-[WKVideoView hitTest:withEvent:]):
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/268041@main
Canonical link: https://commits.webkit.org/265870.563@safari-7616-branch
Commit: 308a54bb2a50201af5d598b844ceaed3b9496a25
https://github.com/WebKit/WebKit/commit/308a54bb2a50201af5d598b844ceaed3b9496a25
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm
Log Message:
-----------
Cherry-pick 4473b145e837. rdar://115543506
[iOS] Crash when closing and removing a WKWebView with an active find interaction
https://bugs.webkit.org/show_bug.cgi?id=261623
rdar://115543506
Reviewed by Wenson Hsieh.
In 267443 at main, `WKWebView` began driving find overlay display logic from the
UI process, rather than the Web process. Specifically, the `CALayer` representing
the overlay is directly manipulated from `WKWebView`, rather than `PageOverlay`.
`-[WKWebView _layerForFindOverlay]` can be used to retrieve the current find
overlay layer, using the `DrawingAreaProxy` and a layer identifier.
The crashing scenario is as follows:
1. Begin a find interaction. This creates a find overlay layer, referenced as `_perProcessState.committedFindLayerID`.
2. Close the `WKWebView` using `-[WKWebView _close]`. This results in the `DrawingAreaProxy` being nulled out.
3. Remove the `WKWebView` from the view hierarchy. This triggers the end of the find interaction.
4. Since the find interaction is ending, the web view attempts to hide the overlay layer.
5. Null dereference of `_page->drawingArea()` as current layer is retrieved prior to hiding.
The underlying assumption that was incorrect here was that `_perProcessState`
gets reset when the `WKWebView` is closed. That would fix the crash, since
`committedFindLayerID` would be unavailable. However, this state is not reset,
presumably since the overall web view state no longer has useful meaning.
To fix, simply null-check the `DrawingAreaProxy` as is done in other parts of
the code. `committedFindLayerID` does not need to be reset, as a new search
cannot be initiated with a closed web view.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _layerForFindOverlay]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(TEST):
Canonical link: https://commits.webkit.org/268044@main
Canonical link: https://commits.webkit.org/265870.564@safari-7616-branch
Commit: 76ffef8761d24344b110825db59e612d4c93bf57
https://github.com/WebKit/WebKit/commit/76ffef8761d24344b110825db59e612d4c93bf57
Author: Alex Christensen <achristensen at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm
Log Message:
-----------
Cherry-pick 266605 at main (fa4ef1f8175e). rdar://115730362
Only call CGImage restricting APIs once per process
https://bugs.webkit.org/show_bug.cgi?id=259840
<rdar://problem/113416279>
Reviewed by Simon Fraser.
This should fix a common assertion.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::m_appHighlightsVisible):
* Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):
Canonical link: https://commits.webkit.org/266605@main
Canonical link: https://commits.webkit.org/265870.566@safari-7616-branch
Commit: 6380262a85805d2059e0893adef72710f855ae13
https://github.com/WebKit/WebKit/commit/6380262a85805d2059e0893adef72710f855ae13
Author: David Kilzer <ddkilzer at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/testing/js/WebCoreTestSupport.cpp
M Source/WebCore/testing/js/WebCoreTestSupport.h
Log Message:
-----------
Add test function for WebCore::SincResampler
https://bugs.webkit.org/show_bug.cgi?id=261702
<rdar://115682448>
Reviewed by Chris Dumez and Alex Christensen.
Add test method that calls SincResampler::processBuffer().
* Source/WebCore/testing/js/WebCoreTestSupport.cpp:
(WebCoreTestSupport::testSincResamplerProcessBuffer): Add.
* Source/WebCore/testing/js/WebCoreTestSupport.h:
(WebCoreTestSupport::testSincResamplerProcessBuffer): Add.
Canonical link: https://commits.webkit.org/265870.567@safari-7616-branch
Commit: 370dd35ca21cc238966ea68bc3a2344eb84b55d7
https://github.com/WebKit/WebKit/commit/370dd35ca21cc238966ea68bc3a2344eb84b55d7
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/dom/Document.cpp
M Source/WebCore/html/LazyLoadFrameObserver.cpp
M Source/WebCore/page/IntersectionObserver.cpp
M Source/WebCore/page/IntersectionObserver.h
Log Message:
-----------
Cherry-pick 3b73b01fe389. rdar://115706697
Move code for computing Intersection Observations from document to IntersectionObserver
https://bugs.webkit.org/show_bug.cgi?id=259173
rdar://112176104
Reviewed by Cameron McCormack.
Move most the Intersetion Observer-related code in Document into IntersectionObserver.cpp
for better encapsulation.
The only behavior change is to keep RefPtr to the IntersectionObserver while running the code.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::updateIntersectionObservations):
(WebCore::expandRootBoundsWithRootMargin): Deleted.
(WebCore::computeClippedRectInRootContentsSpace): Deleted.
(WebCore::computeIntersectionState): Deleted.
* Source/WebCore/html/LazyLoadFrameObserver.cpp:
* Source/WebCore/page/IntersectionObserver.cpp:
(WebCore::expandRootBoundsWithRootMargin):
(WebCore::computeClippedRectInRootContentsSpace):
(WebCore::computeIntersectionState):
(WebCore::IntersectionObserver::updateObservations):
* Source/WebCore/page/IntersectionObserver.h:
Canonical link: https://commits.webkit.org/266034@main
Canonical link: https://commits.webkit.org/265870.567@safari-7616-branch
Commit: 46a317bb097533e6cc4445da037e4d01890ce00d
https://github.com/WebKit/WebKit/commit/46a317bb097533e6cc4445da037e4d01890ce00d
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/page/IntersectionObserver.cpp
M Source/WebCore/page/IntersectionObserver.h
Log Message:
-----------
Cherry-pick 39a323e0f736. rdar://115706930
Optimize Intersection Observer computations slightly
https://bugs.webkit.org/show_bug.cgi?id=259630
rdar://113083595
Reviewed by Ryosuke Niwa.
Refactor computeIntersectionState() so that we can lazily compute intersectionState.absoluteRootBounds()
only when we know we're going to fire an observation.
This requires passing the IntersectionObserverRegistration to computeIntersectionState(), which now
makes more sense as a member function, and moving the computation of thresholdIndex into this
function, so we can compute absoluteRootBounds and absoluteTargetRect lazily when we know we're going
to fire the observation.
IntersectionObservationState becomes a class-private struct since the member function returns it.
To make it clearer which rectangles have valid values in IntersectionObservationState, use
std::optional<FloatRect>s. Rename "localRootBounds" to "rootBounds" because the "local" there didn't
add any information.
Make extensive use of lambda functions in IntersectionObserver::computeIntersectionState() to
group related code and allow for early returns for clarity.
For RenderInlines, replace a call to target.boundingAbsoluteRectWithoutLayout() by code that
calls absoluteQuads() directly, since this is what boundingAbsoluteRectWithoutLayout() does for
inlines. Add a note about how inefficient this is.
There should be no behavior change here. Tested by WPT Intersection Observer tests.
* Source/WebCore/page/IntersectionObserver.cpp:
(WebCore::expandRootBoundsWithRootMargin):
(WebCore::IntersectionObserver::computeIntersectionState const):
(WebCore::IntersectionObserver::updateObservations):
(): Deleted.
(WebCore::computeIntersectionState): Deleted.
* Source/WebCore/page/IntersectionObserver.h:
Canonical link: https://commits.webkit.org/266458@main
Canonical link: https://commits.webkit.org/265870.568@safari-7616-branch
Commit: 38aac1006a428ca874de85b03d6ae5cb72e9bc99
https://github.com/WebKit/WebKit/commit/38aac1006a428ca874de85b03d6ae5cb72e9bc99
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/page/IntersectionObserver.cpp
Log Message:
-----------
Cherry-pick 32beea64ac2d. rdar://115706869
Optimize Intersection Observer computations for inlines
https://bugs.webkit.org/show_bug.cgi?id=259717
rdar://113238475
Reviewed by Ryosuke Niwa.
When computing intersections for RenderInlines, the code computed absolute quads for the RenderInline and
its continutations, then mapped those to local coordinates. What a waste!
Instead we can just compute those rectangles in local coordinates directly. This drops the time spent in
Document::updateIntersectionObservations() from 24% of the time to 14% of the time scrolling an amazon.com
search results page.
* Source/WebCore/page/IntersectionObserver.cpp:
(WebCore::IntersectionObserver::computeIntersectionState const):
Canonical link: https://commits.webkit.org/266501@main
Canonical link: https://commits.webkit.org/265870.569@safari-7616-branch
Commit: 9402507cb554176aaa6911946b80746c138f8f71
https://github.com/WebKit/WebKit/commit/9402507cb554176aaa6911946b80746c138f8f71
Author: Jean-Yves Avenard <jya at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
A LayoutTests/media/media-source/content/test-fragmented-video.png
A LayoutTests/media/media-source/media-managedmse-seek-expected.html
A LayoutTests/media/media-source/media-managedmse-seek.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/Modules/mediasource/MediaSource.cpp
M Source/WebCore/Modules/mediasource/MediaSource.h
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/Modules/mediasource/SourceBuffer.h
M Source/WebCore/platform/graphics/MediaSourcePrivate.h
M Source/WebCore/platform/graphics/MediaSourcePrivateClient.h
M Source/WebCore/platform/graphics/SourceBufferPrivate.cpp
M Source/WebCore/platform/graphics/SourceBufferPrivate.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm
M Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.h
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.h
M Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.h
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.h
M Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.messages.in
M Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.h
M Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.messages.in
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.h
Log Message:
-----------
Cherry-pick 324ba3da764b. rdar://114642707
REGRESSION(267279 at main): [ macOS wk2 ] fast/canvas/webgl/texImage2D-mse-flipY-false.html is a consistent text failure.
https://bugs.webkit.org/show_bug.cgi?id=260867
rdar://114642707
Reviewed by Youenn Fablet and Jer Noble.
The fix for bug 260185 (commit 267279 at main) incorrectly changed the ordering
of operations (renqueue frames was called prior seeking with AVSampleBufferRenderSynchronizer).
This resulted in the incorrect video frame being painted.
In this change we restore the prior seeking workflow. This requires to
split the MediaSource::seekToTarget into two, the first one being to determine
if data is available at the seekpoint and calculating the nearest keyframe
(if using fastSeek) and then the actual SourceBuffer's loading of data
at the seek time.
Fly-By: commit 267279 at main also re-introduced bug 188926 by dropping one
of the work-around. This was caught by media/media-source/media-source-seek-twice.html
Adding test to check that the right frame is displayed when the seeked
event is fired.
* LayoutTests/media/media-source/content/test-fragmented-video.png: Added.
* LayoutTests/media/media-source/media-managedmse-seek-expected.html: Added.
* LayoutTests/media/media-source/media-managedmse-seek.html: Added.
* Source/WebCore/Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::waitForTarget):
(WebCore::MediaSource::completeSeek):
(WebCore::MediaSource::seekToTime):
(WebCore::MediaSource::seekToTarget): Deleted.
* Source/WebCore/Modules/mediasource/MediaSource.h:
* Source/WebCore/Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::computeSeekTime):
(WebCore::SourceBuffer::seekToTime):
(WebCore::SourceBuffer::seekToTarget): Deleted.
* Source/WebCore/Modules/mediasource/SourceBuffer.h:
* Source/WebCore/platform/graphics/MediaSourcePrivate.h:
* Source/WebCore/platform/graphics/MediaSourcePrivateClient.h:
* Source/WebCore/platform/graphics/SourceBufferPrivate.cpp:
(WebCore::SourceBufferPrivate::computeSeekTime):
(WebCore::SourceBufferPrivate::seekToTarget): Deleted.
* Source/WebCore/platform/graphics/SourceBufferPrivate.h:
(WebCore::SourceBufferPrivate::notifyClientWhenReadyForMoreSamples):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::MediaPlayerPrivateMediaSourceAVFObjC):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekInternal):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::maybeSeekCompleted):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::setHasAvailableVideoFrame):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::seekCompleted): Deleted.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm:
(WebCore::MediaSourcePrivateAVFObjC::waitForTarget):
(WebCore::MediaSourcePrivateAVFObjC::seekToTime):
(WebCore::MediaSourcePrivateAVFObjC::seekToTarget): Deleted.
* Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(WebCore::SourceBufferPrivateAVFObjC::seekToTime):
* Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::doSeek):
* Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.cpp:
(WebCore::MediaSourcePrivateGStreamer::waitForTarget):
(WebCore::MediaSourcePrivateGStreamer::seekToTime):
(WebCore::MediaSourcePrivateGStreamer::seekToTarget): Deleted.
* Source/WebCore/platform/graphics/gstreamer/mse/MediaSourcePrivateGStreamer.h:
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp:
(WebCore::MockMediaPlayerMediaSource::seekToTarget):
* Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.cpp:
(WebCore::MockMediaSourcePrivate::waitForTarget):
(WebCore::MockMediaSourcePrivate::seekToTime):
(WebCore::MockMediaSourcePrivate::seekToTarget): Deleted.
* Source/WebCore/platform/mock/mediasource/MockMediaSourcePrivate.h:
* Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.cpp:
(WebKit::RemoteMediaSourceProxy::waitForTarget):
(WebKit::RemoteMediaSourceProxy::seekToTime):
(WebKit::RemoteMediaSourceProxy::seekToTarget): Deleted.
* Source/WebKit/GPUProcess/media/RemoteMediaSourceProxy.h:
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.cpp:
(WebKit::RemoteSourceBufferProxy::computeSeekTime):
(WebKit::RemoteSourceBufferProxy::seekToTime):
(WebKit::RemoteSourceBufferProxy::seekToTarget): Deleted.
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.h:
* Source/WebKit/GPUProcess/media/RemoteSourceBufferProxy.messages.in:
* Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.cpp:
(WebKit::MediaSourcePrivateRemote::waitForTarget):
(WebKit::MediaSourcePrivateRemote::seekToTime):
(WebKit::MediaSourcePrivateRemote::seekToTarget): Deleted.
* Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.h:
* Source/WebKit/WebProcess/GPU/media/MediaSourcePrivateRemote.messages.in:
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.cpp:
(WebKit::SourceBufferPrivateRemote::computeSeekTime):
(WebKit::SourceBufferPrivateRemote::seekToTime):
(WebKit::SourceBufferPrivateRemote::seekToTarget): Deleted.
* Source/WebKit/WebProcess/GPU/media/SourceBufferPrivateRemote.h:
Canonical link: https://commits.webkit.org/267814@main
Canonical link: https://commits.webkit.org/265870.570@safari-7616-branch
Commit: fa988147719d2c36302fa8042c0c32428094de3b
https://github.com/WebKit/WebKit/commit/fa988147719d2c36302fa8042c0c32428094de3b
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/AXObjectCache.h
M Source/WebCore/accessibility/AccessibilityObject.h
M Source/WebCore/accessibility/AccessibilityObjectInterface.h
M Source/WebCore/accessibility/ios/AccessibilityObjectIOS.mm
M Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.h
M Source/WebCore/editing/Editor.cpp
Log Message:
-----------
Apply patch. rdar://114844079
Canonical link: https://commits.webkit.org/265870.572@safari-7616-branch
Commit: 5a43ab3b12c58a5608bc38f96cec554572e2bc5e
https://github.com/WebKit/WebKit/commit/5a43ab3b12c58a5608bc38f96cec554572e2bc5e
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-09-19 (Tue, 19 Sep 2023)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.mm
Log Message:
-----------
Apply patch. rdar://115500744
Canonical link: https://commits.webkit.org/265870.573@safari-7616-branch
Commit: 58238f2ad1a031132c4cc63cf88edec3c4263d0a
https://github.com/WebKit/WebKit/commit/58238f2ad1a031132c4cc63cf88edec3c4263d0a
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
CloneDeserializer should always purifyNaN all double values it reads.
https://bugs.webkit.org/show_bug.cgi?id=261801
rdar://115756664
Reviewed by Yusuke Suzuki.
CloneDeserializer::read() will now invoke purifyNaN() on any double values that it reads.
As a result, we can remove the 2 purifyNaN calls in its client that are now redundant.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::read):
(WebCore::CloneDeserializer::readTerminal):
Canonical link: https://commits.webkit.org/265870.574@safari-7616-branch
Commit: 962e4d3eb875ebdb03c8e8673ffbbecc08b963d7
https://github.com/WebKit/WebKit/commit/962e4d3eb875ebdb03c8e8673ffbbecc08b963d7
Author: Tim Horton <thorton at apple.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm
Log Message:
-----------
Cherry-pick e4d8e9236f2a. rdar://108139596
Cherry-pick 268098 at main (e4d8e9236f2a). rdar://108139596
visionOS: Pixel cracks within layers at some content scales
https://bugs.webkit.org/show_bug.cgi?id=261693
rdar://108139596
Reviewed by Dean Jackson.
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:
(WebKit::RemoteLayerBackingStore::setNeedsDisplay):
(WebKit::RemoteLayerBackingStore::layerBounds const):
(WebKit::RemoteLayerBackingStore::drawInContext):
Dynamic content scaling doesn't support partial repaint, so we disable it.
We do this by calling setNeedsDisplay() on the layer, intending to make a
single repaint rect covering the whole layer.
However, RemoteLayerBackingStore's setNeedDisplay doesn't intersect incoming repaint
rects with the layer's bounds, so a very large repaint rect *outside* of the bounds
of the layer (like you might get with e.g. a large negative text-indent, which is
fairly common on the web), results in a m_dirtyRegion with rectangles far outside
the layer.
Then, depending on the shape of the extralayer repaint rects, the logic in
RemoteLayerBackingStore::drawInContext that decides whether or not to do a
partial repaint (based on the delta between the area covered by the repaint rects
and the bounds of a full repaint) can still decide to do a partial repaint.
(Despite the fact that we absolutely cannot perform partial repaints
for dynamic content scaling right now).
Fix this by intersecting incoming repaint rects with the layer's bounds, so that
calling setNeedsDisplay *always* results in RemoteLayerBackingStore::drawInContext
doing a full repaint.
Canonical link: https://commits.webkit.org/268098@main
Canonical link: https://commits.webkit.org/265870.575@safari-7616-branch
Commit: cb559add0e912a63a981692c620153f2727a813a
https://github.com/WebKit/WebKit/commit/cb559add0e912a63a981692c620153f2727a813a
Author: Tim Horton <thorton at apple.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.h
M Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm
Log Message:
-----------
Cherry-pick 7eb6ed02a5ba. rdar://109372324
Cherry-pick 268107 at main (7eb6ed02a5ba). rdar://109372324
visionOS: Text jumps by subpixel increments when repainting
https://bugs.webkit.org/show_bug.cgi?id=261472
rdar://109372324
Reviewed by Mike Wyrzykowski, Richard Robinson and Dean Jackson.
* Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.h:
* Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.mm:
(WebKit::GraphicsContextCGDisplayList::GraphicsContextCGDisplayList):
(WebKit::CGDisplayListImageBufferBackend::context):
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:
(WebKit::RemoteLayerBackingStore::paintContents):
(WebKit::RemoteLayerBackingStore::drawInContext):
(WebKit::RemoteLayerBackingStoreProperties::applyBackingStoreToLayer):
Now that it is possible to specify the resolution at which a dynamic content
scaling display list is recorded, plumb the backing store scale to that mechanism,
and remove all of our workarounds from the days when it was only recorded at 1x.
This fixes a bug where the integer rounding of the backing store size coupled
with subpixel CTMs would make text quantization cause glyphs to land at different
quantized positions between the 2x tiles and the 1x recorded display list.
Canonical link: https://commits.webkit.org/268107@main
Canonical link: https://commits.webkit.org/265870.576@safari-7616-branch
Commit: 0b441bb5fc708992e654ef53fa14e362abdd8cd0
https://github.com/WebKit/WebKit/commit/0b441bb5fc708992e654ef53fa14e362abdd8cd0
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M Source/WTF/wtf/text/Base64.cpp
M Source/WTF/wtf/text/Base64.h
M Source/WebCore/loader/ResourceLoader.cpp
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/page/Quirks.h
M Source/WebCore/platform/network/DataURLDecoder.cpp
M Source/WebCore/platform/network/DataURLDecoder.h
M Source/WebKit/NetworkProcess/NetworkDataTaskDataURL.cpp
Log Message:
-----------
Cherry-pick 599c092f0fc9. rdar://114573089
Cherry-pick 267969 at main (599c092f0fc9). rdar://114573089
Regression(262976 at main) Images do not show in Microsoft Word Online
https://bugs.webkit.org/show_bug.cgi?id=261524
rdar://114573089
Reviewed by Brent Fulgham.
Images do not show in Microsoft Word Online since the data URL change in 262976 at main.
It is a surprising since 262976 at main was meant to align us with other browsers and yet
images show correctly in Chrome & Firefox.
After some investigation, I found that the data URL used by Word Online for images in
Safari have incorrect padding, while the ones it uses in Chrome have correct padding.
As a result, it doesn't appear to be a WebKit bug but rather Safari getting served
different content than Chrome for some reason.
To address the issue, I am introducing a quirk to disable padding validation in data
URLs on Microsoft Word Online.
* Source/WTF/wtf/text/Base64.cpp:
(WTF::base64DecodeInternal):
* Source/WTF/wtf/text/Base64.h:
* Source/WebCore/loader/ResourceLoader.cpp:
(WebCore::ResourceLoader::loadDataURL):
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldDisableDataURLPaddingValidation const):
* Source/WebCore/page/Quirks.h:
* Source/WebCore/platform/network/DataURLDecoder.cpp:
(WebCore::DataURLDecoder::DecodeTask::DecodeTask):
(WebCore::DataURLDecoder::createDecodeTask):
(WebCore::DataURLDecoder::decodeSynchronously):
(WebCore::DataURLDecoder::decode):
* Source/WebCore/platform/network/DataURLDecoder.h:
Canonical link: https://commits.webkit.org/267969@main
Canonical link: https://commits.webkit.org/265870.577@safari-7616-branch
Commit: 33e61dbf3ab826006436303aab02150d34389a99
https://github.com/WebKit/WebKit/commit/33e61dbf3ab826006436303aab02150d34389a99
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-20 (Wed, 20 Sep 2023)
Changed paths:
M Source/WebCore/page/Quirks.cpp
Log Message:
-----------
Cherry-pick e590fea7147d. rdar://114573089
Regression(262976 at main) Images do not show in Microsoft Word Online
https://bugs.webkit.org/show_bug.cgi?id=261547
rdar://114573089
Reviewed by Wenson Hsieh.
Extend the quirk added in 267969 at main to cover more cases, after further
testing by Karl Dubost.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::shouldDisableDataURLPaddingValidation const):
Canonical link: https://commits.webkit.org/267987@main
Canonical link: https://commits.webkit.org/265870.578@safari-7616-branch
Commit: 587ed3048a75103ee6116ddcbee3542ac0d63976
https://github.com/WebKit/WebKit/commit/587ed3048a75103ee6116ddcbee3542ac0d63976
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
A LayoutTests/webaudio/promise-resolution-crash-expected.txt
A LayoutTests/webaudio/promise-resolution-crash.html
M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
Log Message:
-----------
Regression(265870.536 at safari-7616-branch) Crashes under DeferredPromise::callFunction()
https://bugs.webkit.org/show_bug.cgi?id=261829
rdar://115712299
Reviewed by Brent Fulgham and Mark Lam.
The RELEASE_ASSERT() added by Ryosuke in 265870.536 at safari-7616-branch in DeferredPromise::callFunction()
is hitting a lot in the wild, from various call sites. The assertion makes sure we're allowed to run
script when resolving a promise (i.e. we're not in the middle of layout or style resolution).
* LayoutTests/webaudio/promise-resolution-crash-expected.txt: Added.
* LayoutTests/webaudio/promise-resolution-crash.html: Added.
New test coverage.
* Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
(WebCore::DeferredPromise::callFunction):
Drop the release assertion and instead schedule a task to resolve the promise
asynchronously when we're not allowed to run script, similarly to what we were
already doing when b/f cache suspended.
Canonical link: https://commits.webkit.org/265870.579@safari-7616-branch
Commit: b30dd8e12899eb0d7641e7c6d53ae88c6270943d
https://github.com/WebKit/WebKit/commit/b30dd8e12899eb0d7641e7c6d53ae88c6270943d
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-22 (Fri, 22 Sep 2023)
Changed paths:
M metadata/commit_classes.json
Log Message:
-----------
Cherry-pick 266107 at main (f044b634bcf4). rdar://111392835
[WPT] Add Test-import commit class
https://bugs.webkit.org/show_bug.cgi?id=258575
rdar://111392835
Reviewed by Aakash Jain.
* metadata/commit_classes.json: Add Test-import class.
Canonical link: https://commits.webkit.org/266107@main
Canonical link: https://commits.webkit.org/265870.580@safari-7616-branch
Commit: 9d09d4173b4b8351d9d480606ac69b43bdc67f33
https://github.com/WebKit/WebKit/commit/9d09d4173b4b8351d9d480606ac69b43bdc67f33
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-22 (Fri, 22 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/string_utils.py
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/tests/string_utils_unittest.py
Log Message:
-----------
Cherry-pick 268042 at main (003b673b7350). https://bugs.webkit.org/show_bug.cgi?id=261277
[webkitcorepy] Add string_utils.split
https://bugs.webkit.org/show_bug.cgi?id=261277
redar://115116935
Reviewed by Elliott Williams.
string_utils.split is the reverse of string_utils.joins.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/string_utils.py:
(split):
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/tests/string_utils_unittest.py:
(StringUtils.test_split):
Canonical link: https://commits.webkit.org/268042@main
Canonical link: https://commits.webkit.org/265870.581@safari-7616-branch
Commit: 8ee9bb1a28547bf79c8ee54a97fa0140feeae874
https://github.com/WebKit/WebKit/commit/8ee9bb1a28547bf79c8ee54a97fa0140feeae874
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-22 (Fri, 22 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py
Log Message:
-----------
Cherry-pick 268045 at main (dedaf00ab9cd). rdar://115084502
[webkitscmpy] Support specified branch in find_existing_pull_request
https://bugs.webkit.org/show_bug.cgi?id=261246
rdar://115084502
Reviewed by Elliott Williams.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pull_request.py:
(PullRequest.find_existing_pull_request): Allow caller to specify branch.
Canonical link: https://commits.webkit.org/268045@main
Canonical link: https://commits.webkit.org/265870.582@safari-7616-branch
Commit: adf92f0006b0fc98f65bb78d18d5007044506080
https://github.com/WebKit/WebKit/commit/adf92f0006b0fc98f65bb78d18d5007044506080
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-22 (Fri, 22 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitcorepy/setup.py
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py
M Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py
M Tools/Scripts/webkitpy/autoinstalled/twisted.py
Log Message:
-----------
Cherry-pick 268269 at main (530fa2b998ab). rdar://115851645
[webkitcorepy] Install tomli with setuptools_scm
https://bugs.webkit.org/show_bug.cgi?id=261893
rdar://115851645
Reviewed by Aakash Jain.
Newer versions of setuptools_scm depend on tomli.
* Tools/Scripts/libraries/webkitcorepy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/__init__.py:
Bump version, add tomli.
* Tools/Scripts/libraries/webkitcorepy/webkitcorepy/autoinstall.py:
(Package.install): Install tomli with setuptools dependencies.
Canonical link: https://commits.webkit.org/268269@main
Canonical link: https://commits.webkit.org/265870.583@safari-7616-branch
Commit: 2d38bbd68adeb2ec783736ca26ddfa7a05cb153b
https://github.com/WebKit/WebKit/commit/2d38bbd68adeb2ec783736ca26ddfa7a05cb153b
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-22 (Fri, 22 Sep 2023)
Changed paths:
M metadata/commit_classes.json
Log Message:
-----------
Cherry-pick 268338 at main (ff69c7549279). rdar://115908043
[metadata] Add poisoned commit class
https://bugs.webkit.org/show_bug.cgi?id=261970
rdar://115908043
Reviewed by Dewei Zhu.
* metadata/commit_classes.json: Add poisoned commit class.
Canonical link: https://commits.webkit.org/268338@main
Canonical link: https://commits.webkit.org/265870.584@safari-7616-branch
Commit: 2de3b2f30878022327cd2a58722cedd53ff0268e
https://github.com/WebKit/WebKit/commit/2de3b2f30878022327cd2a58722cedd53ff0268e
Author: Jonathan Bedard <jbedard at apple.com>
Date: 2023-09-22 (Fri, 22 Sep 2023)
Changed paths:
M Tools/Scripts/libraries/webkitscmpy/setup.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py
M Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pickable.py
Log Message:
-----------
Cherry-pick 268340 at main (4c8538afb2f3). rdar://115912222
[git-webkit] Reference all identity commits in pickable
https://bugs.webkit.org/show_bug.cgi?id=261980
rdar://115912222
Reviewed by Dewei Zhu.
* Tools/Scripts/libraries/webkitscmpy/setup.py: Bump version.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/__init__.py: Ditto.
* Tools/Scripts/libraries/webkitscmpy/webkitscmpy/program/pickable.py:
(Pickable.pickable): Continue checking relationships if identity isn't
found in commit story.
Canonical link: https://commits.webkit.org/268340@main
Canonical link: https://commits.webkit.org/265870.585@safari-7616-branch
Commit: 845d34771a74ac2b18c48634f16e8d6c8b7478cd
https://github.com/WebKit/WebKit/commit/845d34771a74ac2b18c48634f16e8d6c8b7478cd
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.2.9
Identifier: 265423.1033 at safari-7616-branch
Commit: 00779ef6e55e8e651dd2dfd55b33920b469a400f
https://github.com/WebKit/WebKit/commit/00779ef6e55e8e651dd2dfd55b33920b469a400f
Author: hoffmanjoshua <jhoffman23 at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.cpp
Log Message:
-----------
Cherry-pick 4e6fd1fb5461. rdar://113803539
AX: Improve smart pointer usage in AXObjectCache
https://bugs.webkit.org/show_bug.cgi?id=260389
rdar://problem/114090467
Reviewed by Tyler Wilcock.
Improve the usage of smart pointers in AXObjectCache in accordance with WebKit guidelines https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines.
* Source/WebCore/accessibility/AXObjectCache.cpp:
Canonical link: https://commits.webkit.org/267064@main
Identifier: 265423.1034 at safari-7616-branch
Commit: 3f96a86a0cc9cdc9bd034a88aa4fd8fc58f2a23a
https://github.com/WebKit/WebKit/commit/3f96a86a0cc9cdc9bd034a88aa4fd8fc58f2a23a
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebCore/accessibility/AXObjectCache.cpp
Log Message:
-----------
Cherry-pick f8ef167b97d5. rdar://114052085
AX: Relations updates thrash between dirty and clean when multiple deferred id attribute changes are processed
https://bugs.webkit.org/show_bug.cgi?id=260370
rdar://problem/114052085
Reviewed by Andres Gonzalez.
In AXObjectCache::handleAttributeChange, any change to the `id`
attribute causes AXObjectCache::m_relationsNeedUpdate to become true.
This is problematic when `m_deferredAttributeChange` contains multiple
`id` attribute changes, as we thrash between setting m_relationsNeedUpdate to true,
immediately resetting it to false as a result of an arbitrary` parentObject` call,
and then re-dirtying it with the next id attribute change.
With this patch (authored by Andres Gonzalez), we only update relations
once, even when a group of id attribute changes are processed.
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::performDeferredCacheUpdate):
(WebCore::AXObjectCache::relationsNeedUpdate):
* Source/WebCore/accessibility/AXObjectCache.h:
Canonical link: https://commits.webkit.org/267190@main
Identifier: 265423.1035 at safari-7616-branch
Commit: 0558fcb7262bf2888bba3dcd4175c1ca1b68ff85
https://github.com/WebKit/WebKit/commit/0558fcb7262bf2888bba3dcd4175c1ca1b68ff85
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M LayoutTests/accessibility/display-contents/tree-and-treeitems-expected.txt
M LayoutTests/accessibility/display-contents/tree-and-treeitems.html
M Source/WebCore/accessibility/AXLogger.cpp
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
M Source/WebCore/accessibility/AccessibilityObjectInterface.h
Log Message:
-----------
Cherry-pick 6d76fb13fc78. rdar://115226509
AX: No accessibility label is exposed for display:contents role="treeitem" elements that have a newline before their child text
https://bugs.webkit.org/show_bug.cgi?id=261376
rdar://problem/115226509
Reviewed by Chris Fleizach.
This patch fixes two bugs:
1. No accessibility label is exposed for display:contents role="treeitem" elements that have a newline before their child text
2. Some display:contents role="treeitem" expose text for other
elements, resulting in that text being doubly-exposed
The first was caused by a lack of resilience in AccessibilityNodeObject::firstChild.
AccessibilityNodeObject::textUnderElement relies on iterating through its accessible children like so:
for (RefPtr child = firstChild(); child; child = child->nextSibling()) {
... compute AX text ...
}
However, for elements that AXObjectCache::getOrCreate fails to create an
object for, we would never iterate because firstChild returned nullptr,
thus resulting in no AX text being gathered. AccessibilityNodeObject::firstChild
now detects this, and iterates until it finds the first accessible child.
The second bug was caused by AccessibilityNodeObject::textUnderElement
recursively calling and textUnderElement for an element that was not
it's child. With this patch, we detect this and continue the loop when
it happens.
New testcases added to accessibility/display-contents/tree-and-treeitems.html.
* LayoutTests/accessibility/display-contents/tree-and-treeitems-expected.txt:
* LayoutTests/accessibility/display-contents/tree-and-treeitems.html:
* Source/WebCore/accessibility/AXLogger.cpp:
(WebCore::operator<<):
* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::firstChild const):
(WebCore::AccessibilityNodeObject::textUnderElement const):
* Source/WebCore/accessibility/AccessibilityObjectInterface.h:
Canonical link: https://commits.webkit.org/267839@main
Identifier: 265423.1036 at safari-7616-branch
Commit: 51f166109f60bd27ddbc897ee9062e022327393a
https://github.com/WebKit/WebKit/commit/51f166109f60bd27ddbc897ee9062e022327393a
Author: Alan Baradlay <zalan at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
A LayoutTests/fast/dynamic/display-none-iframe-async-layout-expected.html
A LayoutTests/fast/dynamic/display-none-iframe-async-layout.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 7d4f344fa9a7. rdar://112494003
Office.com is slow to respond
https://bugs.webkit.org/show_bug.cgi?id=261741
<rdar://112494003>
Reviewed by Antti Koivisto.
1. we do _not_ construct renderers for “display: none” iframes
2. we do construct render tree for the “display: none” iframe’s content
we do #2 because JS may ask for geometry information on content inside a “display: none” iframe.
e.g.
<div><iframe srcdoc=“text” style="display: none;" id=iframe></iframe></div>
where:
iframe.contentDocument.body.offsetHeight should return the value of “18px”
the markup above triggers the following 2 render trees:
Main document:
RenderView
HTML RenderBlock
BODY RenderBody
DIV RenderBlock
(^^ no renderer here for the “display: none” iframe)
iframe document:
RenderView
HTML RenderBlock
BODY RenderBody
#text RenderText
(^^ this is the content _inside_ the "display: none" iframe)
We not only construct a render tree for the invisible iframe content, but also (as part of the tree construction) we schedule an async layout on them
This patch drops such async layout requests on the floor and keep the renderers dirty until after either
1. sync layout is triggered (JS -> DOM API)
2. iframe becomes visible (display != none)
* LayoutTests/fast/dynamic/display-none-iframe-async-layout-expected.html: Added.
* LayoutTests/fast/dynamic/display-none-iframe-async-layout.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::shouldScheduleLayout const):
Canonical link: https://commits.webkit.org/268148@main
Identifier: 265423.1037 at safari-7616-branch
Commit: 5ec82cd39181c89c63e9ca117a684b8d636c1724
https://github.com/WebKit/WebKit/commit/5ec82cd39181c89c63e9ca117a684b8d636c1724
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/platform/ThermalMitigationNotifier.cpp
M Source/WebCore/platform/ThermalMitigationNotifier.h
M Source/WebCore/platform/cocoa/ThermalMitigationNotifier.mm
M Source/WebKit/UIProcess/AuxiliaryProcessProxy.cpp
Log Message:
-----------
Cherry-pick bd0c3f38c2e8. rdar://113230434
[visionOS] Under thermal throttling Safari webpage went blank when navigating
https://bugs.webkit.org/show_bug.cgi?id=261374
<radar://113230434>
Reviewed by Dean Jackson.
When the system is throttled due to thermal pressure, we can easily hit process
timeouts and then web pages will fail to load.
* Source/WebKit/UIProcess/AuxiliaryProcessProxy.cpp:
(WebKit::adjustedTimeoutForThermalState):
(WebKit::AuxiliaryProcessProxy::AuxiliaryProcessProxy):
Query if thermal mitigation is enabled and increase process timeout if so.
* Source/WebCore/platform/ThermalMitigationNotifier.cpp:
(WebCore::ThermalMitigationNotifier::isThermalMitigationEnabled):
Default implementation.
* Source/WebCore/platform/ThermalMitigationNotifier.h:
* Source/WebCore/platform/cocoa/ThermalMitigationNotifier.mm:
(WebCore::isThermalMitigationEnabled):
(-[WebThermalMitigationObserver thermalMitigationEnabled]):
(WebCore::ThermalMitigationNotifier::isThermalMitigationEnabled):
Add static member function to query if thermal mitigation is enabled
as we don't need an instance function in AuxiliaryProcessProxy
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
Make ThermalMitigationNotifier.h a private header.
Canonical link: https://commits.webkit.org/268149@main
Identifier: 265423.1038 at safari-7616-branch
Commit: 1126e3596a0d694cc83d2ab5a3acdcbf903ce561
https://github.com/WebKit/WebKit/commit/1126e3596a0d694cc83d2ab5a3acdcbf903ce561
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/ios/WKVideoView.h
Log Message:
-----------
Cherry-pick f64be53a5d37. rdar://115850939
[iOS] REGRESSION(268041 at main): Unable to scroll Twitch.tv with touch atop video area
https://bugs.webkit.org/show_bug.cgi?id=261950
rdar://115850939
Reviewed by Simon Fraser.
Views which conform to WKNativelyInteractible (like WKModelView and WKSegmentedModelView) get special treatment inside `-_web_findDescendantViewAtPoint:`, so that touch events can be handled directly by the view itself. WKVideoView doesn't actually need to handle touch events directly, so it should just be a normal subclass of WKCompositingView.
* Source/WebKit/UIProcess/ios/WKVideoView.h:
Canonical link: https://commits.webkit.org/268331@main
Identifier: 265423.1039 at safari-7616-branch
Commit: 654466c2303edd0159e34e395c343627ab14cc10
https://github.com/WebKit/WebKit/commit/654466c2303edd0159e34e395c343627ab14cc10
Author: Tyler Wilcock <tyler_w at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
A LayoutTests/accessibility/display-contents/role-row-headers-expected.txt
A LayoutTests/accessibility/display-contents/role-row-headers.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp
M Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h
M Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl
M Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm
Log Message:
-----------
Cherry-pick 9e27509d48e3. rdar://115190637
AX: VoiceOver doesn't read column headers of cells within display:contents role="row" elements
https://bugs.webkit.org/show_bug.cgi?id=261353
rdar://problem/115190637
Reviewed by Chris Fleizach.
This happened due to a combination of two factors:
1. Table header containers and table columns rely on inserting children
for which they aren't the rightful parent in order to return the correct
information from AX APIs
2. AccessibilityObject::insertChild exits early if it detects a
display:contents child is trying to be inserted by something other
than it's rightful parent.
This patch makes an exception to rule 2 for table header containers and
table columns, resulting in display:contents elements matching the
behavior of non-display:contents elements.
* LayoutTests/accessibility/display-contents/role-row-headers-expected.txt: Added.
* LayoutTests/accessibility/display-contents/role-row-headers.html: Added.
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::insertChild):
* Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:
(WTR::AccessibilityUIElement::columns):
* Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
* Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl:
* Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:
(WTR::AccessibilityUIElement::columns):
Canonical link: https://commits.webkit.org/267838@main
Identifier: 265423.1040 at safari-7616-branch
Commit: 0a71cdbb1f3a700b4b30fae3e4304953515f87bf
https://github.com/WebKit/WebKit/commit/0a71cdbb1f3a700b4b30fae3e4304953515f87bf
Author: Jer Noble <jer.noble at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.h
M Source/WebCore/PAL/pal/cocoa/AVFoundationSoftLink.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm
Log Message:
-----------
Cherry-pick 7149a1fcc02e. rdar://113647070
[Cocoa] MSE video playback disappears after system interruption until pause/play
https://bugs.webkit.org/show_bug.cgi?id=261834
rdar://113647070
Reviewed by Tim Horton and Dean Jackson.
On some Cocoa platforms, the system will interrupt AVSampleBufferDisplayLayer rendering
when the process is backgrounded until a flush operation. This is detectable on iOS through
a specific error code, but API has been added for this purpose as well. Detect this state
and, when the page again becomes visible, flush visible AVSBDLs and re-enqueue with video
samples.
Flushing the display layer has the paradoxical effect of pausing playback, as a display
layer without a decoded sample will usually prevent playback from starting. In the case
where we are re-enqueuing due to visibility change, note the reason for the flush in the
MediaPlayerPrivate and do not pause playback in that case.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::playInternal):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::setPageIsVisible):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::shouldBePlaying const):
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::effectiveRateChanged):
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaSourcePrivateAVFObjC.mm:
(WebCore::MediaSourcePrivateAVFObjC::flushActiveSourceBuffersIfNeeded):
* Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(-[WebAVSampleBufferErrorListener beginObservingLayer:]):
(-[WebAVSampleBufferErrorListener layerRequiresFlushToResumeDecodingChanged:]):
(WebCore::SourceBufferPrivateAVFObjC::flushIfNeeded):
(WebCore::SourceBufferPrivateAVFObjC::layerRequiresFlushToResumeDecodingChanged):
(WebCore::SourceBufferPrivateAVFObjC::isReadyForMoreSamples):
Canonical link: https://commits.webkit.org/268283@main
Identifier: 265423.1041 at safari-7616-branch
Commit: 45f668f59cc5cd5602fab44c1d5672a4bffa976e
https://github.com/WebKit/WebKit/commit/45f668f59cc5cd5602fab44c1d5672a4bffa976e
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm
Log Message:
-----------
Cherry-pick 5aa322f6a3dd. rdar://115796405
REGRESSION (267539 at main): [iOS] Webpage unexpectedly scrolls down while typing in the find bar
https://bugs.webkit.org/show_bug.cgi?id=261913
rdar://115796405
Reviewed by Wenson Hsieh.
267539 at main adjusted WKWebView's "scroll to target rect" logic to account for
content insets, to ensure that content in the inset area does not hide the
target rect. However, it did not account for `-[WKWebView _obscuredInsets]`
Specifically, the targeted scrolling logic works by computing the scroll
delta between the current unobscured offset, and a new offset which reveals
the target. Following, 267539 at main found matches at the top of the page, could
have a negative target offset for content with insets, which was necessary to
fix the issue described in that change. However, the unobscured offset is
effectively clamped to (0, 0), as it comes from
`-[WKWebView _contentRectForUserInteraction]`, which adds obscured insets prior
to converting to content view coordinates. Consequently, a constant scroll delta
of `-_obscuredInsets.top` is computed when the page is scrolled to the top, and
there are obscured insets. This results in repeating scrolling as matches are
found at the top of the page.
Fix by accounting for the `_obscuredInsets` when determining the minimum
scroll position.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _scrollToRect:origin:minimumScrollDistance:]):
Add the obscured insets to the minimum content offset to determine a more
accurate minimum scrolling position. The logic additionally enforces a
maximum minimum content offset of (0, 0), as was the case before 267539 at main.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:
(TEST):
Canonical link: https://commits.webkit.org/268295@main
Identifier: 265423.1042 at safari-7616-branch
Commit: 5b43682dab5c24ff0dcba425b00422db2c12374b
https://github.com/WebKit/WebKit/commit/5b43682dab5c24ff0dcba425b00422db2c12374b
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebCore/page/scrolling/ScrollingTree.h
M Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTree.serialization.in
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.cpp
M Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.h
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollingCoordinator.mm
Log Message:
-----------
Cherry-pick 0e58303d1704. rdar://113335852
REGRESSION (macOS Sonoma): Mouse clicks in Safari are sometimes vertically offset
https://bugs.webkit.org/show_bug.cgi?id=261992
rdar://113335852
Reviewed by Richard Robinson.
Some combinations of user scrolling and programmatic scrolling can result in a state where the UI
process and web process end up with different notions of scroll position. That causes hover and
clicks to be offset from where they should be.
This change does not address the fundamental cause of the bug, but does address one common case,
which is a programmatic scroll triggered by a content size change; this occurs on sites that toggle
a header banner between fixed and non-fixed based on scroll position.
There was already code in `ScrollView::updateScrollbars()` to prevent scroll position clamping due
to size adjustment when rubberbanding, but on macOS with UI-side compositing,
`isRubberBandInProgress()` would always return false.
The fix is to maintain RemoteScrollingCoordinator's set of nodes with active rubberbands on macOS
like we do on iOS, since `isRubberBandInProgress()` consults this set. We follow
"nodeWithActiveUserScroll" in `RemoteScrollingUIState`, having
`RemoteScrollingCoordinatorProxyMac::setRubberBandingInProgressForNode()` update this state, which
is pushed to the web process as needed.
I tried to make a test, but this behavior is very timing dependent, and I failed to make a test
that was reliable.
* Source/WebCore/page/scrolling/ScrollingTree.h:
* Source/WebKit/Shared/RemoteLayerTree/RemoteLayerTree.serialization.in:
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.cpp:
(WebKit::RemoteScrollingUIState::encode const):
(WebKit::RemoteScrollingUIState::decode):
(WebKit::RemoteScrollingUIState::reset):
(WebKit::RemoteScrollingUIState::addNodeWithActiveRubberband):
(WebKit::RemoteScrollingUIState::removeNodeWithActiveRubberband):
(WebKit::RemoteScrollingUIState::clearNodesWithActiveRubberband):
* Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingUIState.h:
(WebKit::RemoteScrollingUIState::nodesWithActiveRubberband const):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingCoordinatorProxy.h:
(WebKit::RemoteScrollingCoordinatorProxy::setRubberBandingInProgressForNode):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingCoordinatorProxyMac.mm:
(WebKit::RemoteScrollingCoordinatorProxyMac::setRubberBandingInProgressForNode):
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.h:
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm:
(WebKit::RemoteScrollingTreeMac::setRubberBandingInProgressForNode):
* Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteScrollingCoordinator.mm:
(WebKit::RemoteScrollingCoordinator::scrollingStateInUIProcessChanged):
Canonical link: https://commits.webkit.org/268363@main
Identifier: 265423.1043 at safari-7616-branch
Commit: 8e70cce58ecdd38199d3226aa128f85c92204cc6
https://github.com/WebKit/WebKit/commit/8e70cce58ecdd38199d3226aa128f85c92204cc6
Author: Mike Wyrzykowski <mwyrzykowski at apple.com>
Date: 2023-09-25 (Mon, 25 Sep 2023)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/page/Page.cpp
M Source/WebCore/page/Page.h
M Source/WebCore/platform/graphics/MediaPlayer.cpp
M Source/WebCore/platform/graphics/MediaPlayer.h
M Source/WebCore/platform/graphics/MediaPlayerPrivate.h
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp
M Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h
M Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.h
M Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.cpp
M Source/WebCore/platform/graphics/win/MediaPlayerPrivateMediaFoundation.h
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp
M Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.messages.in
M Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp
M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
Log Message:
-----------
Cherry-pick ffbdce19ceb5. rdar://115086235
[visionOS] Audio from YouTube video is not spatial when multiple Safari windows are open.
https://bugs.webkit.org/show_bug.cgi?id=261609
<radar://115086235>
Reviewed by Dean Jackson.
Pass the sceneIdentifier down from the UI process to the GPU process so
that the AVAudioSession can use it to spatialize from the correct window.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::visibilityStateChanged):
* Source/WebCore/page/Page.cpp:
(WebCore::Page::sceneIdentifier const):
(WebCore::Page::setSceneIdentifier):
Store the scene identifier.
* Source/WebCore/page/Page.h:
Store the sceneIdentifier the Page corresponds to.
* Source/WebCore/platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::setPageIsVisible):
Pass the sceneIdentifier when changing the visibility of the MediaPlayer.
* Source/WebCore/platform/graphics/MediaPlayer.h:
* Source/WebCore/platform/graphics/MediaPlayerPrivate.h:
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:
(WebCore::MediaPlayerPrivateAVFoundation::setPageIsVisible):
Pass the sceneIdentifier when the visibility changes.
* Source/WebCore/platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaSourceAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaSourceAVFObjC::setPageIsVisible):
Call setIntendedSpatialExperience with a corresponding sceneIdentifier.
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
* Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setPageIsVisible):
sceneIdentifier is not needed for MediaPlayerPrivateMediaStreamAVFObjC
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.h:
* Source/WebCore/platform/graphics/cocoa/MediaPlayerPrivateWebM.mm:
(WebCore::MediaPlayerPrivateWebM::setPageIsVisible):
Or the webM player.
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.cpp:
(WebCore::MockMediaPlayerMediaSource::setPageIsVisible):
Member function is a no-op.
* Source/WebCore/platform/mock/mediasource/MockMediaPlayerMediaSource.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp:
(WebKit::RemoteMediaPlayerProxy::setPageIsVisible):
Pass the sceneIdentifier along.
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.messages.in:
Pass the sceneIdentifier along with SetPageIsVisible.
* Source/WebKit/UIProcess/API/ios/WKWebViewIOS.mm:
(-[WKWebView _registerForNotifications]):
(-[WKWebView _webViewWindowDidBecomeKey:]):
(-[WKWebView _webViewSceneWillEnterBackground:]):
(-[WKWebView _webViewSceneWillEnterForeground:]):
(-[WKWebView _webViewSceneDidActivate:]):
Update the sceneIdentifier whenever we receive a scene notification.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::setSceneIdentifier):
Pass the sceneIdentifier from the UI to the web process.
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:
(WebKit::MediaPlayerPrivateRemote::setPageIsVisible):
Pass the sceneIdentifier from the web to GPU process.
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::setSceneIdentifier):
Update the WebCore::Page's sceneIdentifier.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
Add a message to pass the sceneIdentifier.
Canonical link: https://commits.webkit.org/268152@main
Identifier: 265423.1044 at safari-7616-branch
Compare: https://github.com/WebKit/WebKit/compare/076add72e433...8e70cce58ecd
More information about the webkit-changes
mailing list