[webkit-changes] [WebKit/WebKit] 590a10: Revert bc90c50c6ba8. rdar://problem/102218624
bnham
noreply at github.com
Mon Nov 14 16:14:03 PST 2022
Branch: refs/heads/safari-7615.1.12-branch
Home: https://github.com/WebKit/WebKit
Commit: 590a10cfad69db307ea1fea736c4becf1c59c16b
https://github.com/WebKit/WebKit/commit/590a10cfad69db307ea1fea736c4becf1c59c16b
Author: Alan Coon <alancoon at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/PopUpSOAuthorizationSession.mm
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/RedirectSOAuthorizationSession.mm
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationCoordinator.mm
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm
M Source/WebKit/UIProcess/Cocoa/SOAuthorization/WKSOAuthorizationDelegate.mm
Log Message:
-----------
Revert bc90c50c6ba8. rdar://problem/102218624
Canonical link: https://commits.webkit.org/256138.30@safari-7615.1.12-branch
Commit: e5109892a8d1d3560535e41038cecd3709fed838
https://github.com/WebKit/WebKit/commit/e5109892a8d1d3560535e41038cecd3709fed838
Author: Ryan Haddad <ryanhaddad at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ExitFullscreenOnEnterPiP.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewCloseAllMediaPresentations.mm
Log Message:
-----------
Cherry-pick 01ba18b12b6e. rdar://problem/101873453
REGRESSION: 4 PiP API tests consistently failing on Big Sur EWS
https://bugs.webkit.org/show_bug.cgi?id=247373
rdar://101873453
Unreviewed test gardening.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ExitFullscreenOnEnterPiP.mm:
(TestWebKitAPI::TEST): Disable test on Big Sur to speed up EWS.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewCloseAllMediaPresentations.mm:
(TEST): Ditto.
Canonical link: https://commits.webkit.org/256245@main
Canonical link: https://commits.webkit.org/256138.31@safari-7615.1.12-branch
Commit: 88224c59640262f69cd54a3d0153d43171518c66
https://github.com/WebKit/WebKit/commit/88224c59640262f69cd54a3d0153d43171518c66
Author: Alex Christensen <achristensen at webkit.org>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/WebProcess/WebCoreSupport/WebPermissionController.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebPermissionController.h
Log Message:
-----------
Cherry-pick 0310eb3e5fd3. rdar://problem/100894959
WebPermissionControllerProxy::Query message reply should go to correct completion handler
https://bugs.webkit.org/show_bug.cgi?id=247295
rdar://100894959
Reviewed by Sihui Liu.
* Source/WebKit/WebProcess/WebCoreSupport/WebPermissionController.cpp:
(WebKit::WebPermissionController::tryProcessingRequests):
* Source/WebKit/WebProcess/WebCoreSupport/WebPermissionController.h:
Canonical link: https://commits.webkit.org/256298@main
Canonical link: https://commits.webkit.org/256138.32@safari-7615.1.12-branch
Commit: 0d33ea0b2a5a4539a0312b3b3071646659f51468
https://github.com/WebKit/WebKit/commit/0d33ea0b2a5a4539a0312b3b3071646659f51468
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/GPUProcess/mac/com.apple.WebKit.GPUProcess.sb.in
Log Message:
-----------
Cherry-pick 0c5dc1545fa5. rdar://problem/101599506
[GPUP][x64] Add sandbox access to accelerated graphics
https://bugs.webkit.org/show_bug.cgi?id=247367
rdar://101599506
Reviewed by Geoffrey Garen.
Add sandbox access to accelerated graphics in the GPU process on macOS. After upgrading to sandbox version 2, we explicitly
need to grant this access.
* Source/WebKit/GPUProcess/mac/com.apple.WebKit.GPUProcess.sb.in:
Canonical link: https://commits.webkit.org/256288@main
Canonical link: https://commits.webkit.org/256138.33@safari-7615.1.12-branch
Commit: d4937b54572a53b5f74ca9ee5107c8b6dd96c8d4
https://github.com/WebKit/WebKit/commit/d4937b54572a53b5f74ca9ee5107c8b6dd96c8d4
Author: Alan Baradlay <zalan at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M LayoutTests/css2.1/20110323/floats-zero-height-wrap-002-expected.html
A LayoutTests/fast/block/float/ignore-empty-float-expected.html
A LayoutTests/fast/block/float/ignore-empty-float.html
M Source/WebCore/layout/floats/FloatingContext.cpp
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
M Source/WebCore/layout/layouttree/LayoutGeometryRect.h
Log Message:
-----------
Cherry-pick 1abd9354b891. rdar://problem/102103989
REGRESSION (STP 157) CSS2/floats/floats-placement-001.html fails
https://bugs.webkit.org/show_bug.cgi?id=247631
<rdar://problem/102103989>
Reviewed by Antti Koivisto.
While empty (height: 0px) float boxes do have vertical positions, they should be ignored when
probing for horizontal constraints.
* LayoutTests/fast/block/float/ignore-empty-float-expected.html: Added.
* LayoutTests/fast/block/float/ignore-empty-float.html: Added.
* Source/WebCore/layout/floats/FloatingContext.cpp:
(WebCore::Layout::FloatingContext::constraints const):
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::tryPlacingFloatBox):
* Source/WebCore/layout/layouttree/LayoutGeometryRect.h:
(WebCore::Layout::Rect::isEmpty const):
css2.1/20110323/floats-zero-height-wrap-002.htm: Firefox agrees with the new result. The 0 height float box should not "indent" the linebox (not even when it has clearance).
Canonical link: https://commits.webkit.org/256530@main
Canonical link: https://commits.webkit.org/256138.34@safari-7615.1.12-branch
Commit: 6c10aab9042491be3b46ffd6c93d2f014906b8fd
https://github.com/WebKit/WebKit/commit/6c10aab9042491be3b46ffd6c93d2f014906b8fd
Author: Alan Baradlay <zalan at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/fast/block/float/float-box-with-negative-horizontal-margin-expected.html
A LayoutTests/fast/block/float/float-box-with-negative-horizontal-margin.html
M Source/WebCore/layout/floats/FloatingState.cpp
Log Message:
-----------
Cherry-pick 2d63e71e6b4c. rdar://problem/101779195
[LFC][IFC][Floats] Bootstrap 3 pagination widget layout is broken
https://bugs.webkit.org/show_bug.cgi?id=247322
<rdar://101779195>
Reviewed by Antti Koivisto.
A previous refactoring patch caused name shadowing on the incoming FloatItem (also make sure that we skip floats under each other properly).
* LayoutTests/fast/block/float/float-box-with-negative-horizontal-margin-expected.html: Added.
* LayoutTests/fast/block/float/float-box-with-negative-horizontal-margin.html: Added.
* Source/WebCore/layout/floats/FloatingState.cpp:
(WebCore::Layout::FloatingState::append):
Canonical link: https://commits.webkit.org/256206@main
Canonical link: https://commits.webkit.org/256138.35@safari-7615.1.12-branch
Commit: d67c5f660a35f4f56fd42e36b2ab7865a52353b4
https://github.com/WebKit/WebKit/commit/d67c5f660a35f4f56fd42e36b2ab7865a52353b4
Author: J Pascoe <j_pascoe at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm
Log Message:
-----------
Cherry-pick 60e1fb82eaf0. rdar://problem/102218641
Use instancesRespondToSelector instead of respondsToSelector for checking if Managed Domains SPI exists.
https://bugs.webkit.org/show_bug.cgi?id=247323
rdar://101812900
Reviewed by Wenson Hsieh.
* Source/WebKit/UIProcess/WebsiteData/Cocoa/WebsiteDataStoreCocoa.mm:
(WebKit::WebsiteDataStore::initializeManagedDomains):
This needs instancesRespondToSelector as we provide it a class.
Tested via manually installing profile on iOS device.
Canonical link: https://commits.webkit.org/256200@main
Canonical link: https://commits.webkit.org/256138.36@safari-7615.1.12-branch
Commit: 409ba8f8c575dd5f7a07f31e3ee41974f48c75da
https://github.com/WebKit/WebKit/commit/409ba8f8c575dd5f7a07f31e3ee41974f48c75da
Author: Cameron McCormack <heycam at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/platform/mac-monterey-wk2-lbse-text/TestExpectations
M Source/WebCore/rendering/svg/SVGResourcesCache.cpp
Log Message:
-----------
Cherry-pick 64eee924e808. rdar://problem/97335496
Rebuild SVGResources when relevant style property changes even with StyleDifference::Equal
https://bugs.webkit.org/show_bug.cgi?id=243808
rdar://97335496
Reviewed by Said Abou-Hallawa.
Consulting the StyleDifference value in
SVGResourceCache::clientStyleChanged is not an accurate way to determine
whether any property values were changed.
Specifically, if only the filter property is changed, RenderStyle::diff
returns StyleDifference::Equal and includes filter in the list of
"context-sensitive properties". If the context condition is met (which
per RenderElement::adjustStyleDifference is hasLayer()), we'll upgrade
the StyleDifference to some other value. But if not, which is the case
for SVG elements currently, we'll end up returning early from
SVGResourceCache::clientStyleChanged, and won't rebuild resources in
response to a property change.
This patch removes the early return on StyleDifference::Equal. (The
other use of the StyleDifference in this function, to avoid some work
when filter primitive properties are changed, is OK, since the
properties they care about will return accurate StyleDifference values.)
An alternative approach would be to introduce a new StyleDifference
value "UpdateSVGResources" to use when !hasLayer() and the filter
property changes.
* Source/WebCore/rendering/svg/SVGResourcesCache.cpp:
(WebCore::SVGResourcesCache::clientStyleChanged):
Canonical link: https://commits.webkit.org/256335@main
Canonical link: https://commits.webkit.org/256138.37@safari-7615.1.12-branch
Commit: 8ccd65ed8fbc36efecadbef3519602104f1343bc
https://github.com/WebKit/WebKit/commit/8ccd65ed8fbc36efecadbef3519602104f1343bc
Author: Youenn Fablet <youennf at gmail.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKit/GetUserMedia.mm
Log Message:
-----------
Cherry-pick 66fbf24f5aa8. rdar://problem/97926426
[ iPadOS ] CrashGPUProcessWhileCapturing and CrashGPUProcessWhileCapturingAndCalling are disabled
https://bugs.webkit.org/show_bug.cgi?id=247560
rdar://problem/97926426
Reviewed by Eric Carlson.
Reenable tests as they are passing locally.
* Tools/TestWebKitAPI/Tests/WebKit/GetUserMedia.mm:
Canonical link: https://commits.webkit.org/256423@main
Canonical link: https://commits.webkit.org/256138.38@safari-7615.1.12-branch
Commit: e52187a14acc8485d6b405b926b4a992724c653d
https://github.com/WebKit/WebKit/commit/e52187a14acc8485d6b405b926b4a992724c653d
Author: Tim Nguyen <ntim at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/fast/forms/change-input-type-during-setSelectionRange-crash-expected.txt
A LayoutTests/fast/forms/change-input-type-during-setSelectionRange-crash.html
M Source/WebCore/html/TextFieldInputType.cpp
M Source/WebCore/html/TextFieldInputType.h
Log Message:
-----------
Cherry-pick 6a72f93c2426. rdar://problem/102218614
REGRESSION(255229 at main): Do not restore selection when changing input types
https://bugs.webkit.org/show_bug.cgi?id=247472
rdar://101885601
Reviewed by Ryosuke Niwa.
Restoring selection range causes focusin events to fire, and allows the input type to be changed when the container is being recreated for a new input type.
* LayoutTests/fast/forms/change-input-type-during-setSelectionRange-crash-expected.txt: Added.
* LayoutTests/fast/forms/change-input-type-during-setSelectionRange-crash.html: Added.
* Source/WebCore/html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::createDataListDropdownIndicator):
(WebCore::TextFieldInputType::createContainer):
(WebCore::TextFieldInputType::updateAutoFillButton):
* Source/WebCore/html/TextFieldInputType.h:
Canonical link: https://commits.webkit.org/256323@main
Canonical link: https://commits.webkit.org/256138.39@safari-7615.1.12-branch
Commit: f9acaa92bf68321995d1560e938c6bde29301d11
https://github.com/WebKit/WebKit/commit/f9acaa92bf68321995d1560e938c6bde29301d11
Author: Alan Baradlay <zalan at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/fast/block/float/float-with-margin-bottom-incorrect-expected.html
A LayoutTests/fast/block/float/float-with-margin-bottom-incorrect.html
M Source/WebCore/layout/floats/FloatingState.h
Log Message:
-----------
Cherry-pick 76cfbdc3f398. rdar://problem/101193884
Layout issue on IMDB page for Robbie Coltrane
https://bugs.webkit.org/show_bug.cgi?id=247293
<rdar://101193884>
Reviewed by Simon Fraser.
Floating boxes overlap with their margin boxes.
* LayoutTests/fast/block/float/float-with-margin-bottom-incorrect-expected.html: Added.
* LayoutTests/fast/block/float/float-with-margin-bottom-incorrect.html: Added.
* Source/WebCore/layout/floats/FloatingState.h:
(WebCore::Layout::FloatingState::FloatItem::bottom const):
Canonical link: https://commits.webkit.org/256183@main
Canonical link: https://commits.webkit.org/256138.40@safari-7615.1.12-branch
Commit: 9c0c9c6b914a2919fd167ba1e5ccbb2d12d5b7b5
https://github.com/WebKit/WebKit/commit/9c0c9c6b914a2919fd167ba1e5ccbb2d12d5b7b5
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferences.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm
Log Message:
-----------
Cherry-pick 778b4272eb82. rdar://problem/101784583
REGRESSION (256117 at main): Unable to toggle network connection integrity using `-_setNetworkConnectionIntegrityEnabled:`
https://bugs.webkit.org/show_bug.cgi?id=247246
Reviewed by Tim Horton.
* Source/WebKit/UIProcess/API/Cocoa/WKWebpagePreferences.mm:
(-[WKWebpagePreferences _setNetworkConnectionIntegrityEnabled:]):
Add or remove the `Enabled` flag, instead of unconditionally adding the flag.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm:
Add a simple API test to exercise the change.
Canonical link: https://commits.webkit.org/256179@main
Canonical link: https://commits.webkit.org/256138.41@safari-7615.1.12-branch
Commit: 0d7ad20b814d3c297e30aa418f5769789c205580
https://github.com/WebKit/WebKit/commit/0d7ad20b814d3c297e30aa418f5769789c205580
Author: Sihui Liu <sihui_liu at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebCore/Modules/permissions/Permissions.cpp
Log Message:
-----------
Cherry-pick 7dc6d6b06a8c. rdar://problem/101789656
Regression(254490 at main): null dereference in Permissions::query
https://bugs.webkit.org/show_bug.cgi?id=247304
rdar://101789656
Reviewed by Wenson Hsieh and Alex Christensen.
When creating PermissionStatus in Permissions::query(), we did not null check document->page() before dereferencing it.
* Source/WebCore/Modules/permissions/Permissions.cpp:
(WebCore::Permissions::query):
Canonical link: https://commits.webkit.org/256209@main
Canonical link: https://commits.webkit.org/256138.42@safari-7615.1.12-branch
Commit: 0191d3f39fae67d9433cb633aefb9a024b4e4a68
https://github.com/WebKit/WebKit/commit/0191d3f39fae67d9433cb633aefb9a024b4e4a68
Author: Jer Noble <jer.noble at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/media/track/video-track-add-visible-expected.txt
A LayoutTests/media/track/video-track-add-visible.html
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick 7ff585820d47. rdar://problem/101785175
Apple.com/apple-events: Unable to enable subtitles on first watch of the keynote
https://bugs.webkit.org/show_bug.cgi?id=247549
rdar://101785175
Reviewed by Eric Carlson.
Two interlocking bugs prevent captions from being visible if tracks are added after the video is
loaded: 1) `m_processingPreferenceChange` is set to `true` in
`markCaptionAndSubtitleTracksAsUnconfigured()` and is only set to `false` if at least one text
track is present and therefore `configureTextTrackGroup()` is called. 2) the MediaControlsHost is
not notified that the video element's videoBox has changed, as it's only notified during style
updates, and will not necessarily have a RenderVideo attached at that point.
Clear `m_processingPreferenceChange` unconditionally at the end of `configureTextTracks()`. And call
the MediaControlsHost's `updateCaptionDisplaySizes()` when the media element is resized.
* LayoutTests/media/track/video-track-add-visible-expected.txt: Added.
* LayoutTests/media/track/video-track-add-visible.html: Added.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::configureTextTrackGroup):
(WebCore::HTMLMediaElement::layoutSizeChanged):
(WebCore::HTMLMediaElement::configureTextTracks):
Canonical link: https://commits.webkit.org/256408@main
Canonical link: https://commits.webkit.org/256138.43@safari-7615.1.12-branch
Commit: b2b4e9a18082acd5d0ebd2b5e0cbd183f58eae57
https://github.com/WebKit/WebKit/commit/b2b4e9a18082acd5d0ebd2b5e0cbd183f58eae57
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/editing/caret/ios/caret-color-auto-expected.txt
A LayoutTests/editing/caret/ios/caret-color-auto.html
A LayoutTests/editing/caret/ios/caret-color-currentcolor-expected.txt
A LayoutTests/editing/caret/ios/caret-color-currentcolor.html
M Source/WebCore/editing/FrameSelection.cpp
Log Message:
-----------
Cherry-pick 80d228d483a6. rdar://problem/102218556
REGRESSION (255095 at main): [iOS] 'caret-color: auto' displays a black caret color
https://bugs.webkit.org/show_bug.cgi?id=247382
rdar://101579150
Reviewed by Wenson Hsieh.
On iOS, the caret is drawn in the UIProcess, and the caret color is set using
post-layout data on EditorState. The system default caret color is used whenever
the Color is invalid.
Prior to 255095 at main, `RenderStyle::caretColor()` returned a Color, rather than
a StyleColor, and 'currentcolor' was represented using an invalid Color. The
initial value of caret color was the invalid Color, meaning that if no caret
color was specified by the author, or a value of 'currentcolor' was specified,
the system default caret color would be used.
Now that `RenderStyle::caretColor()` returns a StyleColor rather than a Color,
it must be resolved prior to its use. StyleColor is only aware of 'currentcolor',
absolute colors, and system colors. Since there is no "invalid" StyleColor, the
initial value is `StyleColor::currentColor()`. This color is then resolved to
the value of the element's color property, which is commonly black ('CanvasText' in
light mode). The UIProcess always receives a valid Color in the post-layout data,
and does not use the system default caret color.
To fix, return an invalid color when 'caret-color: auto' is specified. This
ensures the UIProcess will prefer the system default caret color. Additionally,
this solution preserves an improvement introduced by 255095 at main, which is that
explicitly specifying "caret-color: currentcolor" will customize the caret color.
* LayoutTests/editing/caret/ios/caret-color-auto-expected.txt: Added.
* LayoutTests/editing/caret/ios/caret-color-auto.html: Added.
* LayoutTests/editing/caret/ios/caret-color-currentcolor-expected.txt: Added.
* LayoutTests/editing/caret/ios/caret-color-currentcolor.html: Added.
* Source/WebCore/editing/FrameSelection.cpp:
(WebCore::CaretBase::computeCaretColor):
Canonical link: https://commits.webkit.org/256281@main
Canonical link: https://commits.webkit.org/256138.44@safari-7615.1.12-branch
Commit: 7b41bfdcd17fc66605d5925611e2e5542e75f99e
https://github.com/WebKit/WebKit/commit/7b41bfdcd17fc66605d5925611e2e5542e75f99e
Author: Per Arne Vollan <pvollan at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/com.apple.WebProcess.sb.in
Log Message:
-----------
Cherry-pick 829dab614cc1. rdar://problem/100386989
Fix crash in theme painting on macOS if GPU is not available
https://bugs.webkit.org/show_bug.cgi?id=247327
rdar://100386989
Reviewed by Geoffrey Garen.
This is a fix for a theme painting crash when Metal is unavailable and we're falling back to OpenGL. The fallback is using CVMS, which is
performing JIT'ing, but only JSC is allowed access to the JIT region in the WebContent process. This change blocks access to CVMS in the
sandbox. I have been able to disable Metal and force software GL in the debugger, and have confirmed that we do not crash with this change.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::gpuMachServices):
* Source/WebKit/WebProcess/com.apple.WebProcess.sb.in:
Canonical link: https://commits.webkit.org/256539@main
Canonical link: https://commits.webkit.org/256138.45@safari-7615.1.12-branch
Commit: 00c2dde4cbe92cb880cad0fc06b766493c69c902
https://github.com/WebKit/WebKit/commit/00c2dde4cbe92cb880cad0fc06b766493c69c902
Author: Aditya Keerthi <akeerthi at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
R LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field-expected.txt
R LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field.html
M Source/WebCore/html/HTMLTextFormControlElement.h
M Source/WebCore/html/TextFieldInputType.cpp
M Source/WebCore/html/TextFieldInputType.h
Log Message:
-----------
Cherry-pick 82deae87c0ac. rdar://problem/102218535
Crash when displaying autofill buttons
https://bugs.webkit.org/show_bug.cgi?id=247589
rdar://101938935
Reviewed by Wenson Hsieh.
Speculative revert of 255229 at main, as crashes have been observed when using
autofill buttons, following that change.
An alternate approach will need to be taken to fix webkit.org/b/245976.
* LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field-expected.txt: Removed.
* LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field.html: Removed.
* Source/WebCore/html/HTMLTextFormControlElement.h:
* Source/WebCore/html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::createDataListDropdownIndicator):
(WebCore::TextFieldInputType::createContainer):
* Source/WebCore/html/TextFieldInputType.h:
Canonical link: https://commits.webkit.org/256431@main
Canonical link: https://commits.webkit.org/256138.46@safari-7615.1.12-branch
Commit: a7fe968e8afd0c0d24f618d96781bea84653e04a
https://github.com/WebKit/WebKit/commit/a7fe968e8afd0c0d24f618d96781bea84653e04a
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A JSTests/stress/wasm-error-message-get-local.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 8ee3aa58b2a4. rdar://problem/101023980
[JSC] fix wrong text in WASM error message
https://bugs.webkit.org/show_bug.cgi?id=247280
rdar://101023980
Reviewed by Yusuke Suzuki.
Fix WASM error message for `local.get`.
* JSTests/stress/wasm-error-message-get-local.js: Added.
(shouldBe):
(async let):
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseIndexForLocal):
Canonical link: https://commits.webkit.org/256176@main
Canonical link: https://commits.webkit.org/256138.47@safari-7615.1.12-branch
Commit: cb77c9386c97ac2caac5047c4a4ae7cd71bbd6f1
https://github.com/WebKit/WebKit/commit/cb77c9386c97ac2caac5047c4a4ae7cd71bbd6f1
Author: Said Abou-Hallawa <said at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M LayoutTests/platform/ios-wk2/TestExpectations
M Source/WebCore/rendering/RenderLayerModelObject.cpp
M Source/WebCore/rendering/RenderObject.cpp
Log Message:
-----------
Cherry-pick 91fad1c1435f. rdar://problem/99801188
[ iOS15 Debug ] svg/compositing and svg/z-index tests assert in debug
https://bugs.webkit.org/show_bug.cgi?id=243515
rdar://99801188
Reviewed by Simon Fraser.
Move the call to RenderLayer::willBeDestroyed() from RenderObject::destroy() to
the layer owner class RenderLayerModelObject::destroyLayer(). This will account
for the LBSE which creates objects derived from RenderSVGModelObject.
* LayoutTests/platform/ios-wk2/TestExpectations:
* Source/WebCore/rendering/RenderLayerModelObject.cpp:
(WebCore::RenderLayerModelObject::destroyLayer):
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::destroy):
Canonical link: https://commits.webkit.org/256475@main
Canonical link: https://commits.webkit.org/256138.48@safari-7615.1.12-branch
Commit: f2886a69c5c715ea6cc0129c09ec3149fe33ff45
https://github.com/WebKit/WebKit/commit/f2886a69c5c715ea6cc0129c09ec3149fe33ff45
Author: Chris Dumez <cdumez at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 9c08d49c54bf. rdar://problem/100558596
Regression(254699 at main): fast/events/remove-iframe-during-toggle-crash.html is crashing
https://bugs.webkit.org/show_bug.cgi?id=247761
rdar://100558596
Reviewed by Geoffrey Garen.
254699 at main added a call to `policyChecker().stopCheck()` inside Document::open().
The stopCheck() call can clear `m_frame` so we need to null-check `m_frame` again
after the call.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::open):
Canonical link: https://commits.webkit.org/256552@main
Canonical link: https://commits.webkit.org/256138.49@safari-7615.1.12-branch
Commit: a2c477bf8afdee8f24f728873806f71b182b8a64
https://github.com/WebKit/WebKit/commit/a2c477bf8afdee8f24f728873806f71b182b8a64
Author: Vitor Roriz <vitor.roriz at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/css3/calc/inner-border-radius-longer-than-width-expected.html
A LayoutTests/css3/calc/inner-border-radius-longer-than-width.html
M Source/WebCore/display/css/DisplayBoxDecorationPainter.cpp
M Source/WebCore/rendering/BorderPainter.cpp
M Source/WebCore/rendering/style/BorderData.h
Log Message:
-----------
Cherry-pick bdb44a705275. rdar://problem/99885016
Assertion in WebCore::calculateAdjustedInnerBorder()
https://bugs.webkit.org/show_bug.cgi?id=247569
rdar://99885016
Reviewed by Antti Koivisto.
The adjusting function calculateAdjustedInnerBorder assumes it will be called only when:
[1]: the radii of one of the vertex of the edge we are painting is zero.
In BorderPainter::paintBorderSides(...), when borderWillArcInnerEdge(...) evaluates to true,
a path would be used for calling paintOneBorderSide(...) which would result in calculateAdjustedInnerBorder
being called when [1] does not hold for the test added here.
borderWillArcInnerEdge return trues if one of the radius it receives isZero(), however isZero() checks
that both height and width of the radius are zero, while one of them being zero would already invalidate
rendering the border as rounded, as described by https://w3c.github.io/csswg-drafts/css-backgrounds/#border-radii
Therefore, we propose changing borderWillArcInnerEdge to use isEmpty(), that checks that the height or width of
the radius is zero.
* LayoutTests/css3/calc/inner-border-radius-longer-than-width.html: Added.
* LayoutTests/css3/calc/inner-border-radius-longer-than-width-expected.html: Added.
This test would trigger the following assertion on calculateAdjustedInnerBorder():
'ASSERT(!(newRadii.bottomLeft().width() && newRadii.bottomRight().width()));'
* Source/WebCore/rendering/style/BorderData.h:
(WebCore::BorderData::hasBorderRadius const):
* Source/WebCore/display/css/DisplayBoxDecorationPainter.cpp:
(WebCore::Display::BorderPainter::borderWillArcInnerEdge):
* Source/WebCore/rendering/BorderPainter.cpp:
(WebCore::borderWillArcInnerEdge):
borderWillArchInnerEdge() and hasBorderRadius() uses now isEmpty() instead of isZero(), since isEmpty()
checks if either the height or width of the radius is zero.
Canonical link: https://commits.webkit.org/256445@main
Canonical link: https://commits.webkit.org/256138.50@safari-7615.1.12-branch
Commit: 0b7ce5fb933c22cc7d56598eea157d83f95c4a1d
https://github.com/WebKit/WebKit/commit/0b7ce5fb933c22cc7d56598eea157d83f95c4a1d
Author: Patrick Angle <pangle at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Cherry-pick c46be5c1183b. rdar://problem/102218310
WebDriver: [Cocoa] Regression(255359 at main) Exception when deleting remote automation session
https://bugs.webkit.org/show_bug.cgi?id=247384
rdar://101872145
Reviewed by Wenson Hsieh.
Revert the changes in 255359 at main and instead apply a more targeted approach to fixing that specific issue. Previous
attempts to fix this with more state management in `WKWindowVisibilityObserver` created more issues, so a more targeted
fix it is!
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(WebKit::WebViewImpl::viewWillMoveToWindowImpl):
(WebKit::WebViewImpl::viewWillMoveToWindow):
(WebKit::WebViewImpl::prepareForMoveToWindow):
(-[WKWindowVisibilityObserver _observeWindow:]): Deleted.
Canonical link: https://commits.webkit.org/256334@main
Canonical link: https://commits.webkit.org/256138.51@safari-7615.1.12-branch
Commit: afc12eaab2d2a63ae56bdd7d6171d24a07310457
https://github.com/WebKit/WebKit/commit/afc12eaab2d2a63ae56bdd7d6171d24a07310457
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
A LayoutTests/compositing/clipping/clip-stack-hidden-and-radius-expected.html
A LayoutTests/compositing/clipping/clip-stack-hidden-and-radius.html
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick c91af32319e7. rdar://problem/100514998
REGRESSION (STP): Animating image inside clipping border-radius ignores overflow hidden
https://bugs.webkit.org/show_bug.cgi?id=245769
rdar://100514998
Reviewed by Alan Baradlay.
When composited layers are clipped by non-stacking-context ancestors, we build an "ancestor clipping stack"
to represent those clips. Contiguous sets of non-scrollable, non-radius clips can be collapsed into
a single entry as the intersection of the clip rects, which is what `pushNonScrollableClip()` does
in `RenderLayerCompositor::computeAncestorClippingStack()`.
While walking up the ancestor chain, if we encounter a clip-with-radius or overflow:scroll,
we need to push any pending non-scrollable clip, but the border-radius clause here failed
to do that, resulting in an incorrect attempt to push a clip with an infinite rect at
the end.
Fix by ensuring that the `hasBorderRadius()` clause calls `pushNonScrollableClip()` just as
the `hasCompositedScrollableOverflow()` one does.
* LayoutTests/compositing/clipping/clip-stack-hidden-and-radius-expected.html: Added.
* LayoutTests/compositing/clipping/clip-stack-hidden-and-radius.html: Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeAncestorClippingStack const):
Canonical link: https://commits.webkit.org/256202@main
Canonical link: https://commits.webkit.org/256138.52@safari-7615.1.12-branch
Commit: ba2f1714efe3e35cb3b82ea0a0e8072068722102
https://github.com/WebKit/WebKit/commit/ba2f1714efe3e35cb3b82ea0a0e8072068722102
Author: Richard Robinson <richard_robinson2 at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M LayoutTests/css3/scroll-snap/scroll-padding-overflow-paging.html
M LayoutTests/fast/repaint/fixed-move-after-keyboard-scroll.html
M LayoutTests/fast/scrolling/keyboard-scrolling-distance-downArrow.html
M LayoutTests/fast/scrolling/mac/keyboard-scrolling-overflow-scroll.html
M LayoutTests/fast/scrolling/mac/smooth-scroll-recursive-frame-to-overflow.html
M LayoutTests/fast/scrolling/mac/smooth-scroll-recursive-overflow-to-overflow.html
M LayoutTests/fast/scrolling/unfocusing-page-while-keyboard-scrolling.html
M LayoutTests/platform/mac/fast/repaint/fixed-move-after-keyboard-scroll-expected.txt
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/page/FrameView.cpp
M Source/WebCore/page/FrameView.h
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/ScrollingCoordinatorTypes.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/ScrollingTreeScrollingNode.cpp
M Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h
M Source/WebCore/page/scrolling/ScrollingTreeScrollingNodeDelegate.h
M Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.h
M Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm
M Source/WebCore/platform/KeyboardScrollingAnimator.cpp
M Source/WebCore/platform/KeyboardScrollingAnimator.h
M Source/WebCore/platform/ScrollAnimation.cpp
M Source/WebCore/platform/ScrollAnimation.h
A Source/WebCore/platform/ScrollAnimationKeyboard.cpp
A Source/WebCore/platform/ScrollAnimationKeyboard.h
M Source/WebCore/platform/ScrollAnimator.cpp
M Source/WebCore/platform/ScrollableArea.cpp
M Source/WebCore/platform/ScrollableArea.h
M Source/WebCore/platform/ScrollingEffectsController.cpp
M Source/WebCore/platform/ScrollingEffectsController.h
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp
M Source/WebCore/rendering/RenderLayerScrollableArea.h
M Tools/TestWebKitAPI/Tests/WebKit/SpacebarScrolling.cpp
Log Message:
-----------
Cherry-pick cb5925ef6a3e. rdar://problem/101052130
Scrolling by pressing space bar has regressed in trunk, is choppy (not 120Hz)
https://bugs.webkit.org/show_bug.cgi?id=246878
rdar://101052130
Reviewed by Simon Fraser.
Moves keyboard smooth scrolling onto the scrolling thread instead of the main thread.
A new `ScrollAnimation` is created to facilitate this, `ScrollAnimationKeyboard`. Most
of the changes are to allow the state to propogate through the various classes and
the scrolling tree.
Since keyboard scrolling is now on a different thread, some tests had to be modified to
enable the `AsyncOverflowScrollingEnabled` and `AsyncFrameScrollingEnabled` settings.
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/page/FrameView.cpp:
(WebCore::FrameView::requestStartKeyboardAnimation):
(WebCore::FrameView::requestFinishKeyboardAnimation):
* Source/WebCore/page/FrameView.h:
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::requestStartKeyboardAnimation):
(WebCore::AsyncScrollingCoordinator::requestFinishKeyboardAnimation):
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.h:
* Source/WebCore/page/scrolling/ScrollingCoordinator.h:
(WebCore::ScrollingCoordinator::requestStartKeyboardAnimation):
(WebCore::ScrollingCoordinator::requestFinishKeyboardAnimation):
* Source/WebCore/page/scrolling/ScrollingStateNode.h:
* Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp:
(WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode):
(WebCore::ScrollingStateScrollingNode::setKeyboardScrollData):
(WebCore::ScrollingStateScrollingNode::setKeyboardScrollEndData):
* Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h:
(WebCore::ScrollingStateScrollingNode::keyboardScrollData const):
(WebCore::ScrollingStateScrollingNode::keyboardScrollEndData const):
* Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.cpp:
(WebCore::ScrollingTreeScrollingNode::commitStateAfterChildren):
(WebCore::ScrollingTreeScrollingNode::handleKeyboardScrollRequest):
(WebCore::ScrollingTreeScrollingNode::handleKeyboardScrollEndRequest):
* Source/WebCore/page/scrolling/ScrollingTreeScrollingNode.h:
* Source/WebCore/page/scrolling/ScrollingTreeScrollingNodeDelegate.h:
(WebCore::ScrollingTreeScrollingNodeDelegate::handleKeyboardScrollRequest):
(WebCore::ScrollingTreeScrollingNodeDelegate::handleKeyboardScrollEndRequest):
* Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.h:
* Source/WebCore/page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm:
(WebCore::ScrollingTreeScrollingNodeDelegateMac::handleKeyboardScrollRequest):
(WebCore::ScrollingTreeScrollingNodeDelegateMac::handleKeyboardScrollEndRequest):
* Source/WebCore/platform/KeyboardScrollingAnimator.cpp:
(WebCore::KeyboardScrollingAnimator::KeyboardScrollingAnimator):
(WebCore::KeyboardScrollingAnimator::beginKeyboardScrollGesture):
(WebCore::KeyboardScrollingAnimator::handleKeyUpEvent):
(WebCore::KeyboardScrollingAnimator::stopScrollingImmediately):
(WebCore::perpendicularAbsoluteUnitVector): Deleted.
(WebCore::KeyboardScrollingAnimator::updateKeyboardScrollPosition): Deleted.
(WebCore::farthestPointInDirection): Deleted.
(WebCore::KeyboardScrollingAnimator::stopKeyboardScrollAnimation): Deleted.
* Source/WebCore/platform/KeyboardScrollingAnimator.h:
* Source/WebCore/platform/ScrollAnimation.cpp:
(WebCore::operator<<):
* Source/WebCore/platform/ScrollAnimation.h:
* Source/WebCore/platform/ScrollAnimationKeyboard.cpp: Added.
(WebCore::perpendicularAbsoluteUnitVector):
(WebCore::boxSideForDirection):
(WebCore::farthestPointInDirection):
(WebCore::ScrollAnimationKeyboard::scrollableDirectionsFromPosition):
(WebCore::ScrollAnimationKeyboard::ScrollAnimationKeyboard):
(WebCore::ScrollAnimationKeyboard::retargetActiveAnimation):
(WebCore::ScrollAnimationKeyboard::serviceAnimation):
(WebCore::ScrollAnimationKeyboard::startKeyboardScroll):
(WebCore::ScrollAnimationKeyboard::stopKeyboardScrollAnimation):
(WebCore::ScrollAnimationKeyboard::finishKeyboardScroll):
(WebCore::ScrollAnimationKeyboard::animateScroll):
(WebCore::ScrollAnimationKeyboard::debugDescription const):
* Source/WebCore/platform/ScrollAnimationKeyboard.h: Copied from Source/WebCore/platform/ScrollAnimation.cpp.
* Source/WebCore/platform/ScrollAnimator.cpp:
(WebCore::ScrollAnimator::ScrollAnimator):
* Source/WebCore/platform/ScrollableArea.cpp:
(WebCore::ScrollableArea::beginKeyboardScroll):
(WebCore::ScrollableArea::endKeyboardScroll):
* Source/WebCore/platform/ScrollableArea.h:
(WebCore::ScrollableArea::requestStartKeyboardAnimation):
(WebCore::ScrollableArea::requestFinishKeyboardAnimation):
* Source/WebCore/platform/ScrollingEffectsController.cpp:
(WebCore::ScrollingEffectsController::animationCallback):
(WebCore::ScrollingEffectsController::startKeyboardScroll):
(WebCore::ScrollingEffectsController::finishKeyboardScroll):
(WebCore::ScrollingEffectsController::updateKeyboardScrollingAnimatingState):
(WebCore::ScrollingEffectsController::scrollAnimationWillStart):
* Source/WebCore/platform/ScrollingEffectsController.h:
(WebCore::ScrollingEffectsControllerClient::updateKeyboardScrollPosition): Deleted.
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::requestStartKeyboardAnimation):
(WebCore::RenderLayerScrollableArea::requestFinishKeyboardAnimation):
* Source/WebCore/rendering/RenderLayerScrollableArea.h:
Canonical link: https://commits.webkit.org/256266@main
Canonical link: https://commits.webkit.org/256138.53@safari-7615.1.12-branch
Commit: 02c28d10f4fba36c9c0bd8cebad49a8693549dcd
https://github.com/WebKit/WebKit/commit/02c28d10f4fba36c9c0bd8cebad49a8693549dcd
Author: Youenn Fablet <youennf at gmail.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/ThirdParty/libwebrtc/Configurations/libwebrtc.iOS.exp
M Source/ThirdParty/libwebrtc/Configurations/libwebrtc.iOSsim.exp
M Source/ThirdParty/libwebrtc/Configurations/libwebrtc.mac.exp
M Source/ThirdParty/libwebrtc/Source/webrtc/sdk/WebKit/WebKitUtilities.h
M Source/ThirdParty/libwebrtc/Source/webrtc/sdk/WebKit/WebKitUtilities.mm
Log Message:
-----------
Cherry-pick d19c17dc2cdb. rdar://problem/101476647
Remove webrtc::copyPixelBufferInI420Buffer
https://bugs.webkit.org/show_bug.cgi?id=247178
rdar://101476647
Reviewed by Eric Carlson.
Remove no longer needed code.
* Source/ThirdParty/libwebrtc/Configurations/libwebrtc.iOS.exp:
* Source/ThirdParty/libwebrtc/Configurations/libwebrtc.iOSsim.exp:
* Source/ThirdParty/libwebrtc/Configurations/libwebrtc.mac.exp:
* Source/ThirdParty/libwebrtc/Source/webrtc/sdk/WebKit/WebKitUtilities.h:
* Source/ThirdParty/libwebrtc/Source/webrtc/sdk/WebKit/WebKitUtilities.mm:
(webrtc::copyPixelBufferInI420Buffer): Deleted.
Canonical link: https://commits.webkit.org/256271@main
Canonical link: https://commits.webkit.org/256138.54@safari-7615.1.12-branch
Commit: 8f77fabda8179ade2d0c739dd14e0a5cdb016be1
https://github.com/WebKit/WebKit/commit/8f77fabda8179ade2d0c739dd14e0a5cdb016be1
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebCore/platform/ios/PasteboardIOS.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm
Log Message:
-----------
Cherry-pick d7150a05e06e. rdar://problem/96853551
REGRESSION (255932 at main): Text copied from Notes pastes as attachment in Mail compose
https://bugs.webkit.org/show_bug.cgi?id=247778
rdar://96853551
Reviewed by Aditya Keerthi.
After the fix in `255932 at main`, copying rich text from Notes on iOS and pasting into Mail compose
results in an attachment being inserted into the document. This is because Notes writes the UTI
"com.apple.notes.richtext" to the pasteboard, which conforms to `UTTypeCompositeContent` but
isn't one of RTFD/WebArchive, so we treat it as an attachment by default.
To avoid this problem while preserving the original intent behind `255932 at main`, we narrow the fix
to special case `UTTypePDF`, rather than adding blanket rules to treat composite content as
attachments.
Test: WKAttachmentTestsIOS.PasteRichTextCopiedFromNotes
* Source/WebCore/platform/ios/PasteboardIOS.mm:
(WebCore::shouldTreatAsAttachmentByDefault):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/256565@main
Canonical link: https://commits.webkit.org/256138.55@safari-7615.1.12-branch
Commit: 4367e93f15cb193809e2ddcb5c03c852e49789fd
https://github.com/WebKit/WebKit/commit/4367e93f15cb193809e2ddcb5c03c852e49789fd
Author: Commit Queue <commit-queue at webkit.org>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/image-loading-lazy-multiple-times-expected.txt
M LayoutTests/imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/image-loading-lazy-multiple-times.html
M Source/WebCore/loader/ImageLoader.cpp
Log Message:
-----------
Cherry-pick ddc412db83b0. rdar://problem/101676331
Unreviewed, reverting r254127 at main.
https://bugs.webkit.org/show_bug.cgi?id=247297
Causes some images with loading=lazy to not load
Reverted changeset:
"Fix image-loading-lazy-multiple-times.html"
https://bugs.webkit.org/show_bug.cgi?id=216979
https://commits.webkit.org/254127@main
Canonical link: https://commits.webkit.org/256175@main
Canonical link: https://commits.webkit.org/256138.56@safari-7615.1.12-branch
Commit: 275135219a36d8e85c60bc4fe3ddcd78c4f5ec39
https://github.com/WebKit/WebKit/commit/275135219a36d8e85c60bc4fe3ddcd78c4f5ec39
Author: Jer Noble <jer.noble at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick e4f004bdfd57. rdar://problem/100892574
CRASH: Assertion in WPT /webvtt/rendering/cues-with-video/processing-model/regions/viewportanchor_y_50_percent.html
https://bugs.webkit.org/show_bug.cgi?id=247333
rdar://100892574
Reviewed by Eric Carlson.
An existing check protects HTMLMediaElement::configureTextTrackDisplay() from making script-exposed changes while a
Document and it's ActiveDOMObjects has been stopped, but also needs to protect when those same objects are Suspended.
Re-use HTMLMediaElement::isSuspended() (which encompasses both those above checks) everywhere within HTMLMediaElement.
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::userCancelledLoad):
(WebCore::HTMLMediaElement::exitFullscreen):
(WebCore::HTMLMediaElement::configureTextTrackDisplay):
(WebCore::HTMLMediaElement::updateMediaControlsAfterPresentationModeChange):
Canonical link: https://commits.webkit.org/256352@main
Canonical link: https://commits.webkit.org/256138.57@safari-7615.1.12-branch
Commit: 5737ac0505ee3037f07ee5e089961179614845d9
https://github.com/WebKit/WebKit/commit/5737ac0505ee3037f07ee5e089961179614845d9
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M JSTests/stress/class-static-block.js
M Source/JavaScriptCore/parser/Parser.cpp
Log Message:
-----------
Cherry-pick d102e7a7748f. rdar://problem/101940195
Fix duplicated name in class static block
https://bugs.webkit.org/show_bug.cgi?id=247426
rdar://101940195
Reviewed by Mark Lam.
When parsing block statement in static block mode, we should alllow
var declaration in the block scope. This is becuase static block is
evaluated as a function call, where function scope should allow var
declaration. In this case, var variables would be bounded under the
static block scope when checking hoistable declarations in the parsing phase.
* JSTests/stress/class-static-block.js:
(foo.x):
(foo):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseBlockStatement):
* Source/JavaScriptCore/parser/Parser.h:
(JSC::Scope::setAllowsVarDeclarations):
Canonical link: https://commits.webkit.org/256311@main
Canonical link: https://commits.webkit.org/256138.58@safari-7615.1.12-branch
Commit: 43d5cbf681049d4636f9d5f8298a177fbf4501c7
https://github.com/WebKit/WebKit/commit/43d5cbf681049d4636f9d5f8298a177fbf4501c7
Author: Patrick Angle <pangle at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebCore/css/makeprop.pl
Log Message:
-----------
Cherry-pick 49637d036739. rdar://problem/101876145
Web Inspector: Regression(256223 at main) Assertion in LayoutTests/inspector/css/getSupportedCSSProperties.html at WebCore::CSSProperty::isInheritedProperty
https://bugs.webkit.org/show_bug.cgi?id=247398
rdar://101876145
Reviewed by Sam Weinig.
Known CSSPropertyID values are actually 0 thru `firstCSSProperty` + `numCSSProperties`. `firstCSSProperty` has a value
of 2, and `numCSSProperties` is 512, but the last property has an ID of 513.
* Source/WebCore/css/makeprop.pl:
Canonical link: https://commits.webkit.org/256275@main
Canonical link: https://commits.webkit.org/256138.59@safari-7615.1.12-branch
Commit: 0c186e2bde004bce6927b206837e75b0733cc195
https://github.com/WebKit/WebKit/commit/0c186e2bde004bce6927b206837e75b0733cc195
Author: Ben Nham <nham at apple.com>
Date: 2022-11-14 (Mon, 14 Nov 2022)
Changed paths:
M Source/WebKit/Platform/cocoa/SharedMemoryCocoa.cpp
Log Message:
-----------
Cherry-pick eece793cfe01. rdar://problem/102215064
Shared memory IPC sometimes fails under Rosetta
https://bugs.webkit.org/show_bug.cgi?id=247691
rdar://99827403
Reviewed by Geoffrey Garen.
Sending a SharedMemory object over IPC sometimes fails when the sending process runs under Rosetta
and the receiving process is ARM64. This is due to the Rosetta process using a 4KB page size and the
receiving process using a 16KB page size. On the sending side, SharedMemory calls `safeRoundPage` on
the actual size to round the allocation up to a 4KB boundary. On the receiving side, SharedMemory
calls `safeRoundPage` again on the actual size, but now rounds up to a 16KB boundary. This means the
receiving side might try to ask the kernel to map a larger memory region that was created on the
sending side. This causes `mach_vm_map` to fail with an invalid argument error.
One easy way to trigger this issue is to implement a URL scheme handler in a Rosetta UIProcess that
returns some small payload. This will result in a buffer being sent to an ARM WebContent process.
To fix this, the kernel team recommended that we:
1. Stop rounding the page size in user space. The syscalls we use here (e.g. mach_vm_allocate) are
already documented to handle page rounding for you.
2. Defensively handle the case where we might try to share a non-page-aligned region. (This actually
doesn't apply in our case since `SharedMemory::allocate` is always returning a page-aligned region
but it's good to do in case someone adds that capability in the future.) We do this by using
`MAP_MEM_USE_DATA_ADDR` with `mach_make_memory_entry_64` and `VM_FLAGS_RETURN_DATA_ADDR` with
`mach_vm_map`.
This patch implements those recommendations.
To test this, I ran `URLSchemeHandler.Basic` under Rosetta. Before this patch, WebContent crashed
with the assert `Received invalid message: 'WebPage_URLSchemeTaskDidReceiveData'`. After this patch,
the test no longer crashes.
* Source/WebKit/Platform/cocoa/SharedMemoryCocoa.cpp:
(WebKit::SharedMemory::Handle::decode):
(WebKit::SharedMemory::allocate):
(WebKit::makeMemoryEntry):
(WebKit::SharedMemory::map):
(WebKit::SharedMemory::~SharedMemory):
(WebKit::SharedMemory::createHandle):
(WebKit::safeRoundPage): Deleted.
Canonical link: https://commits.webkit.org/256505@main
Canonical link: https://commits.webkit.org/256138.60@safari-7615.1.12-branch
Compare: https://github.com/WebKit/WebKit/compare/1e37fe268593...0c186e2bde00
More information about the webkit-changes
mailing list