Branch: refs/heads/safari-7615.1.18-branch
Home: https://github.com/WebKit/WebKit
Commit: ef9061c6655308a54f3a1b0e00dfee63d12eb7f7
https://github.com/WebKit/WebKit/commit/ef9061c6655308a54f3a1b0e00dfee63d12eb7f7
Author: Jer Noble <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm
Log Message:
-----------
Cherry-pick 139d1d031bd3. rdar://problem/104475956
-pictureInPicturePlayerLayerView is unavailable on watchOS
https://bugs.webkit.org/show_bug.cgi?id=250910
rdar://104475956
Reviewed by Chris Dumez and Eric Carlson.
Add a HAVE_PICTUREINPICTUREPLAYERLAYERVIEW guard and use it liberally in
VideoFullscreenInterfaceAVKit.mm.
* Source/WTF/wtf/PlatformHave.h:
* Source/WebCore/platform/ios/VideoFullscreenInterfaceAVKit.mm:
(WebAVPlayerLayerView_dealloc):
(allocWebAVPlayerLayerViewInstance):
(VideoFullscreenInterfaceAVKit::videoDimensionsChanged):
(VideoFullscreenInterfaceAVKit::doEnterFullscreen):
Canonical link: https://commits.webkit.org/259189@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: e3fdd60e62d427bd1e0c311081c5ed8ca5e21b90
https://github.com/WebKit/WebKit/commit/e3fdd60e62d427bd1e0c311081c5ed8ca5e21b90
Author: Arunsundar Kannan <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A LayoutTests/fast/forms/textfield-input-type-crash-onblur-expected.txt
A LayoutTests/fast/forms/textfield-input-type-crash-onblur.html
M Source/WebCore/html/HTMLInputElement.cpp
M Source/WebCore/html/HTMLOptionElement.cpp
M Source/WebCore/html/TextFieldInputType.cpp
Log Message:
-----------
Cherry-pick 665170902bfa. rdar://problem/102886109
UAF crash occurs during a style update when an older freed HTMLElement is
accessed
https://bugs.webkit.org/show_bug.cgi?id=247389
rdar://101420898
Reviewed by Ryosuke Niwa and Ryan Haddad.
* LayoutTests/fast/forms/textfield-input-type-crash-onblur-expected.txt:
Added.
* LayoutTests/fast/forms/textfield-input-type-crash-onblur.html: Added.
* Source/WebCore/html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::dataListMayHaveChanged):
* Source/WebCore/html/HTMLOptionElement.cpp:
(WebCore::HTMLOptionElement::childrenChanged):
* Source/WebCore/html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::createDataListDropdownIndicator):
(WebCore::TextFieldInputType::dataListMayHaveChanged):
Canonical link: https://commits.webkit.org/252432.838@safari-7614-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 03a471d8b8f5e773bc5416b4fcc25f3643d5207d
https://github.com/WebKit/WebKit/commit/03a471d8b8f5e773bc5416b4fcc25f3643d5207d
Author: Razvan Caliman <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/DetailsSection.css
Log Message:
-----------
Cherry-pick 0d3847719a53. rdar://problem/103953134
Web Inspector: Regression [r258503@main] Computed style sections have
yellow background
https://bugs.webkit.org/show_bug.cgi?id=250204
Reviewed by Patrick Angle.
Keep a very specific selector for detail section rows
that have a warning child element to avoid marking
other types of rows with a yellow background color.
* Source/WebInspectorUI/UserInterface/Views/DetailsSection.css:
(.details-section > .content > .group > .row:is(.simple,
.font-variation):has(.warning)):
(.details-section > .content > .group > .row:is(.simple, .font-variation) >
.warning):
(.details-section > .content > .group > .row:has(.warning)): Deleted.
(.details-section > .content > .group > .row > .warning): Deleted.
Canonical link: https://commits.webkit.org/258667@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 24c2349535f6b092e49edc962a769f768f2e7eb6
https://github.com/WebKit/WebKit/commit/24c2349535f6b092e49edc962a769f768f2e7eb6
Author: Youenn Fablet <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/webrtc/sdk/objc/components/video_codec/RTCVideoEncoderH264.mm
Log Message:
-----------
Cherry-pick 9173fc4b4ede. rdar://problem/103922609
Remove RTCVideoEncoderH264 _pixelBufferPool
https://bugs.webkit.org/show_bug.cgi?id=250309
rdar://103922609
Reviewed by Jean-Yves Avenard.
_pixelBufferPool is not useful as a member field, let's remove it and
access it when needed instead.
This aligns with libwebrtc upstream.
Covered by webrtc H264 tests.
*
Source/ThirdParty/libwebrtc/Source/webrtc/sdk/objc/components/video_codec/RTCVideoEncoderH264.mm:
(-[RTCVideoEncoderH264 encode:codecSpecificInfo:frameTypes:]):
(-[RTCVideoEncoderH264 resetCompressionSessionIfNeededWithFrame:]):
(-[RTCVideoEncoderH264 resetCompressionSessionWithPixelFormat:]):
(-[RTCVideoEncoderH264 destroyCompressionSession]):
Canonical link: https://commits.webkit.org/258669@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 6147c2c5f1ad100abf5c79675ac803e8d64291a5
https://github.com/WebKit/WebKit/commit/6147c2c5f1ad100abf5c79675ac803e8d64291a5
Author: Brent Fulgham <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WTF/Scripts/GeneratePreferences.rb
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M
Source/WebKit/Scripts/PreferencesTemplates/WebPreferencesExperimentalFeatures.cpp.erb
Log Message:
-----------
Cherry-pick 1a660cb880b4. rdar://problem/103969233
Do not automatically enable 'developer' features during tests
https://bugs.webkit.org/show_bug.cgi?id=250235
<rdar://problem/103969233>
Reviewed by Elliott Williams.
The generator logic added in Bug 247926 also activated features with
'developer'
status while running tests.
This is wrong for a couple of reasons:
(1) The 'developer' flags with a defaultValue of 'false' are generally not
relevant to our
automated testing (e.g., enabling security-violating CORS state, enabling
features not meant
for web use cases, etc.
(2) TestWebKitAPI tests that need these special settings already enable the
individually, so
we should not hard-set them to 'true' at each test iteration, as this can
also enable features
on platforms or configurations that need these features to be off.
This patch limits the "automatically enabled" feature flags to those that
are marked as
'preview', 'testable', or 'stable'.
* Source/WTF/Scripts/GeneratePreferences.rb:
*
Source/WebKit/Scripts/PreferencesTemplates/WebPreferencesExperimentalFeatures.cpp.erb:
Canonical link: https://commits.webkit.org/258681@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 7e589f29395bc9e143b83198e60e2615e9eb9ba9
https://github.com/WebKit/WebKit/commit/7e589f29395bc9e143b83198e60e2615e9eb9ba9
Author: Richard Robinson <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/platform/KeyboardScrollingAnimator.cpp
Log Message:
-----------
Cherry-pick 410bb5f43c2e. rdar://problem/103969202
REGRESSION: Horizontal scroll-to-end is very slow (and maybe shouldn't
happen at all?)
https://bugs.webkit.org/show_bug.cgi?id=250251
rdar://103969202
Reviewed by Simon Fraser.
This bug was happening because when modifier keys are applied to a key
press,
AppKit sends a `keyDown` event to the UIProcess, but does not send a
corresponding
`keyUp` event. This causes scrolling to never stop.
This PR changes this behavior so that no scrolling will happen with
`Cmd+Left/Right arrow`,
`Shift+Left/Right arrow`, or `Cmd+Shift+Left/Right arrow`. This behavior is
better because these were never technically valid key combos in the first
place,
and simply pressing the left or right arrow accomplishes the desired
scrolling.
`Cmd+Left/Right arrow` also sometimes interferes with page back/forward
keyboard
shortcuts, so this will avoid that as well.
* Source/WebCore/platform/KeyboardScrollingAnimator.cpp:
(WebCore::scrollGranularityForKeyboardEvent):
Canonical link: https://commits.webkit.org/258686@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 4186f8e2d8d231d1de109bf084c5a6c6dc6a84bc
https://github.com/WebKit/WebKit/commit/4186f8e2d8d231d1de109bf084c5a6c6dc6a84bc
Author: Alex Christensen <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
Log Message:
-----------
Cherry-pick 547312c768f0. rdar://problem/103833306
Null check frame in CachedResourceLoader::updateRequestAfterRedirection
https://bugs.webkit.org/show_bug.cgi?id=250391
rdar://103833306
Reviewed by Chris Dumez.
Crash logs indicate the line that used the frame was crashing with null
dereferences.
Add some null checks to not crash during frame teardown.
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::CachedResourceLoader::updateRequestAfterRedirection):
Canonical link: https://commits.webkit.org/258728@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: cc1e0e6d18aab3d3e164a132b6c7a848281c914f
https://github.com/WebKit/WebKit/commit/cc1e0e6d18aab3d3e164a132b6c7a848281c914f
Author: Antti Koivisto <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A LayoutTests/fast/media/mq-nested-non-dynamic-expected.html
A LayoutTests/fast/media/mq-nested-non-dynamic.html
M Source/WebCore/style/RuleSetBuilder.cpp
Log Message:
-----------
Cherry-pick 3e90af4d3b34. rdar://problem/103732686
REGRESSION (257171@main): Static media query inside a dynamic media query
breaks dynamic evaluation
https://bugs.webkit.org/show_bug.cgi?id=250293
rdar://103732686
Reviewed by Simon Fraser.
Dynamic queries end up always matching.
* LayoutTests/fast/media/mq-nested-non-dynamic-expected.html: Added.
* LayoutTests/fast/media/mq-nested-non-dynamic.html: Added.
* Source/WebCore/style/RuleSetBuilder.cpp:
(WebCore::Style::RuleSetBuilder::MediaQueryCollector::pop):
Take care we don't pop a wrong stack frame. Static queries don't add to the
stack.
Canonical link: https://commits.webkit.org/258732@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 3ae5ebf7d8c5de02fb9b5219f520d0d42619b11e
https://github.com/WebKit/WebKit/commit/3ae5ebf7d8c5de02fb9b5219f520d0d42619b11e
Author: Chirag M Shah <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A LayoutTests/fast/css/css-text-border-menu-expected.txt
A LayoutTests/fast/css/css-text-border-menu.html
M Source/WebCore/css/StyleProperties.cpp
Log Message:
-----------
Cherry-pick db5cab0a4aaa. rdar://problem/103916548
Stop returning nullptr for system font keywords on non-font related
properties
https://bugs.webkit.org/show_bug.cgi?id=250245
rdar://103916548
Reviewed by Darin Adler and Tim Nguyen.
The code that is handling font: menu shouldn’t apply to non-font
properties.
* LayoutTests/fast/css/css-text-border-menu-expected.txt: Added.
* LayoutTests/fast/css/css-text-border-menu.html: Added.
* Source/WebCore/css/StyleProperties.cpp:
(WebCore::StyleProperties::getPropertyCSSValue const):
Canonical link: https://commits.webkit.org/258742@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 3de2dff25cde54f1d0db1c6a15cc14dc81d6ab25
https://github.com/WebKit/WebKit/commit/3de2dff25cde54f1d0db1c6a15cc14dc81d6ab25
Author: Simon Fraser <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp
M Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm
M Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.cpp
Log Message:
-----------
Cherry-pick 7d8a1c4dc4ab. rdar://problem/104050312
Tests that change page scale still trigger <CATransformLayer> changing
property contentsScale in transform-only layer, will have no effect" logging
https://bugs.webkit.org/show_bug.cgi?id=250344
rdar://104050312
Reviewed by Tim Horton.
There were still code paths that changed the `ContentsScaleChanged`
property on PlatformCALayers wrapping a CATransformLayer,
triggering "<CATransformLayer> changing property contentsScale in
transform-only layer".
So cut this off a bit lower down, by early returning from
`setContentsScale()` functions on PlatformCALayer subclasses.
* Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:
(WebCore::GraphicsLayerCA::initialize):
* Source/WebCore/platform/graphics/ca/cocoa/PlatformCALayerCocoa.mm:
(WebCore::PlatformCALayerCocoa::setContentsScale):
*
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/PlatformCALayerRemote.cpp:
(WebKit::PlatformCALayerRemote::setContentsScale):
Canonical link: https://commits.webkit.org/258745@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9472ddd5f151c3e9a46659805e7b53be8bd89ae7
https://github.com/WebKit/WebKit/commit/9472ddd5f151c3e9a46659805e7b53be8bd89ae7
Author: Sihui Liu <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.cpp
M Source/WebCore/Modules/filesystemaccess/FileSystemStorageConnection.h
M
Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.cpp
M
Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in
M Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.h
Log Message:
-----------
Cherry-pick 6a1487774c3c. rdar://problem/103979195
FileSystemSyncAccessHandle::close should return after releasing lock
https://bugs.webkit.org/show_bug.cgi?id=250194
rdar://103979195
Reviewed by Youenn Fablet.
Make FileSystemSyncAccessHandle::close() return after receiving the reply
for close message.
* Source/WebCore/Modules/filesystemaccess/FileSystemFileHandle.cpp:
(WebCore::FileSystemFileHandle::closeSyncAccessHandle):
* Source/WebCore/Modules/filesystemaccess/FileSystemStorageConnection.h:
*
Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.cpp:
(WebCore::WorkerFileSystemStorageConnection::closeSyncAccessHandle):
*
Source/WebCore/Modules/filesystemaccess/WorkerFileSystemStorageConnection.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::closeSyncAccessHandle):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in:
*
Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.cpp:
(WebKit::WebFileSystemStorageConnection::closeSyncAccessHandle):
* Source/WebKit/WebProcess/WebCoreSupport/WebFileSystemStorageConnection.h:
Canonical link: https://commits.webkit.org/258775@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 56575c640615633572b08d52b04307d523073e50
https://github.com/WebKit/WebKit/commit/56575c640615633572b08d52b04307d523073e50
Author: Andres Gonzalez <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M LayoutTests/accessibility/inline-block-assertion-expected.txt
M LayoutTests/accessibility/inline-block-assertion.html
M Source/WebCore/accessibility/AXObjectCache.cpp
Log Message:
-----------
Cherry-pick 4b90132f4d9d. rdar://problem/104090244
AX: crash in AXObjectCache::updateRelationsForTree.
https://bugs.webkit.org/show_bug.cgi?id=250406
<rdar://problem/104090244>
Reviewed by Chris Fleizach.
Fallout from change for https://bugs.webkit.org/show_bug.cgi?id=224582.
We now null check the Document* returned from
HTMLFrameOwnerElement::contentDocument().
The layout test accessibility/inline-block-assertion.html caught this crash
in ITM.
* LayoutTests/accessibility/inline-block-assertion-expected.txt:
* LayoutTests/accessibility/inline-block-assertion.html:
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::updateRelationsForTree):
Canonical link: https://commits.webkit.org/258783@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: b53c9365d7c5600d87a8cee6a30c189191619584
https://github.com/WebKit/WebKit/commit/b53c9365d7c5600d87a8cee6a30c189191619584
Author: Alan Baradlay <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp
Log Message:
-----------
Cherry-pick 6f437bc5e96e. rdar://problem/104106726
[IFC][ink overflow] Collect glyph overflow for text content when applicable
https://bugs.webkit.org/show_bug.cgi?id=250434
<rdar://problem/104106726>
Reviewed by Antti Koivisto.
Let's inflate ink overflow with the collected enclosing glyph bounds.
*
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayContentBuilder.cpp:
(WebCore::Layout::InlineDisplayContentBuilder::appendTextDisplayBox):
Canonical link: https://commits.webkit.org/258785@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: fa589211bc7db54056fe91da4fc55e35f3165827
https://github.com/WebKit/WebKit/commit/fa589211bc7db54056fe91da4fc55e35f3165827
Author: Richard Robinson <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp
Log Message:
-----------
Cherry-pick d1c80025c33e. rdar://problem/104099969
Null pointer web content crash in AsyncScrollingCoordinator callback
https://bugs.webkit.org/show_bug.cgi?id=250426
rdar://104099969
Reviewed by Simon Fraser.
Adds a null check for `m_page` in the hysteresis callback of
`AsyncScrollingCoordinator`.
* Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::hysterisisTimerFired):
Canonical link: https://commits.webkit.org/258792@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: edf95f53c6781956d6d9b0b45602a51ae2f32631
https://github.com/WebKit/WebKit/commit/edf95f53c6781956d6d9b0b45602a51ae2f32631
Author: Aditya Keerthi <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A
LayoutTests/fast/dom/HTMLElement/attr-dir-value-change-auto-parent-expected.txt
A LayoutTests/fast/dom/HTMLElement/attr-dir-value-change-auto-parent.html
M Source/WebCore/html/HTMLElement.cpp
Log Message:
-----------
Cherry-pick 222e3c7feef0. rdar://problem/102207392
REGRESSION (254017@main): Arabic default signature in Mail.app is not
right-to-left
https://bugs.webkit.org/show_bug.cgi?id=250443
rdar://102207392
Reviewed by Darin Adler and Ryosuke Niwa.
Mail.app controls the directionality of the signature by adding
`dir="auto"` to
the signature element, getting the element's computed style, and then
updating
the attribute to reflect the computed value. The `<body>` of the email has
`dir="auto"` specified.
Following 254017@main, adding the `dir` attribute to an element with a
`dir="auto"` parent, results in an unconditional call to unset the
`SelfOrPrecedingNodesAffectDirAuto` node flag. This flag is read in
`HTMLElement::directionalityIfDirIsAuto`, which returns `std::nullopt` if
the
flag is unset, rather than computing the directionality from the text.
Consequently, a fallback left-to-right value is used when resolving style.
To fix, only unset the `SelfOrPrecedingNodesAffectDirAuto` node flag if the
specified direction is valid, and not `auto`.
*
LayoutTests/fast/dom/HTMLElement/attr-dir-value-change-auto-parent-expected.txt:
Added.
* LayoutTests/fast/dom/HTMLElement/attr-dir-value-change-auto-parent.html:
Added.
* Source/WebCore/html/HTMLElement.cpp:
(WebCore::HTMLElement::dirAttributeChanged):
Canonical link: https://commits.webkit.org/258799@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 4c426363d83b92df64761af54f643c9456a23d98
https://github.com/WebKit/WebKit/commit/4c426363d83b92df64761af54f643c9456a23d98
Author: Alan Baradlay <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M
LayoutTests/fast/flexbox/missing-repaint-when-flext-item-never-had-layout-expected.txt
A LayoutTests/fast/repaint/full-repaint-on-content-change-expected.txt
A LayoutTests/fast/repaint/full-repaint-on-content-change.html
R
LayoutTests/platform/ios-wk2/fast/flexbox/missing-repaint-when-flext-item-never-had-layout-expected.txt
M
LayoutTests/platform/ios-wk2/fast/repaint/placeholder-after-caps-lock-hidden-expected.txt
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick 9ebe18b3a872. rdar://problem/103343165
Repaint issue on buy-iphone-14-pro page when hovering "trade in" content
https://bugs.webkit.org/show_bug.cgi?id=250461
<rdar://103343165>
Reviewed by Antti Koivisto.
This change matches legacy line layout behavior where "full layout"
triggers "full repaint".
It covers up certain repaint issues with content where visual overflow
geometry does not encloses all overflow (glyph in this case).
* LayoutTests/fast/repaint/full-repaint-on-content-change-expected.txt:
Added.
* LayoutTests/fast/repaint/full-repaint-on-content-change.html: Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::layoutModernLines):
Canonical link: https://commits.webkit.org/258819@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: d518daba99bec756b708148d9b8bb2600ea4a8b5
https://github.com/WebKit/WebKit/commit/d518daba99bec756b708148d9b8bb2600ea4a8b5
Author: Per Arne Vollan <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm
Log Message:
-----------
Cherry-pick e569cd626f62. rdar://problem/102979844
Fix timeout of HEIC test
https://bugs.webkit.org/show_bug.cgi?id=250463
rdar://102979844
Reviewed by Geoffrey Garen.
For the HEIC tests to work, a sandbox extension to the trust service needs
to be issued.
This patch also updates the test expectations for the HEIC tests.
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:
(WebKit::WebProcessPool::platformInitializeWebProcess):
Canonical link: https://commits.webkit.org/258885@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 0c9774aecbff4e72dac10c4704bc70bd39491d4f
https://github.com/WebKit/WebKit/commit/0c9774aecbff4e72dac10c4704bc70bd39491d4f
Author: Nikolaos Mouchtaris <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/platform/ScrollableArea.cpp
Log Message:
-----------
Cherry-pick f68ac346edce. rdar://problem/103763815
Re-add static assert for ScrollableArea size
https://bugs.webkit.org/show_bug.cgi?id=249805
<rdar://103763815>
Reviewed by Simon Fraser.
Re-add static assert.
* Source/WebCore/platform/ScrollableArea.cpp:
Canonical link: https://commits.webkit.org/258888@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: ed0b5985f3b9ea3d03f6887d0b4fdb7d41de219b
https://github.com/WebKit/WebKit/commit/ed0b5985f3b9ea3d03f6887d0b4fdb7d41de219b
Author: Alan Coon <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Configurations/Version.xcconfig
M Configurations/WebKitTargetConditionals.xcconfig
Log Message:
-----------
Cherry-pick dc1c1c69c6a8. rdar://problem/103407903
WebKit versions lack prefix
https://bugs.webkit.org/show_bug.cgi?id=250521
rdar://103407903
Reviewed by Alexey Proskuryakov.
* Configurations/Version.xcconfig:
Add configuration for 140000.
* Configurations/WebKitTargetConditionals.xcconfig:
Canonical link: https://commits.webkit.org/258900@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 0a6b45958d863ede20564d117c86631a5c83a839
https://github.com/WebKit/WebKit/commit/0a6b45958d863ede20564d117c86631a5c83a839
Author: Said Abou-Hallawa <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M
LayoutTests/platform/gtk/imported/w3c/web-platform-tests/svg/import/text-tspan-02-b-manual-expected.txt
M LayoutTests/platform/gtk/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.png
M LayoutTests/platform/gtk/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.txt
M
LayoutTests/platform/ios-simulator/imported/w3c/web-platform-tests/svg/import/text-tspan-02-b-manual-expected.txt
M LayoutTests/platform/ios/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.txt
M
LayoutTests/platform/mac/imported/w3c/web-platform-tests/svg/import/text-tspan-02-b-manual-expected.txt
M LayoutTests/platform/mac/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.png
M LayoutTests/platform/mac/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.txt
M Source/WebCore/css/svg.css
Log Message:
-----------
Cherry-pick d94164b2e7f5. rdar://problem/104246166
Unreviewed, revert 255917@main
https://bugs.webkit.org/show_bug.cgi?id=250603
rdar://104246166
It causes text to be squashed on on wsj.com interactive graphs.
*
LayoutTests/platform/gtk/imported/w3c/web-platform-tests/svg/import/text-tspan-02-b-manual-expected.txt:
* LayoutTests/platform/gtk/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.png:
* LayoutTests/platform/gtk/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.txt:
*
LayoutTests/platform/ios-simulator/imported/w3c/web-platform-tests/svg/import/text-tspan-02-b-manual-expected.txt:
* LayoutTests/platform/ios/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.txt:
*
LayoutTests/platform/mac/imported/w3c/web-platform-tests/svg/import/text-tspan-02-b-manual-expected.txt:
* LayoutTests/platform/mac/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.png:
* LayoutTests/platform/mac/svg/W3C-SVG-1.1-SE/text-tspan-02-b-expected.txt:
* Source/WebCore/css/svg.css:
(text, tspan, textPath):
(text): Deleted.
(tspan, textPath): Deleted.
Canonical link: https://commits.webkit.org/258905@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 0141f10ed683e4784259159b23941cb42cb3c564
https://github.com/WebKit/WebKit/commit/0141f10ed683e4784259159b23941cb42cb3c564
Author: Alan Baradlay <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A LayoutTests/fast/inline/line-spanning-inline-box-crash-expected.html
A LayoutTests/fast/inline/line-spanning-inline-box-crash.html
M
Source/WebCore/layout/formattingContexts/inline/InlineLineBoxVerticalAligner.cpp
M
Source/WebCore/layout/formattingContexts/inline/InlineLineBoxVerticalAligner.h
Log Message:
-----------
Cherry-pick 1cf5f56743f9. rdar://problem/104223956
[IFC] Infinite recursion in
Layout::LineBoxVerticalAligner::layoutBoundsForInlineBoxSubtree
https://bugs.webkit.org/show_bug.cgi?id=249942
<rdar://104223956>
Reviewed by Antti Koivisto.
layoutBoundsForInlineBoxSubtree recursively visits an inline box subtree
(<span id=parent><img><span id=child><img></span></span>) to
figure out enclosing ascent/descent.
This patch turns this recursive approach into iterative by using the inline
box list on the line box instead of
using the layout tree structure. Now we simply start iterating through the
inline level boxes on the line box
from the inline box in question until either the end of line or when we are
back to the same parent.
i.e instead of calling layoutBoundsForInlineBoxSubtree() with <span parent>
followed by <span child>
layoutBoundsForInlineBoxSubtree(<span parent>) call uses the inline level
box list:
[inline box <span parent>][inline level box <img>][inline box <span
child>][inline level box <img>]
The problem with using the layout tree structure is that we may find layout
boxes not present on the current line
e.g. <span><img><br><img></span>
Here (using the layout tree) we find the <img> (which is wrapped to the
next line due to <br>)
and calling LineBox::inlineLevelBoxForLayoutBox() with a layout box that's
not on the current line returns unexpected result.
* LayoutTests/fast/inline/line-spanning-inline-box-crash-expected.html:
Added.
* LayoutTests/fast/inline/line-spanning-inline-box-crash.html: Added.
*
Source/WebCore/layout/formattingContexts/inline/InlineLineBoxVerticalAligner.cpp:
(WebCore::Layout::LineBoxVerticalAligner::layoutBoundsForInlineBoxSubtree
const):
(WebCore::Layout::LineBoxVerticalAligner::alignInlineLevelBoxes const):
*
Source/WebCore/layout/formattingContexts/inline/InlineLineBoxVerticalAligner.h:
Canonical link: https://commits.webkit.org/258933@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 5d4dd016ac2cc17737c7ddafe8f58301342decd5
https://github.com/WebKit/WebKit/commit/5d4dd016ac2cc17737c7ddafe8f58301342decd5
Author: Said Abou-Hallawa <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M LayoutTests/TestExpectations
M LayoutTests/fast/images/avif-as-image-expected.html
M LayoutTests/fast/images/avif-heif-container-as-image-expected.html
M LayoutTests/fast/images/resources/green-313x313.avif
M LayoutTests/fast/images/resources/green-400x400.avif
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-ventura/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M LayoutTests/platform/mac/TestExpectations
Log Message:
-----------
Cherry-pick 9bffbcdd799e. rdar://problem/102823196
Sanitize the layout test AVIF images so they are decoded similarly using
libavif and CoreGraphics
https://bugs.webkit.org/show_bug.cgi?id=248544
rdar://102823196
Reviewed by Simon Fraser.
These files have identity matrices in the Sequence Header but have no colr
box.
So they are considered malformed images. To make rendering these images the
same
using CoreGraphics and libavif, they have be sanitized to be well formed.
The
TestExpectations can now be cleaned.
* LayoutTests/TestExpectations:
* LayoutTests/fast/images/avif-as-image-expected.html:
* LayoutTests/fast/images/avif-heif-container-as-image-expected.html:
* LayoutTests/fast/images/resources/green-313x313.avif:
* LayoutTests/fast/images/resources/green-400x400.avif:
* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-ventura/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* LayoutTests/platform/mac/TestExpectations:
Canonical link: https://commits.webkit.org/258934@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9516a9ad13ff97b51cc9ed40e5cfe15355ab96ab
https://github.com/WebKit/WebKit/commit/9516a9ad13ff97b51cc9ed40e5cfe15355ab96ab
Author: Brady Eidson <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreDelegate.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm
Log Message:
-----------
Cherry-pick f2855604234b. rdar://problem/103918987
Change notification permissions delegate method to expect NSURLs instead of
NSStrings
https://bugs.webkit.org/show_bug.cgi?id=250432
rdar://103918987
Reviewed by Tim Horton.
Makes it a bit harder for clients to do the wrong thing.
* Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:
* Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreDelegate.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm:
(-[FirePushEventDataStoreDelegate
notificationPermissionsForWebsiteDataStore:]):
Canonical link: https://commits.webkit.org/258960@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 135479a1f4e6978f6dc1225cb5388f75dbccf9d3
https://github.com/WebKit/WebKit/commit/135479a1f4e6978f6dc1225cb5388f75dbccf9d3
Author: Commit Queue <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
R LayoutTests/editing/deleting/merge-list-items-in-same-list-expected.txt
R LayoutTests/editing/deleting/merge-list-items-in-same-list.html
R LayoutTests/editing/deleting/merge-lists-expected.txt
R LayoutTests/editing/deleting/merge-lists.html
M Source/WebCore/editing/DeleteSelectionCommand.cpp
Log Message:
-----------
Cherry-pick cba3185df4c6. rdar://problem/104227951
Unreviewed, reverting r257650@main.
https://bugs.webkit.org/show_bug.cgi?id=250700
Caused new web platform test failures
Reverted changeset:
"Handle special case of merging lists in mergeParagraphs()"
https://bugs.webkit.org/show_bug.cgi?id=248709
https://commits.webkit.org/257650@main
Canonical link: https://commits.webkit.org/258972@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: bdf25ffe57b18a2c47e17139375fc2a655b23426
https://github.com/WebKit/WebKit/commit/bdf25ffe57b18a2c47e17139375fc2a655b23426
Author: Karl Rackler <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm
M Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreDelegate.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm
Log Message:
-----------
Cherry-pick af27b83945e6. rdar://problem/103918987
Revert [258960@main] Change notification permissions delegate method to
expect NSURLs instead of NSStrings
https://bugs.webkit.org/show_bug.cgi?id=250432
rdar://103918987
Unreviewed revert
This reverts because it broke the build on the bots.
* Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:
* Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreDelegate.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm:
(-[FirePushEventDataStoreDelegate
notificationPermissionsForWebsiteDataStore:]):
Canonical link: https://commits.webkit.org/258994@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9d83f5014ee50e530330a324b195f4347dc2af63
https://github.com/WebKit/WebKit/commit/9d83f5014ee50e530330a324b195f4347dc2af63
Author: Tim Nguyen <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A LayoutTests/fullscreen/fullscreen-enclosing-iframe-size-expected.html
A LayoutTests/fullscreen/fullscreen-enclosing-iframe-size.html
M Source/WebCore/dom/FullscreenManager.cpp
Log Message:
-----------
Cherry-pick afc8fb2561c8. rdar://problem/104238564
Fix style invalidation for ancestor documents of fullscreen element
https://bugs.webkit.org/show_bug.cgi?id=250750
rdar://104238564
Reviewed by Darin Adler.
We were just calling
`document().resolveStyle(Document::ResolveStyleType::Rebuild)` only on the
document the fullscreen request came from,
the ancestor documents were not covered. We need to call that method for
frames in reverse tree order, in order to have the correct sequence
of layouts:
1. Apply fullscreen styles to iframe contents
2. Append iframe contents to top layer
3. Apply fullscreen styles to iframe, make iframe contents dirty
4. Append iframe to top layer
As opposed to the incorrect sequence which leads to dirty renderers:
1. Apply fullscreen styles to iframe, make iframe contents dirty
2. Append iframe to top layer
3. Apply fullscreen styles to iframe contents
4. Append iframe contents to top layer (which is dirty because of step 1)
We preserve the tree order for queuing events as mandated by the spec.
* LayoutTests/fullscreen/fullscreen-enclosing-iframe-size-expected.html:
Added.
* LayoutTests/fullscreen/fullscreen-enclosing-iframe-size.html: Added.
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::willEnterFullscreen):
Canonical link: https://commits.webkit.org/259032@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: f1c87a119bc5984ae200d45d5432cf2c63bbe7cc
https://github.com/WebKit/WebKit/commit/f1c87a119bc5984ae200d45d5432cf2c63bbe7cc
Author: Wenson Hsieh <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A
LayoutTests/http/tests/permissions/permission-state-for-notifications-in-ephemeral-session-expected.txt
A
LayoutTests/http/tests/permissions/permission-state-for-notifications-in-ephemeral-session.html
M LayoutTests/http/tests/push-api/permissions-ephemeral-expected.txt
M LayoutTests/http/tests/push-api/permissions-ephemeral.html
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebNotificationClient.cpp
Log Message:
-----------
Cherry-pick 5e4c68005fe4. rdar://problem/103905006
REGRESSION (252706@main): zillow.com shows a Recaptcha interstitial in
private browsing mode
https://bugs.webkit.org/show_bug.cgi?id=250686
rdar://103905006
Reviewed by Youenn Fablet and Ben Nham.
Currently, in private browsing mode (i.e. when using an ephemeral session)
`Notification.permission`
unconditionally returns `"denied"` (with `Notification.requestPermission`
also unconditionally
denying the request). However, the Permissions API (i.e.
`navigator.permissions.query`) implements
inconsistent behavior, and instead returns `"prompt"` in this scenario. On
zillow.com, this causes
a bot detection script to erroneously flag the UA as non-human in private
browsing, and present
interstitial Recaptcha UI to the user.
Fix this by making the heuristics for "notifications" in
`WebPageProxy::queryPermission` consistent
with the Notifications API, such that in an ephemeral session, we return
"default" or "prompt"
unless the page has requested access (in which case we'll deny access, and
then subsequently return
"denied").
Test:
http/tests/permissions/permission-state-for-notifications-in-ephemeral-session.html
*
LayoutTests/http/tests/permissions/permission-state-for-notifications-in-ephemeral-session-expected.txt:
*
LayoutTests/http/tests/permissions/permission-state-for-notifications-in-ephemeral-session.html:
* LayoutTests/http/tests/push-api/permissions-ephemeral-expected.txt:
* LayoutTests/http/tests/push-api/permissions-ephemeral.html:
Rebaseline an existing layout test.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::queryPermission):
* Source/WebKit/WebProcess/WebCoreSupport/WebNotificationClient.cpp:
(WebKit::WebNotificationClient::checkPermission):
Canonical link: https://commits.webkit.org/259040@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 3a60d8046c4a1d91a562720f5224cefd9d1a4e98
https://github.com/WebKit/WebKit/commit/3a60d8046c4a1d91a562720f5224cefd9d1a4e98
Author: Matthieu Dubet <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/svg/painting/svg-currentcolor-dynamic-inherit-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/svg/painting/svg-currentcolor-dynamic-inherit.html
M Source/WebCore/rendering/style/RenderStyle.cpp
M Source/WebCore/rendering/style/SVGRenderStyle.cpp
M Source/WebCore/rendering/style/SVGRenderStyle.h
Log Message:
-----------
Cherry-pick f5b520fdec0e. rdar://problem/102904403
SVGRenderStyle should repaint on resolved color change
https://bugs.webkit.org/show_bug.cgi?id=250718
rdar://102904403
Reviewed by Antti Koivisto.
Before this patch, the diff algorithm would naively
compare the color properties value without taking into
account the dynamic nature of "currentcolor".
*
LayoutTests/imported/w3c/web-platform-tests/svg/painting/svg-currentcolor-dynamic-inherit-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/svg/painting/svg-currentcolor-dynamic-inherit.html:
Added.
* Source/WebCore/rendering/style/RenderStyle.cpp:
(WebCore::RenderStyle::changeRequiresLayout const):
(WebCore::RenderStyle::changeRequiresRepaint const):
(WebCore::RenderStyle::diff const):
* Source/WebCore/rendering/style/SVGRenderStyle.cpp:
(WebCore::colorChangeRequiresRepaint):
(WebCore::SVGRenderStyle::changeRequiresLayout const):
(WebCore::SVGRenderStyle::changeRequiresRepaint const):
(WebCore::SVGRenderStyle::diff const): Deleted.
* Source/WebCore/rendering/style/SVGRenderStyle.h:
Canonical link: https://commits.webkit.org/259082@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2219d7e0d88fb8e3b77732fdff3d86c20b0ea466
https://github.com/WebKit/WebKit/commit/2219d7e0d88fb8e3b77732fdff3d86c20b0ea466
Author: Sihui Liu <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
Log Message:
-----------
Cherry-pick 7dc5b3c7ae63. rdar://problem/104398225
Suspend and resume closing NetworkStorageManager when network process gets
suspended/resumed
https://bugs.webkit.org/show_bug.cgi?id=250790
rdar://problem/104398225
Reviewed by Chris Dumez and Youenn Fablet.
NetworkStorageManager's ownership may be moved from NetworkSession to
NetworkProcess between PrepareToSuspend and
ProcessDidResume messages in network process, when it is being closed, so
we need to make sure closing
NetworkStorageManagers are also resumed. Otherwise, cleanup task will not
be handled.
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::prepareToSuspend):
(WebKit::NetworkProcess::processDidResume):
Canonical link: https://commits.webkit.org/259093@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 042c8add4685e97faf621794b7b922831389b268
https://github.com/WebKit/WebKit/commit/042c8add4685e97faf621794b7b922831389b268
Author: J Pascoe <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M
LayoutTests/http/wpt/webauthn/public-key-credential-get-success-local.https-expected.txt
Log Message:
-----------
Cherry-pick 6eeffda74648. rdar://problem/104386284
http/wpt/webauthn/public-key-credential-get-success-local.https.html is a
consistent failure
https://bugs.webkit.org/show_bug.cgi?id=250772
rdar://problem/104386284
Unreviewed, rebaseline.
*
LayoutTests/http/wpt/webauthn/public-key-credential-get-success-local.https-expected.txt:
Rebaseline this test.
Canonical link: https://commits.webkit.org/259107@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 64c608c49e3b546b7770261dd2fc3ab1602dc1ce
https://github.com/WebKit/WebKit/commit/64c608c49e3b546b7770261dd2fc3ab1602dc1ce
Author: Sihui Liu <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp
Log Message:
-----------
Cherry-pick cee0c766f33c. rdar://problem/103883105
Move file attribute setting in
WebsiteDataStore::resolveDirectoriesIfNecessary off main thread
https://bugs.webkit.org/show_bug.cgi?id=250821
rdar://103883105
Reviewed by Youenn Fablet.
Setting excluded attribute might require disk access, so moving it to
background thread.
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::resolveDirectoriesIfNecessary):
Canonical link: https://commits.webkit.org/259121@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2f0d7c51c46d8677defce715e5db3f1a815d370c
https://github.com/WebKit/WebKit/commit/2f0d7c51c46d8677defce715e5db3f1a815d370c
Author: Sihui Liu <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp
Log Message:
-----------
Cherry-pick 61cec390e9de. rdar://problem/104295786
Ensure CacheStorageDiskStore is destroyed on the callback queue
https://bugs.webkit.org/show_bug.cgi?id=250869
rdar://104295786
Reviewed by Chris Dumez.
CacheStorageDiskStore is not ThreadSafeRefCounted (we don't expect it to be
ref-ed or deref-ed from different threads),
so we need to pass the last ref of CacheStorageDiskStore to the queue that
creates it.
* Source/WebKit/NetworkProcess/storage/CacheStorageDiskStore.cpp:
(WebKit::CacheStorageDiskStore::readAllRecords):
(WebKit::CacheStorageDiskStore::readRecords):
Canonical link: https://commits.webkit.org/259127@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 1a3ebdd6697501661ddd52b592fb629ff8273e77
https://github.com/WebKit/WebKit/commit/1a3ebdd6697501661ddd52b592fb629ff8273e77
Author: Kimmo Kinnunen <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/WebProcess/GPU/media/RemoteAudioDestinationProxy.cpp
Log Message:
-----------
Cherry-pick 3c729e10ad7a. rdar://problem/104470320
AudioContext::suspend creates a remote audio destination
https://bugs.webkit.org/show_bug.cgi?id=250890
rdar://problem/104470320
Reviewed by Youenn Fablet.
Stopping RemoteAudioDestinationProxy that was not started would
establish a connection to GPUP RemoteAudioDestination. This is a slow
operation.
This would happen sometimes during load, where load commit would suspend
the AudioContext that the page created but did not start. AudioContext
starts in Suspended state, but suspending it would cause stop call
to the underlying destination.
To minimize the change at this time, fix the problem at
RemoteAudioDestinationProxy level. Later on, AudioContext can be
improved further.
* Source/WebKit/WebProcess/GPU/media/RemoteAudioDestinationProxy.cpp:
(WebKit::RemoteAudioDestinationProxy::startRendering):
(WebKit::RemoteAudioDestinationProxy::stopRendering):
Canonical link: https://commits.webkit.org/259134@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 23c3577e1b309f3c3746d0bc1b3276a381bc8cac
https://github.com/WebKit/WebKit/commit/23c3577e1b309f3c3746d0bc1b3276a381bc8cac
Author: Richard Robinson <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebCore/editing/EditorCommand.cpp
M Source/WebCore/page/EventHandler.cpp
M Source/WebCore/page/EventHandler.h
M Source/WebCore/platform/KeyboardScrollingAnimator.cpp
M Source/WebCore/platform/KeyboardScrollingAnimator.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Cherry-pick 8984da740010. rdar://problem/104152802
Page scrolls more than one screenful when pressing Space or Fn+Down
https://bugs.webkit.org/show_bug.cgi?id=250598
rdar://104152802
Reviewed by Simon Fraser.
Before event handler driven smooth keyboard scrolling, pressing and holding
the
spacebar or page up/down keys would do the following sequence of actions:
1. Scroll down the page by a "screenful".
2. On Cocoa platforms, the scrolling mechanism would wait until the
`keyRepeatInterval`
has passed.
3. After the interval has passed, it would continue consistently page
scrolling until
the key is released.
With the introduction of event handler driven smooth keyboard scrolling,
step two
was omitted. However, because smooth scrolling was slower than previously,
the behavior
was effectively unchanged, as the slowness of the scrolling compensated for
what would
have been the key repeat interval.
After https://github.com/WebKit/WebKit/pull/8318, smooth scrolling was
adjusted which
caused its velocity to increase. As a result, the lack of a delay was now
noticable,
and page scrolling would scroll more than a "screenful" unless preisely one
key event was sent.
This PR adjusts smooth scrolling such that the smooth keyboard scroll
animation only
starts after the `keyRepeatInterval`, with the first part of the entire
scroll behaving the
same as it did prior to smooth keyboard scrolling.
Note that this will apply to only spacebar and page up / down scrolling,
and not arrow key
scrolling.
* Source/WebCore/editing/EditorCommand.cpp:
(WebCore::executeScrollPageBackward):
(WebCore::executeScrollPageForward):
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::defaultKeyboardEventHandler):
(WebCore::EventHandler::defaultKeyboardScrollEventHandler):
(WebCore::EventHandler::defaultPageUpDownEventHandler):
(WebCore::EventHandler::defaultSpaceEventHandler):
(WebCore::EventHandler::beginKeyboardScrollGesture):
(WebCore::EventHandler::startKeyboardScrollAnimationOnDocument):
(WebCore::EventHandler::startKeyboardScrollAnimationOnRenderBoxLayer):
(WebCore::EventHandler::startKeyboardScrollAnimationOnRenderBoxAndItsAncestors):
(WebCore::EventHandler::startKeyboardScrollAnimationOnEnclosingScrollableContainer):
(WebCore::EventHandler::keyboardScrollRecursively):
(WebCore::EventHandler::keyboardScroll):
* Source/WebCore/page/EventHandler.h:
* Source/WebCore/platform/KeyboardScrollingAnimator.cpp:
(WebCore::KeyboardScrollingAnimator::beginKeyboardScrollGesture):
* Source/WebCore/platform/KeyboardScrollingAnimator.h:
Canonical link: https://commits.webkit.org/259146@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 7fdeb4e137c81459142e151e95b4820cb29e21aa
https://github.com/WebKit/WebKit/commit/7fdeb4e137c81459142e151e95b4820cb29e21aa
Author: Simon Fraser <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A
LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt
A
LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt
A
LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed.html
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 2f33fa54c405. rdar://problem/104095908
A fixed header inside overflow scroll with a transformed ancestor stutters
on scrolling (affects Libby app)
https://bugs.webkit.org/show_bug.cgi?id=250652
rdar://104095908
Reviewed by Alan Baradlay.
The Libby app has content which uses a stacking-context overflow:scroll
with a position:fixed
descendant, and a CSS transform on an ancestor of the scroller. In this
situation, we treat the
position:fixed as if it has position:absolute, but still need to use the
correct containing block
for it (which is the enclosing transformed box).
Two fixes are required here. First,
`RenderLayerCompositor::computeCoordinatedPositioningForLayer()`
needs to check if the position:fixed layer actually has fixed behavior
(i.e. no transformed
ancestor) before the early return.
Second, the `traverseAncestorLayers()` helper only handled
position:absolute containing block logic;
we need to fix it to also compute the correct containing block for
position:fixed (which allows it
to find transformed ancestors of fixed).
Fixing `traverseAncestorLayers()` to have the correct containingBlock
behavior for fixed layers
revealed a surprising behavior, which is that the deprecated CSS `clip`
property on a
position:absolute element clips position:fixed descendants, which is odd
because it's different from
how overflow works (https://github.com/w3c/csswg-drafts/issues/8336). So
RenderLayerCompositor::computeAncestorClippingStack() needs some special
case code to detect this
case. This is tested by
imported/blink/fast/css/fixed-overlaps-absolute-in-clip.html.
*
LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt:
Added.
*
LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt:
Added.
*
LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed.html:
Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::traverseAncestorLayers):
(WebCore::RenderLayerCompositor::computeAncestorClippingStack const):
(WebCore::RenderLayerCompositor::computeCoordinatedPositioningForLayer
const):
Canonical link: https://commits.webkit.org/259175@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: b554b2ccfe0e7ff9caeb4931ce0ae31f2f124e60
https://github.com/WebKit/WebKit/commit/b554b2ccfe0e7ff9caeb4931ce0ae31f2f124e60
Author: Mark Lam <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
A JSTests/stress/parser-property-node-identifier-should-not-be-null.js
M Source/JavaScriptCore/builtins/BuiltinNames.h
M Source/JavaScriptCore/parser/NodeConstructors.h
M Source/JavaScriptCore/parser/Parser.cpp
Log Message:
-----------
Cherry-pick 90bd38013bce. rdar://problem/104507750
Parser's PropertyNode should never be given an Identifier with a null impl.
https://bugs.webkit.org/show_bug.cgi?id=250931
<rdar://problem/104507750>
Reviewed by Yusuke Suzuki.
For static initializer blocks, instead of passing a null Identifier, we'll
use an Identifier
made from the newly introduced staticInitializerBlockPrivateName().
* JSTests/stress/parser-property-node-identifier-should-not-be-null.js:
Added.
(Class.get c):
(Class):
* Source/JavaScriptCore/builtins/BuiltinNames.h:
* Source/JavaScriptCore/parser/NodeConstructors.h:
(JSC::PropertyNode::PropertyNode):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
Canonical link: https://commits.webkit.org/259187@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 59403a0b66c3cac53908b88cc07f8bed189da760
https://github.com/WebKit/WebKit/commit/59403a0b66c3cac53908b88cc07f8bed189da760
Author: Miguel Salinas <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M Source/WebKit/UIProcess/ProcessThrottler.cpp
Log Message:
-----------
Cherry-pick 2663e6d98e20. rdar://problem/104382617
[iOS] Fix release assertion in WebKit::ProcessThrottler::didConnectToProcess
https://bugs.webkit.org/show_bug.cgi?id=250789
Reviewed by Chris Dumez.
This assertion needs to be updated after adding the option to drop the
'Suspended' assertion.
* Source/WebKit/UIProcess/ProcessThrottler.cpp:
(WebKit::ProcessThrottler::didConnectToProcess):
Canonical link: https://commits.webkit.org/259137@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: aee29a42dd4e79087256cedca83cdb3f2b0f8b9f
https://github.com/WebKit/WebKit/commit/aee29a42dd4e79087256cedca83cdb3f2b0f8b9f
Author: Alan Baradlay <[email protected]>
Date: 2023-01-23 (Mon, 23 Jan 2023)
Changed paths:
M LayoutTests/TestExpectations
A
LayoutTests/fast/text/layout-overflow-for-line-clamped-content-expected.html
A LayoutTests/fast/text/layout-overflow-for-line-clamped-content.html
M
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/alignment/flex-align-baseline-line-clamp-001.tentative-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/css/css-grid/alignment/grid-align-baseline-line-clamp-001.tentative-expected.txt
M LayoutTests/platform/ios/fast/overflow/line-clamp-expected.txt
M LayoutTests/platform/mac/fast/overflow/line-clamp-expected.txt
M
Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h
Log Message:
-----------
Cherry-pick f34b777b4bff. rdar://problem/103942782
REGRESSION (256989@main): YouTube "read more" links are missing, long
comments cut off
https://bugs.webkit.org/show_bug.cgi?id=250270
<rdar://103942782>
Reviewed by Antti Koivisto.
This patch addresses 2 issues with IFC's -webkit-line-clamp implementation:
1. -webkit-line-clamp expects the clamped content to be laid out when
overflow is hidden (even completely collapsed blocks too). They produce layout
overflow.
(The fix is to not early-return in InlineFormattingContext::lineLayout when
we reach the clamped line)
2. The height of the inline content is measured from the top of the first
line to the bottom of the clamped line (0 when the content is fully collapsed).
(The fix is to take clamping into account in
LineLayout::contentLogicalHeight)
-reset some of the IFC progressions in LayoutTest.
*
LayoutTests/fast/text/layout-overflow-for-line-clamped-content-expected.html:
Added.
* LayoutTests/fast/text/layout-overflow-for-line-clamped-content.html:
Added.
*
Source/WebCore/layout/formattingContexts/inline/InlineFormattingContext.cpp:
(WebCore::Layout::lineEndingEllipsisPolicy):
(WebCore::Layout::InlineFormattingContext::lineLayout):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::lastLineIndexForContentHeight
const):
(WebCore::LayoutIntegration::LineLayout::contentLogicalHeight const):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.h:
Canonical link: https://commits.webkit.org/258730@main
Canonical link: https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/91f2473a5118...aee29a42dd4e
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
