[webkit-changes] [WebKit/WebKit] dfdd52: Cherry-pick 284560 at main (01c06ea002c2). https://bu...
Olivier Blin
noreply at github.com
Fri Oct 4 05:27:07 PDT 2024
Branch: refs/heads/webkitglib/2.46
Home: https://github.com/WebKit/WebKit
Commit: dfdd524cf70f6697658cace461a6640e3e546a6d
https://github.com/WebKit/WebKit/commit/dfdd524cf70f6697658cace461a6640e3e546a6d
Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
Date: 2024-10-03 (Thu, 03 Oct 2024)
Changed paths:
M Source/WebCore/bindings/js/JSDOMPromiseDeferred.h
Log Message:
-----------
Cherry-pick 284560 at main (01c06ea002c2). https://bugs.webkit.org/show_bug.cgi?id=280744
JSDOMPromiseDeferred.h:307:20: "error: use 'template' keyword to treat 'resolve' as a dependent template name" with some Clang versions
https://bugs.webkit.org/show_bug.cgi?id=280744
rdar://136932730
Reviewed by Darin Adler.
In some Clang versions, we get the following error diagnostic:
```
JSDOMPromiseDeferred.h:307:20: error: use 'template' keyword to treat 'resolve' as a dependent template name
307 | m_promise->resolve<IDLType>(std::forward<typename IDLType::ParameterType>(value));
| ^
| template
```
This is a valid error because `m_promise` is indeed a member template
specialization and the `resolve()` call explicitly depends on a template
parameter.
We fix this by prepending the `resolve()` call with keyword `template`.
c.f. ISO C++23 13.3.3.4.
* Source/WebCore/bindings/js/JSDOMPromiseDeferred.h:
(WebCore::DOMPromiseDeferred::resolve):
Canonical link: https://commits.webkit.org/284560@main
Canonical link: https://commits.webkit.org/282416.181@webkitglib/2.46
Commit: bc6f7ef66ba3c3a48183babfe143dc3dc05d7260
https://github.com/WebKit/WebKit/commit/bc6f7ef66ba3c3a48183babfe143dc3dc05d7260
Author: Antti Koivisto <antti at apple.com>
Date: 2024-10-03 (Thu, 03 Oct 2024)
Changed paths:
A LayoutTests/fast/css/attribute-selector-for-style-inline-invalidation-expected.html
A LayoutTests/fast/css/attribute-selector-for-style-inline-invalidation.html
M Source/WebCore/dom/StyledElement.cpp
M Source/WebCore/style/StyleScopeRuleSets.cpp
M Source/WebCore/style/StyleScopeRuleSets.h
Log Message:
-----------
Cherry-pick 284588 at main (e4b32fa1e5ad). https://bugs.webkit.org/show_bug.cgi?id=280787
rememberthemilk.com: REGRESSION (280692 at main): Clicking on the dropdown list doesn't expand to display its content
https://bugs.webkit.org/show_bug.cgi?id=280787
rdar://136259655
Reviewed by Alan Baradlay.
The page uses attribute selectors that query the value of the style attribute
[style*="display: none;"].b-FS-n { display: block; … }
With the optimization implemented in 280692 at main we fail to invalidate correctly when the
inline style is programmatically mutated, affecting the value of the style attribute.
* LayoutTests/fast/css/attribute-selector-for-style-inline-invalidation-expected.html: Added.
* LayoutTests/fast/css/attribute-selector-for-style-inline-invalidation.html: Added.
* Source/WebCore/dom/StyledElement.cpp:
(WebCore::StyledElement::dirtyStyleAttribute):
(WebCore::StyledElement::invalidateStyleAttribute):
Uses normal element invalidation instead of optimized inline style one if we have any selectors targeting style attribute.
* Source/WebCore/style/StyleScopeRuleSets.cpp:
(WebCore::Style::ScopeRuleSets::collectFeatures const):
(WebCore::Style::ScopeRuleSets::selectorsForStyleAttribute const):
Unify the collection of style attribute selector data.
(WebCore::Style::ScopeRuleSets::hasSelectorsForStyleAttribute const): Deleted.
(WebCore::Style::ScopeRuleSets::hasComplexSelectorsForStyleAttribute const): Deleted.
* Source/WebCore/style/StyleScopeRuleSets.h:
Canonical link: https://commits.webkit.org/284588@main
Canonical link: https://commits.webkit.org/282416.182@webkitglib/2.46
Commit: be05151abff105cd79200b4f163da535d683ffdb
https://github.com/WebKit/WebKit/commit/be05151abff105cd79200b4f163da535d683ffdb
Author: Vitaly Dyachkov <vitaly at igalia.com>
Date: 2024-10-03 (Thu, 03 Oct 2024)
Changed paths:
M Source/WebKit/Shared/libwpe/WebEventFactory.cpp
Log Message:
-----------
Cherry-pick 284552 at main (a5522d147cd6). https://bugs.webkit.org/show_bug.cgi?id=279967
[WPE] Assertion failure !isHashTraitsEmptyValue<KeyTraits>(key) in WPE/Debug/WTF/Headers/wtf/HashTable.h
https://bugs.webkit.org/show_bug.cgi?id=279967
Reviewed by Carlos Garcia Campos.
Default `HashTraits` disallow 0 treating it as an empty key.
* Source/WebKit/Shared/libwpe/WebEventFactory.cpp:
(WebKit::WebEventFactory::createWebTouchEvent):
Canonical link: https://commits.webkit.org/284552@main
Canonical link: https://commits.webkit.org/282416.183@webkitglib/2.46
Commit: 112bdba004cf9414fce4b04422fcc07861628b8b
https://github.com/WebKit/WebKit/commit/112bdba004cf9414fce4b04422fcc07861628b8b
Author: Matt Woodrow <mattwoodrow at apple.com>
Date: 2024-10-03 (Thu, 03 Oct 2024)
Changed paths:
A LayoutTests/compositing/shared-backing/overlap-bounds-change-crash-expected.txt
A LayoutTests/compositing/shared-backing/overlap-bounds-change-crash.html
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
Log Message:
-----------
Cherry-pick 283182 at main (ff9c149d15da). https://bugs.webkit.org/show_bug.cgi?id=279143
ASSERT in WebCore::RenderLayerCompositor::traverseUnchangedSubtree - provider == backingSharingState.backingProviderCandidateForLayer(layer, *this, overlapMap, layerExtent).
https://bugs.webkit.org/show_bug.cgi?id=279143
<rdar://135189928>
Reviewed by Simon Fraser.
This case has a backing sharing provider, and a shared layer with a sibling in
the middle.
The sibling has a reference filter (overlapBoundsIncludeChildren() == true) and
is initially not composited. This results in the computed overlap bounds being
that of it's clipped ancestor, which may not intersect the backing sharing
provider.
If the sibling becomes composited during this compositing update, the on the
next update it will use a different clip (from itself only) and now overlap the
backing sharing provider. Nothing marks the shared layer as needing an update,
so it detects that it can't share due to overlap during the
traverseUnchangedSubtree path and asserts.
Fix this by adding a flag to the clip rect calculation that makes it not
depending on prior compositing decisions.
* LayoutTests/compositing/shared-backing/overlap-bounds-change-crash-expected.txt: Added.
* LayoutTests/compositing/shared-backing/overlap-bounds-change-crash.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::calculateClipRects const):
* Source/WebCore/rendering/RenderLayer.h:
Canonical link: https://commits.webkit.org/283182@main
Canonical link: https://commits.webkit.org/282416.184@webkitglib/2.46
Commit: cda7d4f67eaee35731342bd46eaa2379a82c7c65
https://github.com/WebKit/WebKit/commit/cda7d4f67eaee35731342bd46eaa2379a82c7c65
Author: Devin Rousso <hi at devinrousso.com>
Date: 2024-10-04 (Fri, 04 Oct 2024)
Changed paths:
A LayoutTests/inspector/dom-debugger/command-line-api-event-expected.txt
A LayoutTests/inspector/dom-debugger/command-line-api-event.html
M Source/WebCore/inspector/agents/InspectorDOMDebuggerAgent.cpp
Log Message:
-----------
Cherry-pick 283181 at main (bec6d22a9343). https://bugs.webkit.org/show_bug.cgi?id=278919
Web Inspector: $event ReferenceError in Safari extension event listeners
https://bugs.webkit.org/show_bug.cgi?id=278919
Reviewed by BJ Burg.
Grabbing the `GlobalObject` from the `ScriptExecutionContext` is not always going to be correct if the `EventListener` was created in a `DOMWrapperWorld`.
* Source/WebCore/inspector/agents/InspectorDOMDebuggerAgent.cpp:
(WebCore::globalObject): Added.
(WebCore::InspectorDOMDebuggerAgent::willHandleEvent):
(WebCore::InspectorDOMDebuggerAgent::didHandleEvent):
* LayoutTests/inspector/dom-debugger/command-line-api-event.html: Added.
* LayoutTests/inspector/dom-debugger/command-line-api-event-expected.txt: Added.
Canonical link: https://commits.webkit.org/283181@main
Canonical link: https://commits.webkit.org/282416.185@webkitglib/2.46
Commit: 12e6ecea377621e00752ea6049b09178f257db75
https://github.com/WebKit/WebKit/commit/12e6ecea377621e00752ea6049b09178f257db75
Author: Said Abou-Hallawa <said at apple.com>
Date: 2024-10-04 (Fri, 04 Oct 2024)
Changed paths:
A LayoutTests/fast/images/image-size-unsigned-overflow-expected.txt
A LayoutTests/fast/images/image-size-unsigned-overflow.html
A LayoutTests/fast/images/resources/512752x256376.jpg
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/win/TestExpectations
M Source/WebCore/platform/graphics/BitmapImageDescriptor.cpp
M Source/WebCore/platform/graphics/BitmapImageSource.cpp
Log Message:
-----------
Cherry-pick 283179 at main (0ed1220736b8). https://bugs.webkit.org/show_bug.cgi?id=279108
Fix possible integer overflow when calculating the image frame size in bytes
https://bugs.webkit.org/show_bug.cgi?id=279108
rdar://134343651
Reviewed by Simon Fraser.
Instead of calling IntSize::area(), call IntSize::unclampedArea() to avoid integer
overflow when calculating the size of an imagre frame. The overflow will happen
if the size of the image is larager than 4G pixels.
* LayoutTests/fast/images/image-size-unsigned-overflow-expected.txt: Added.
* LayoutTests/fast/images/image-size-unsigned-overflow.html: Added.
* LayoutTests/fast/images/resources/512752x256376.jpg: Added.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/win/TestExpectations:
JPEGXLImageDecoder::tryDecodeSize() crashes when decoding the new added image.
* Source/WebCore/platform/graphics/BitmapImageDescriptor.cpp:
(WebCore::BitmapImageDescriptor::maximumSubsamplingLevel const):
* Source/WebCore/platform/graphics/BitmapImageSource.cpp:
(WebCore::BitmapImageSource::isLargeForDecoding const):
(WebCore::BitmapImageSource::cacheNativeImageAtIndex):
Canonical link: https://commits.webkit.org/283179@main
Canonical link: https://commits.webkit.org/282416.186@webkitglib/2.46
Commit: c03b9af5c161726886725ff30570ce982d185e1e
https://github.com/WebKit/WebKit/commit/c03b9af5c161726886725ff30570ce982d185e1e
Author: Olivier Blin <olivier.blin at softathome.com>
Date: 2024-10-04 (Fri, 04 Oct 2024)
Changed paths:
M Source/WTF/wtf/cocoa/FileSystemCocoa.mm
M Source/WTF/wtf/posix/FileSystemPOSIX.cpp
Log Message:
-----------
Cherry-pick 284612 at main (12930853a9a4). https://bugs.webkit.org/show_bug.cgi?id=277734
[WTF] Open files with O_CLOEXEC by default to avoid file handles leak
https://bugs.webkit.org/show_bug.cgi?id=277734
Reviewed by Michael Catanzaro.
FileSystemPOSIX opens files without the O_CLOEXEC file in openFile()
and openTemporaryFile().
This can cause file handles to be leaked to subprocess.
For example, if the UIProcess opens content rules files from the
ContentRuleListStore class before the NetworkProcess is spawned, the
content rules file handles are leaked to the NetworkProcess.
It does not seem useful to open files without O_CLOEXEC.
Also fix FileSystemCocoa for createTemporaryZipArchive().
* Source/WTF/wtf/posix/FileSystemPOSIX.cpp:
(WTF::FileSystemImpl::openFile):
(WTF::FileSystemImpl::openTemporaryFile):
* Source/WTF/wtf/cocoa/FileSystemCocoa.mm:
(WTF::FileSystemImpl::createTemporaryZipArchive):
(WTF::FileSystemImpl::openTemporaryFile):
Canonical link: https://commits.webkit.org/284612@main
Canonical link: https://commits.webkit.org/282416.187@webkitglib/2.46
Compare: https://github.com/WebKit/WebKit/compare/eacf9977760d...c03b9af5c161
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list