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 <[email protected]>
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/[email protected]
Commit: e5109892a8d1d3560535e41038cecd3709fed838
https://github.com/WebKit/WebKit/commit/e5109892a8d1d3560535e41038cecd3709fed838
Author: Ryan Haddad <[email protected]>
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/[email protected]
Commit: 88224c59640262f69cd54a3d0153d43171518c66
https://github.com/WebKit/WebKit/commit/88224c59640262f69cd54a3d0153d43171518c66
Author: Alex Christensen <[email protected]>
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/[email protected]
Commit: 0d33ea0b2a5a4539a0312b3b3071646659f51468
https://github.com/WebKit/WebKit/commit/0d33ea0b2a5a4539a0312b3b3071646659f51468
Author: Per Arne Vollan <[email protected]>
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/[email protected]
Commit: d4937b54572a53b5f74ca9ee5107c8b6dd96c8d4
https://github.com/WebKit/WebKit/commit/d4937b54572a53b5f74ca9ee5107c8b6dd96c8d4
Author: Alan Baradlay <[email protected]>
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/[email protected]
Commit: 6c10aab9042491be3b46ffd6c93d2f014906b8fd
https://github.com/WebKit/WebKit/commit/6c10aab9042491be3b46ffd6c93d2f014906b8fd
Author: Alan Baradlay <[email protected]>
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/[email protected]
Commit: d67c5f660a35f4f56fd42e36b2ab7865a52353b4
https://github.com/WebKit/WebKit/commit/d67c5f660a35f4f56fd42e36b2ab7865a52353b4
Author: J Pascoe <[email protected]>
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/[email protected]
Commit: 409ba8f8c575dd5f7a07f31e3ee41974f48c75da
https://github.com/WebKit/WebKit/commit/409ba8f8c575dd5f7a07f31e3ee41974f48c75da
Author: Cameron McCormack <[email protected]>
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/[email protected]
Commit: 8ccd65ed8fbc36efecadbef3519602104f1343bc
https://github.com/WebKit/WebKit/commit/8ccd65ed8fbc36efecadbef3519602104f1343bc
Author: Youenn Fablet <[email protected]>
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/[email protected]
Commit: e52187a14acc8485d6b405b926b4a992724c653d
https://github.com/WebKit/WebKit/commit/e52187a14acc8485d6b405b926b4a992724c653d
Author: Tim Nguyen <[email protected]>
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@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/[email protected]
Commit: f9acaa92bf68321995d1560e938c6bde29301d11
https://github.com/WebKit/WebKit/commit/f9acaa92bf68321995d1560e938c6bde29301d11
Author: Alan Baradlay <[email protected]>
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/[email protected]
Commit: 9c0c9c6b914a2919fd167ba1e5ccbb2d12d5b7b5
https://github.com/WebKit/WebKit/commit/9c0c9c6b914a2919fd167ba1e5ccbb2d12d5b7b5
Author: Wenson Hsieh <[email protected]>
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@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/[email protected]
Commit: 0d7ad20b814d3c297e30aa418f5769789c205580
https://github.com/WebKit/WebKit/commit/0d7ad20b814d3c297e30aa418f5769789c205580
Author: Sihui Liu <[email protected]>
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@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/[email protected]
Commit: 0191d3f39fae67d9433cb633aefb9a024b4e4a68
https://github.com/WebKit/WebKit/commit/0191d3f39fae67d9433cb633aefb9a024b4e4a68
Author: Jer Noble <[email protected]>
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/[email protected]
Commit: b2b4e9a18082acd5d0ebd2b5e0cbd183f58eae57
https://github.com/WebKit/WebKit/commit/b2b4e9a18082acd5d0ebd2b5e0cbd183f58eae57
Author: Aditya Keerthi <[email protected]>
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@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@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@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/[email protected]
Commit: 7b41bfdcd17fc66605d5925611e2e5542e75f99e
https://github.com/WebKit/WebKit/commit/7b41bfdcd17fc66605d5925611e2e5542e75f99e
Author: Per Arne Vollan <[email protected]>
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/[email protected]
Commit: 00c2dde4cbe92cb880cad0fc06b766493c69c902
https://github.com/WebKit/WebKit/commit/00c2dde4cbe92cb880cad0fc06b766493c69c902
Author: Aditya Keerthi <[email protected]>
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@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/[email protected]
Commit: a7fe968e8afd0c0d24f618d96781bea84653e04a
https://github.com/WebKit/WebKit/commit/a7fe968e8afd0c0d24f618d96781bea84653e04a
Author: Yijia Huang <[email protected]>
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/[email protected]
Commit: cb77c9386c97ac2caac5047c4a4ae7cd71bbd6f1
https://github.com/WebKit/WebKit/commit/cb77c9386c97ac2caac5047c4a4ae7cd71bbd6f1
Author: Said Abou-Hallawa <[email protected]>
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/[email protected]
Commit: f2886a69c5c715ea6cc0129c09ec3149fe33ff45
https://github.com/WebKit/WebKit/commit/f2886a69c5c715ea6cc0129c09ec3149fe33ff45
Author: Chris Dumez <[email protected]>
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@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@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/[email protected]
Commit: a2c477bf8afdee8f24f728873806f71b182b8a64
https://github.com/WebKit/WebKit/commit/a2c477bf8afdee8f24f728873806f71b182b8a64
Author: Vitor Roriz <[email protected]>
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/[email protected]
Commit: 0b7ce5fb933c22cc7d56598eea157d83f95c4a1d
https://github.com/WebKit/WebKit/commit/0b7ce5fb933c22cc7d56598eea157d83f95c4a1d
Author: Patrick Angle <[email protected]>
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@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@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/[email protected]
Commit: afc12eaab2d2a63ae56bdd7d6171d24a07310457
https://github.com/WebKit/WebKit/commit/afc12eaab2d2a63ae56bdd7d6171d24a07310457
Author: Simon Fraser <[email protected]>
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/[email protected]
Commit: ba2f1714efe3e35cb3b82ea0a0e8072068722102
https://github.com/WebKit/WebKit/commit/ba2f1714efe3e35cb3b82ea0a0e8072068722102
Author: Richard Robinson <[email protected]>
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/[email protected]
Commit: 02c28d10f4fba36c9c0bd8cebad49a8693549dcd
https://github.com/WebKit/WebKit/commit/02c28d10f4fba36c9c0bd8cebad49a8693549dcd
Author: Youenn Fablet <[email protected]>
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/[email protected]
Commit: 8f77fabda8179ade2d0c739dd14e0a5cdb016be1
https://github.com/WebKit/WebKit/commit/8f77fabda8179ade2d0c739dd14e0a5cdb016be1
Author: Wenson Hsieh <[email protected]>
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@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@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@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/[email protected]
Commit: 4367e93f15cb193809e2ddcb5c03c852e49789fd
https://github.com/WebKit/WebKit/commit/4367e93f15cb193809e2ddcb5c03c852e49789fd
Author: Commit Queue <[email protected]>
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@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/[email protected]
Commit: 275135219a36d8e85c60bc4fe3ddcd78c4f5ec39
https://github.com/WebKit/WebKit/commit/275135219a36d8e85c60bc4fe3ddcd78c4f5ec39
Author: Jer Noble <[email protected]>
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/[email protected]
Commit: 5737ac0505ee3037f07ee5e089961179614845d9
https://github.com/WebKit/WebKit/commit/5737ac0505ee3037f07ee5e089961179614845d9
Author: Yijia Huang <[email protected]>
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/[email protected]
Commit: 43d5cbf681049d4636f9d5f8298a177fbf4501c7
https://github.com/WebKit/WebKit/commit/43d5cbf681049d4636f9d5f8298a177fbf4501c7
Author: Patrick Angle <[email protected]>
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@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/[email protected]
Commit: 0c186e2bde004bce6927b206837e75b0733cc195
https://github.com/WebKit/WebKit/commit/0c186e2bde004bce6927b206837e75b0733cc195
Author: Ben Nham <[email protected]>
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/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/1e37fe268593...0c186e2bde00
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
