Branch: refs/heads/safari-7616.1.27.13-branch
Home: https://github.com/WebKit/WebKit
Commit: 19413cffce1b18e788ca45bd6be249378ee677e4
https://github.com/WebKit/WebKit/commit/19413cffce1b18e788ca45bd6be249378ee677e4
Author: Myah Cobbs <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
Identifier: [email protected]
Commit: b12841fcb133e051c9f4a2a61a6459f4f6f70c59
https://github.com/WebKit/WebKit/commit/b12841fcb133e051c9f4a2a61a6459f4f6f70c59
Author: Yusuke Suzuki <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/jit/AssemblyHelpers.cpp
M Source/JavaScriptCore/jit/AssemblyHelpers.h
M Source/JavaScriptCore/jit/JITOpcodes.cpp
Log Message:
-----------
Cherry-pick 00e61ef559b5. rdar://problem/113143403
[JSC] Squeeze object allocation JIT code
https://bugs.webkit.org/show_bug.cgi?id=259151
rdar://112145626
Reviewed by Mark Lam.
1. Use stp to update FreeList's data.
2. Avoid unnecessary instructions (null clear) for most of cases by passing
SlowAllocationResult enum.
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
(JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
(JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileNewBoundFunction):
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
(JSC::AssemblyHelpers::emitAllocate):
(JSC::AssemblyHelpers::emitAllocateVariableSized):
* Source/JavaScriptCore/jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateJSCell):
(JSC::AssemblyHelpers::emitAllocateJSObject):
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
(JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
* Source/JavaScriptCore/jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emit_op_create_this):
Canonical link: https://commits.webkit.org/266010@main
Identifier: [email protected]
Commit: 8af6c38ecf3a7c044a7fec099104f12226051e2f
https://github.com/WebKit/WebKit/commit/8af6c38ecf3a7c044a7fec099104f12226051e2f
Author: Yusuke Suzuki <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
A JSTests/stress/rope-resolve-recursive-non-ascii.js
A JSTests/stress/rope-resolve-recursive.js
A JSTests/stress/three-rope-non-ascii.js
A JSTests/stress/three-rope.js
A JSTests/stress/two-rope-non-ascii.js
A JSTests/stress/two-rope.js
M Source/JavaScriptCore/runtime/JSString.cpp
M Source/JavaScriptCore/runtime/JSString.h
M Source/JavaScriptCore/runtime/JSStringInlines.h
Log Message:
-----------
Cherry-pick 9c5c2c9fc89f. rdar://problem/113143401
[JSC] JSRopeString::resolveToBuffer should have fast path for two
rope+non-rope case
https://bugs.webkit.org/show_bug.cgi?id=259176
rdar://112178098
Reviewed by Michael Saboff.
JSRopeString can have three fibers. But we observed two fibers case, where
only one is a rope, very commonly.
This happens when you write code like this,
var string = '';
for (var i = 0; i < 1e6; ++i)
string += char
Then, the resulted string becomes two fibers rope, only left hand side gets
super deep.
We can handle this string, just recursively handle the left side (via
tail-call), but just spreading the right side.
This patch changes JSRopeString::resolveToBuffer to handle this kind of
patterns efficiently. We carefully crafted this
code so that the above pattern becomes repeated tail call to
JSRopeString::resolveToBuffer. We also have sp checker so that
this code works perfectly well even if the compiler is not supporting
tail-calls (at some level, we stop and use slow-but-works mode).
* Source/JavaScriptCore/runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeInternalNoSubstring const):
(JSC::JSRopeString::resolveRopeToAtomString const):
(JSC::JSRopeString::resolveRopeToExistingAtomString const):
(JSC::JSRopeString::resolveRopeWithFunction const):
* Source/JavaScriptCore/runtime/JSString.h:
* Source/JavaScriptCore/runtime/JSStringInlines.h:
(JSC::JSRopeString::resolveToBuffer):
(JSC::jsAtomString):
Canonical link: https://commits.webkit.org/266028@main
Identifier: [email protected]
Commit: 5d545d4f84e2ea414361c3b3fa1ebff112e26f72
https://github.com/WebKit/WebKit/commit/5d545d4f84e2ea414361c3b3fa1ebff112e26f72
Author: Yusuke Suzuki <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
A JSTests/stress/string-from-char-code-double.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGClobberize.h
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 5d994adeb6a3. rdar://problem/113143381
[JSC] Handle String.fromCharCode(double) in DFG
https://bugs.webkit.org/show_bug.cgi?id=259207
rdar://112245867
Reviewed by Mark Lam.
String.fromCharCode will perform toUInt32 onto the input. So we can just
use existing mechanism (DFG's ValueToInt32)
to accept it even if the input is double.
* JSTests/stress/string-from-char-code-double.js: Added.
(shouldBe):
(test):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
Canonical link: https://commits.webkit.org/266056@main
Identifier: [email protected]
Commit: 999bdda0e4303dace301d42bce4f922fd0a275c1
https://github.com/WebKit/WebKit/commit/999bdda0e4303dace301d42bce4f922fd0a275c1
Author: Yusuke Suzuki <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
A JSTests/microbenchmarks/rope-resolve-recursive.js
M Source/JavaScriptCore/runtime/JSString.cpp
M Source/JavaScriptCore/runtime/JSString.h
M Source/JavaScriptCore/runtime/JSStringInlines.h
M Source/WTF/wtf/Compiler.h
Log Message:
-----------
Cherry-pick 4d816460b765. rdar://problem/113143358
[JSC] Further optimize JSRopeString::resolveRope
https://bugs.webkit.org/show_bug.cgi?id=259203
rdar://112241674
Reviewed by Mark Lam.
This patch furhter improves JSRopeString::resolveRope and jsAtomString.
1. We crafted JSRopeString::resolveToBuffer very carefully so that it
becomes tail calls well.
This allows clang to make it loop instead of calls for recursive
resolveToBuffer calls, which
is significantly efficient. We ensure this condition is met by using
MUST_TAIL_CALL C++ attribute,
which is available in clang.
2. We tweak jsAtomString to make it better in terms of performance. It
turned out these duplicate part
is mandatory to make it super efficient, which is observed by
JetStream2/WSL.
Simple rope resolution gets 3-4% improvement.
ToT Patched
rope-resolve-recursive 21.3292+-0.6975 ^ 20.5524+-0.0687
^ definitely 1.0378x faster
* Source/JavaScriptCore/runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeInternalNoSubstring const):
* Source/JavaScriptCore/runtime/JSString.h:
* Source/JavaScriptCore/runtime/JSStringInlines.h:
(JSC::JSRopeString::resolveToBufferSlow):
(JSC::JSRopeString::resolveToBuffer):
(JSC::jsAtomString):
(JSC::JSStringFibers::JSStringFibers): Deleted.
(JSC::JSStringFibers::fiber const): Deleted.
(JSC::JSStringFibers::fiber0 const): Deleted.
(JSC::JSStringFibers::fiber1 const): Deleted.
(JSC::JSStringFibers::fiber2 const): Deleted.
(): Deleted.
* Source/WTF/wtf/Compiler.h:
Canonical link: https://commits.webkit.org/266060@main
Identifier: [email protected]
Commit: 87c475770c900826785b589791b1b1a241710228
https://github.com/WebKit/WebKit/commit/87c475770c900826785b589791b1b1a241710228
Author: Yusuke Suzuki <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/JavaScriptCore/runtime/PropertyName.h
Log Message:
-----------
Cherry-pick 7b6f95072a21. rdar://problem/113143380
[JSC] Early return from isCanonicalNumericIndexString when it is definitely
not a number
https://bugs.webkit.org/show_bug.cgi?id=259230
rdar://112292849
Reviewed by Alexey Shvayka.
This patch makes isCanonicalNumericIndexString early return for obvious non
number cases
so that we avoid super costly number-to-string & string-to-number path.
* Source/JavaScriptCore/runtime/PropertyName.h:
(JSC::isCanonicalNumericIndexString):
Canonical link: https://commits.webkit.org/266080@main
Identifier: [email protected]
Commit: 551d35f13ec0301694bf5f9135ad2fb324955437
https://github.com/WebKit/WebKit/commit/551d35f13ec0301694bf5f9135ad2fb324955437
Author: Richard Robinson <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/Platform/spi/mac/AppKitSPI.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/mac/WKView.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Cherry-pick 3d721c09585b. rdar://problem/111534888
REGRESSION (UI-side compositing): Jumpy full screen transition animation
https://bugs.webkit.org/show_bug.cgi?id=259375
rdar://111534888
Reviewed by Wenson Hsieh.
With UI-side compositing, when entering or exiting window fullscreen mode,
the transition is
sometimes jumpy. This happens in cases where the UI process resizes before
the web content has a
chance to resize. The web content and the UI Process should always resize
in the same CA commit.
Fix by adopting an AppKit SPI to defer entering or exiting window
fullscreen mode until the web
content has actually been resized to the new size. This is done by using a
"window snapshot readiness handler".
* Source/WTF/wtf/PlatformHave.h:
Add a new `HAVE` definition to only enable this on macOS, and only on
versions where the SPI exists.
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]):
Invokes the readiness handler and then resets it, indicating to AppKit that
the full screen should
be allowed to resume.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]):
(-[WKView _web_windowWillExitFullScreen]):
Stub methods required to compile legacy WebKit.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _doWindowSnapshotReadinessUpdate]):
(-[WKWebView setFrameSize:]):
When `setFrameSize` gets called with the new frame size, the UI process
waits for the next presentation
update of the web prcoess. Once in the completion handler, we know that the
web content has properly
resized, and so we should now invalidate the readiness handler.
(-[WKWebView _web_windowWillEnterFullScreen]):
(-[WKWebView _web_windowWillExitFullScreen]):
Upon receiving one of these notifications, we take out a window snapshot
readiness handler and store
it. This tells AppKit to defer the final stage of the enter and exit full
screen animations until
the handler is invoked.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
In some cases, `setFrameSize` would early return inside of
`didChangeFrameSize` due to these set of
methods. This caused the bug to still reproduce, since the new drawing area
size was no longer being set.
These methods have long been not actually needed, so their implementations
are now removed and there is
no longer a need for an early return.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]):
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]):
(WebKit::WebViewImpl::windowWillEnterFullScreen):
(WebKit::WebViewImpl::windowWillExitFullScreen):
When entering or exiting full screen, we now listen to their respective
notifications.
Canonical link: https://commits.webkit.org/266273@main
Identifier: [email protected]
Commit: d3ee930967af12ead6f09f97ffe956f1ad9d00ab
https://github.com/WebKit/WebKit/commit/d3ee930967af12ead6f09f97ffe956f1ad9d00ab
Author: Kyle Piddington <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj
Log Message:
-----------
Cherry-pick b258292b1506. rdar://problem/112819533
Dont build default.metallib when building ANGLE
https://bugs.webkit.org/show_bug.cgi?id=259509
<rdar://112819533>
Reviewed by Alex Christensen.
The autogenerated metal file was accidently included as a
build target in ANGLE's default shared library. It's previously
been compiled in a seperate project that builds to
"ANGLEMetalLib.metallib". After the last ANGLE roll,
it was building to both "default.metallib" and 'ANGLEMetalLib.metallib'
This change restores the previous behavior for this library.
* Source/ThirdParty/ANGLE/ANGLE.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/266307@main
Identifier: [email protected]
Commit: 6595f7362fd5d57d0abe89af093bf085ba646e67
https://github.com/WebKit/WebKit/commit/6595f7362fd5d57d0abe89af093bf085ba646e67
Author: Commit Queue <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
R LayoutTests/fast/forms/label/label-selection-expected.txt
R LayoutTests/fast/forms/label/label-selection.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/html/HTMLLabelElement.cpp
Log Message:
-----------
Cherry-pick a799925247d5. rdar://problem/112973142
Unreviewed, reverting 263420@main.
https://bugs.webkit.org/show_bug.cgi?id=259558
'caused WPT regression in test
*proxy-modifier-click-to-associated-element.tentative.html'*
Reverted changeset:
"Cannot select text within a label element that is linked to an input field"
https://bugs.webkit.org/show_bug.cgi?id=96734
https://commits.webkit.org/263420@main
Canonical link: https://commits.webkit.org/266356@main
Identifier: [email protected]
Commit: 6583e3e153197dbf213ac495086d09c2fc538deb
https://github.com/WebKit/WebKit/commit/6583e3e153197dbf213ac495086d09c2fc538deb
Author: Razvan Caliman <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js
Log Message:
-----------
Cherry-pick 48da5f9506d1. rdar://problem/112984488
Uncaught Exception: TypeError: undefined is not an object (evaluating
'this.contentBrowser.currentContentView')
https://bugs.webkit.org/show_bug.cgi?id=259566
rdar://112984488
Reviewed by Devin Rousso.
*
Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js:
(WI.SourcesNavigationSidebarPanel.prototype._handleResourceGroupingModeChanged):
Canonical link: https://commits.webkit.org/266428@main
Identifier: [email protected]
Commit: f98ac85df52f74789c4cc43350a24513f3014a82
https://github.com/WebKit/WebKit/commit/f98ac85df52f74789c4cc43350a24513f3014a82
Author: Tim Nguyen <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 9336846dfe3b. rdar://problem/112410375
[popover] Using shadow DOM wrongly auto-hides popover by light dismiss
https://bugs.webkit.org/show_bug.cgi?id=259261
rdar://112410375
Reviewed by Ryosuke Niwa and Darin Adler.
Use the flat tree as mandated by the spec when calculating which popover to
light dismiss:
- https://html.spec.whatwg.org/#topmost-clicked-popover
- https://html.spec.whatwg.org/#nearest-inclusive-open-popover
- https://html.spec.whatwg.org/#nearest-inclusive-target-popover-for-invoker
*
LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/html/semantics/popovers/popover-light-dismiss-flat-tree.html:
Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::handlePopoverLightDismiss):
Canonical link: https://commits.webkit.org/266457@main
Identifier: [email protected]
Commit: 422f537ae4b3c8066a3c58271435b8f12f5bfe68
https://github.com/WebKit/WebKit/commit/422f537ae4b3c8066a3c58271435b8f12f5bfe68
Author: Tyler Wilcock <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/WebCore/accessibility/AXLogger.cpp
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/AXObjectCache.h
M Source/WebCore/accessibility/AccessibilityMenuListOption.h
M Source/WebCore/accessibility/AccessibilitySpinButton.h
Log Message:
-----------
Cherry-pick 5b4bb30a99e4. rdar://problem/113042000
Cherry-pick 266406@main (5b4bb30a99e4). rdar://113042000
AX: Finish converting all WebCore/accessibility member variables to use
smart pointers
https://bugs.webkit.org/show_bug.cgi?id=259606
rdar://113042000
Reviewed by Chris Fleizach.
Continued work towards complying with
https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines.
* Source/WebCore/accessibility/AXLogger.cpp:
(WebCore::AXLogger::log):
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::AXObjectCache):
(WebCore::AXObjectCache::rootObject):
(WebCore::AXObjectCache::setIsolatedTreeRoot):
(WebCore::AXObjectCache::remove):
(WebCore::AXObjectCache::deferNodeAddedOrRemoved):
(WebCore::AXObjectCache::notificationPostTimerFired):
(WebCore::AXObjectCache::focusCurrentModal):
(WebCore::AXObjectCache::characterOffsetForPoint):
(WebCore::filterWeakListHashSetForRemoval):
(WebCore::filterWeakHashMapForRemoval):
(WebCore::AXObjectCache::prepareForDocumentDestruction):
(WebCore::AXObjectCache::performDeferredCacheUpdate):
(WebCore::AXObjectCache::deferTextChangedIfNeeded):
(WebCore::AXObjectCache::deferTextReplacementNotificationForTextControl):
(WebCore::AXObjectCache::rootWebArea):
(WebCore::AXObjectCache::updateRelationsIfNeeded):
(WebCore::AXObjectCache::addRelations):
* Source/WebCore/accessibility/AXObjectCache.h:
(WebCore::AXObjectCache::document const):
* Source/WebCore/accessibility/AccessibilityMenuListOption.h:
* Source/WebCore/accessibility/AccessibilitySpinButton.h:
Canonical link: https://commits.webkit.org/266406@main
Identifier: [email protected]
Commit: 651b005b2ef77b0a44d2c3024a95f3801a8d1eb7
https://github.com/WebKit/WebKit/commit/651b005b2ef77b0a44d2c3024a95f3801a8d1eb7
Author: Wenson Hsieh <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm
Log Message:
-----------
Cherry-pick 4f26424a4687. rdar://problem/113060681
REGRESSION (266341@main): mousemove no longer dispatched when UI-side
compositing is disabled
https://bugs.webkit.org/show_bug.cgi?id=259618
Reviewed by Aditya Keerthi.
After the changes in 266341@main, when UI-side compositing is disabled, we
can end up in a state where mouse events are
indefinitely queued in the UI process, as the web process never flushes the
deferred DidReceiveEvent message for a
mousemove event that has already been handled. This is because
`TiledCoreAnimationDrawingArea::scheduleRenderingUpdate`
is unimplemented, and so nothing guarantees that we'll eventually send the
deferred `DidReceiveEvent` back to the UI
process.
Fix this by avoiding the deferred `DidReceiveEvent` if
`scheduleRenderingUpdate()` returns `false` (indicating that no
rendering update is scheduled). In practice, this effectively disables the
changes in 266341@main unless we're using a
remote layer tree drawing area, which is now the default on both macOS
Sonoma (in most device models) and iOS 17, which
enable UI-side compositing.
Test: MouseEventTests.SendMouseMoveEventStream
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::mouseEvent):
* Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm:
Canonical link: https://commits.webkit.org/266411@main
Identifier: [email protected]
Commit: 9165679994d6d4a37796d116e9a85f139da903f3
https://github.com/WebKit/WebKit/commit/9165679994d6d4a37796d116e9a85f139da903f3
Author: Myah Cobbs <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
R LayoutTests/fast/table/table-inside-continuation-removed-expected.txt
R LayoutTests/fast/table/table-inside-continuation-removed.html
M Source/WebCore/rendering/RenderTable.cpp
M Source/WebCore/rendering/RenderTable.h
M Source/WebCore/rendering/RenderTableCol.cpp
Log Message:
-----------
Revert "Cherry-pick e1cc9fc57dbe. rdar://problem/111803504"
* LayoutTests/fast/table/table-inside-continuation-removed-expected.txt:
Removed.
* LayoutTests/fast/table/table-inside-continuation-removed.html: Removed.
* Source/WebCore/rendering/RenderTable.cpp:
(WebCore::RenderTable::removeColumn):
(WebCore::RenderTable::invalidateColumns): Deleted.
* Source/WebCore/rendering/RenderTable.h:
* Source/WebCore/rendering/RenderTableCol.cpp:
(WebCore::RenderTableCol::willBeRemovedFromTree):
Identifier: [email protected]
Commit: 995ad4598bd2399e6feec6a7cec1c298b98a5742
https://github.com/WebKit/WebKit/commit/995ad4598bd2399e6feec6a7cec1c298b98a5742
Author: Cameron McCormack <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Source/WebCore/html/HTMLCanvasElement.h
M Source/WebCore/html/canvas/CanvasStyle.cpp
Log Message:
-----------
Cherry-pick 5ec234192a2e. rdar://problem/112439220
Cherry-pick 266238@main (5ec234192a2e). rdar://112439220
Avoid creating a new CSSParserContext each time a color is assigned to
fillStyle/strokeStyle on a canvas context
https://bugs.webkit.org/show_bug.cgi?id=259431
rdar://112439220
Reviewed by Tim Nguyen.
Creating the CSSParserContext is slightly expensive, since it fetches
all of the relevant document Settings.
* Source/WebCore/html/HTMLCanvasElement.h:
(WebCore::HTMLCanvasElement::cssParserContext):
* Source/WebCore/html/canvas/CanvasStyle.cpp:
(WebCore::parseColor):
Canonical link: https://commits.webkit.org/266238@main
Identifier: [email protected]
Commit: 06e494697172df9383c7f1a4e214e3a48452bc6b
https://github.com/WebKit/WebKit/commit/06e494697172df9383c7f1a4e214e3a48452bc6b
Author: Myah Cobbs <[email protected]>
Date: 2023-08-03 (Thu, 03 Aug 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/Platform/spi/mac/AppKitSPI.h
M Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h
M Source/WebKit/UIProcess/API/mac/WKView.mm
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h
M Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm
M Source/WebKit/UIProcess/mac/WebViewImpl.h
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
Log Message:
-----------
Revert "Cherry-pick 3d721c09585b. rdar://problem/111534888"
This reverts commit 551d35f13ec0301694bf5f9135ad2fb324955437.
* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/Platform/spi/mac/AppKitSPI.h:
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView dealloc]):
(-[WKWebView _invalidateWindowSnapshotReadinessHandler]): Deleted.
* Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h:
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView setFrameSize:]):
(-[WKWebView _doWindowSnapshotReadinessUpdate]): Deleted.
(-[WKWebView _holdWindowResizeSnapshotWithReason:]): Deleted.
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.h:
* Source/WebKit/UIProcess/mac/WKViewLayoutStrategy.mm:
(-[WKViewLayoutStrategy disableFrameSizeUpdates]):
(-[WKViewLayoutStrategy enableFrameSizeUpdates]):
(-[WKViewLayoutStrategy frameSizeUpdatesDisabled]):
(-[WKViewLayoutStrategy didChangeFrameSize]):
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Identifier: [email protected]
Commit: 3de3fe9c701d81b18a7ca8317c0dfae068b18980
https://github.com/WebKit/WebKit/commit/3de3fe9c701d81b18a7ca8317c0dfae068b18980
Author: Ryan Reno <[email protected]>
Date: 2023-08-03 (Thu, 03 Aug 2023)
Changed paths:
M Source/WTF/wtf/MemoryPressureHandler.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick 8299d7639dd9. rdar://problem/109875865
Change compositing policy in response to memory pressure status
https://bugs.webkit.org/show_bug.cgi?id=259580
rdar://109875865
Reviewed by Simon Fraser.
We switch to a more conservative compositing policy when the
MemoryPressureHandler has a change in memory usage policy at most every
2 seconds. In some cases we can enter memory warning and critical memory
pressure situations and get a foreground jetsam before this 2s has
expired. This change will respond to recent memory warning and memory
pressure notifications in order to change the compositing policy. While we
can't guarantee to not jetsam, this does improve our chances of
reducing layer counts before the system gets critically low on
memory.
* Source/WTF/wtf/MemoryPressureHandler.h:
(WTF::MemoryPressureHandler::isUnderMemoryWarning const):
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateCompositingPolicy):
Canonical link: https://commits.webkit.org/266497@main
Identifier: [email protected]
Commit: c8736cca5fbdc1c0f2e6fbab5b8e1a0c25e2a1c3
https://github.com/WebKit/WebKit/commit/c8736cca5fbdc1c0f2e6fbab5b8e1a0c25e2a1c3
Author: Tim Horton <[email protected]>
Date: 2023-08-03 (Thu, 03 Aug 2023)
Changed paths:
M Source/WTF/wtf/dtoa/utils.h
Log Message:
-----------
Cherry-pick 9bd05bda44cc. rdar://problem/113341253
dtoa/utils.h doesn't parse after recent SDK changes
https://bugs.webkit.org/show_bug.cgi?id=259789
rdar://113341253
Reviewed by Wenson Hsieh.
* Source/WTF/wtf/dtoa/utils.h:
Recent SDK changes resulted in CoreUtils headers getting imported into
translation units (OutputContext.mm) that also import `dtoa/utils.h`.
The aforementioned CoreUtils headers have long had macros Min() and Max(),
which conflict with our template functions' definitions, and make utils.h
fail to parse.
As a quick workaround, undefine the rogue macros before our Min() and Max().
Canonical link: https://commits.webkit.org/266550@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 553da0f7b52cc50e34d76e9e1379c700f349385b
https://github.com/WebKit/WebKit/commit/553da0f7b52cc50e34d76e9e1379c700f349385b
Author: Tim Horton <[email protected]>
Date: 2023-08-03 (Thu, 03 Aug 2023)
Changed paths:
M Source/WTF/wtf/SHA1.h
Log Message:
-----------
Cherry-pick 9809c1a27c82. rdar://problem/113360320
SHA1.h doesn't parse after recent SDK changes
https://bugs.webkit.org/show_bug.cgi?id=259800
rdar://113360320
Reviewed by Megan Gardner and Wenson Hsieh.
* Source/WTF/wtf/SHA1.h:
Recent SDK changes resulted in CoreUtils headers getting imported into
translation units (MediaPlayerPrivateWebM.mm) that also import `SHA1.h`.
The aforementioned CoreUtils headers have long had a macro SHA1(),
which conflict with our template functions' definitions, and make SHA1.h
fail to parse.
As a quick workaround, undefine the rogue macros before our SHA1 class.
Canonical link: https://commits.webkit.org/266559@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: de9566e607cb7bf528b77db2a8fa87638954639c
https://github.com/WebKit/WebKit/commit/de9566e607cb7bf528b77db2a8fa87638954639c
Author: Richard Robinson <[email protected]>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm
Log Message:
-----------
Cherry-pick 43da1fd1587a. rdar://problem/111534888
WebKit Media: Toggling fullscreen fails to work
https://bugs.webkit.org/show_bug.cgi?id=259760
rdar://111534888
Reviewed by Aditya Keerthi.
The window resize handler is created when receiving the
`will{Enter|Exit}FullScreen` notification,
and is then invalidated as a result of `setFrameSize` being called.
However, when transiting to/from
element full screen, `setFrameSize` is called before the notification is
posted, instead of after.
This causes the handler to never be invalidated.
Fix by creating the handler directly inside `setFrameSize`, and not rely on
the full screen
notifications at all. This is ok since `_holdResizeSnapshotWithReason` only
returns a non-nil block
when entering or exiting full screen, so it has no effect in other cases.
No new tests, since all tests in `FullscreenVideoTextRecognition` already
test this behavior in some
configurations.
* Source/WebKit/UIProcess/API/mac/WKView.mm:
(-[WKView _web_windowWillEnterFullScreen]): Deleted.
(-[WKView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/API/mac/WKWebViewMac.mm:
(-[WKWebView _holdWindowResizeSnapshotWithReason:]):
(-[WKWebView setFrameSize:]):
(-[WKWebView _web_windowWillEnterFullScreen]): Deleted.
(-[WKWebView _web_windowWillExitFullScreen]): Deleted.
* Source/WebKit/UIProcess/mac/WebViewImpl.h:
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(-[WKWindowVisibilityObserver startObserving:]):
(-[WKWindowVisibilityObserver stopObserving:]):
(-[WKWindowVisibilityObserver _windowWillEnterFullScreen:]): Deleted.
(-[WKWindowVisibilityObserver _windowWillExitFullScreen:]): Deleted.
(WebKit::WebViewImpl::windowWillEnterFullScreen): Deleted.
(WebKit::WebViewImpl::windowWillExitFullScreen): Deleted.
Canonical link: https://commits.webkit.org/266558@main
Identifier: [email protected]
Commit: 916a90535d784a62a78224e1223d546c69c5fe91
https://github.com/WebKit/WebKit/commit/916a90535d784a62a78224e1223d546c69c5fe91
Author: Andres Gonzalez <[email protected]>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M LayoutTests/accessibility/mac/basic-embed-pdf-accessibility-expected.txt
M LayoutTests/accessibility/mac/basic-embed-pdf-accessibility.html
M LayoutTests/accessibility/mac/iframe-pdf.html
Log Message:
-----------
Cherry-pick 00389e4e1673. rdar://problem/110029481
REGRESSION: Two accessibility/mac/ tests are a consistent failure
https://bugs.webkit.org/show_bug.cgi?id=259452
rdar://110029481
Reviewed by Chris Fleizach.
These tests needed to be re-based and the value of the static text needs to
be trimEnd() to accomodate differences in trailing \n between OS versions.
* LayoutTests/accessibility/mac/basic-embed-pdf-accessibility-expected.txt:
* LayoutTests/accessibility/mac/basic-embed-pdf-accessibility.html:
* LayoutTests/accessibility/mac/iframe-pdf-expected.txt:
Canonical link: https://commits.webkit.org/266296@main
Commit: 8505c76e299d4d6360072eac71d8ea9f072fb5c3
https://github.com/WebKit/WebKit/commit/8505c76e299d4d6360072eac71d8ea9f072fb5c3
Author: Chris Dumez <[email protected]>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Source/WTF/wtf/ThreadSafeWeakHashSet.h
M Source/WTF/wtf/WeakHashMap.h
M Source/WTF/wtf/WeakHashSet.h
M Source/WTF/wtf/WeakListHashSet.h
M Source/WebKit/NetworkProcess/NetworkDataTask.cpp
M Source/WebKit/NetworkProcess/NetworkDataTaskBlob.cpp
M Source/WebKit/NetworkProcess/NetworkDataTaskDataURL.cpp
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/NetworkSession.h
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
M Source/WebKit/NetworkProcess/curl/NetworkDataTaskCurl.cpp
M Source/WebKit/NetworkProcess/soup/NetworkDataTaskSoup.cpp
M Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp
Log Message:
-----------
Cherry-pick 177d6881d88d. rdar://problem/112162921
Regression: NetworkDataTask's ThreadSafeWeakPtrControlBlock are leaking
https://bugs.webkit.org/show_bug.cgi?id=259808
rdar://112162921
Reviewed by Alex Christensen.
The NetworkProcess memory was growing unboundedly during long-running
browsing
benchmarks, which the number of NetworkDataTask's
ThreadSafeWeakPtrControlBlock
objects growing very large.
The issue was with the `ThreadSafeWeakHashSet<NetworkDataTask>
m_dataTaskSet`
container on the NetworkSession. We would add NetworkDataTask objects to
this
WeakHashSet and never explicitly remove them. We had a comment in the code
indicating that the ThreadSafeWeakHashSet's amortized clean up would take
care
of removing them. The issue though is that amortized clean up would never
happen
and m_dataTaskSet's internal Set would just grow unboundedly, keeping
control
blocks alive.
The reason amortized clean up never triggered is that we only add to
m_dataTaskSet,
we never remove from it, never clear it and we only very rarely call
forEach() on
it. As a result, ThreadSafeWeakHashSet::m_operationCountSinceLastCleanup
would only
increment due to the add() calls. The condition for amortized clean up was:
`++m_operationCountSinceLastCleanup / 2 > m_set.size()`.
Since m_operationCountSinceLastCleanup would only increase due to the add()
calls
and since nothing would ever get removed from the set,
`m_operationCountSinceLastCleanup / 2`
could never reach the size of the set.
I am making several fixes in this patch:
1. I added a `|| m_operationCountSinceLastCleanup >
m_maxOperationCountWithoutCleanup`
check to amortized clean up to guarantee that amortized clean up
eventually happens
and that such weak containers can never grow unboundedly, no matter how
they are used.
m_maxOperationCountWithoutCleanup gets multiplied by 2 whenever the
clean up finds
nothing for proper amortization.
2. I made it so that NetworkDataTask objects remove themselves from the
ThreadSafeWeakHashSet
in their destructor. This is good practice no matter what and makes such
the set stays
small.
3. I actually found a bug in `ThreadSafeWeakHashSet::remove()` when
implementing the fix in
(2). ThreadSafeWeakHashSet::remove() would fail to remove the object
from the set if the
call if made after the object destructor has started running! The reason
for this is that
the ThreadSafeWeakHashSet was using a `std::pair<ControlBlockRefPtr,
const T*>` as set
key internally. This means that we needed to create a ControlBlockRefPtr
of the object's
control block in remove() in order to remove the object from the map.
However, 265344@main
made it so that ref'ing a control block returns nullptr after the object
has started
destruction. As a result, the first item in the key pair would be
nullptr and we'd fail
to remove. To address the issue, I am dropping the ControlBlockRefPtr
from the key and
using a `HashMap<const T*, ControlBlockRefPtr>` instead of a HashSet.
* Source/WTF/wtf/ThreadSafeWeakHashSet.h:
* Source/WTF/wtf/WeakHashMap.h:
* Source/WTF/wtf/WeakHashSet.h:
* Source/WTF/wtf/WeakListHashSet.h:
* Source/WebKit/NetworkProcess/NetworkDataTask.cpp:
(WebKit::NetworkDataTask::~NetworkDataTask):
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::registerNetworkDataTask):
(WebKit::NetworkSession::unregisterNetworkDataTask):
* Source/WebKit/NetworkProcess/NetworkSession.h:
* Tools/TestWebKitAPI/Tests/WTF/WeakPtr.cpp:
(TestWebKitAPI::ObjectAddingAndRemovingItself::create):
(TestWebKitAPI::ObjectAddingAndRemovingItself::~ObjectAddingAndRemovingItself):
(TestWebKitAPI::ObjectAddingAndRemovingItself::ObjectAddingAndRemovingItself):
(TestWebKitAPI::TEST):
(TestWebKitAPI::ObjectAddingItselfOnly::create):
(TestWebKitAPI::ObjectAddingItselfOnly::ObjectAddingItselfOnly):
Canonical link: https://commits.webkit.org/266594@main
Commit: 6e35c55b155033cc5a6c6fb467753559df2af02b
https://github.com/WebKit/WebKit/commit/6e35c55b155033cc5a6c6fb467753559df2af02b
Author: Myah Cobbs <[email protected]>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.27.13.2
Identifier: [email protected]
Commit: 77a5e1d430357bce4a8aa65a99df0d975c782633
https://github.com/WebKit/WebKit/commit/77a5e1d430357bce4a8aa65a99df0d975c782633
Author: Dan Robson <[email protected]>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.27.13.3
Identifier: [email protected]
Commit: e6ebf7aee39a8b14045a26626a122dc105226b06
https://github.com/WebKit/WebKit/commit/e6ebf7aee39a8b14045a26626a122dc105226b06
Author: Chris Dumez <[email protected]>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkDataTask.cpp
Log Message:
-----------
Cherry-pick c0a7c3bf2d79. rdar://problem/114003508
Regression(266594@main) Crash under
NetworkSession::unregisterNetworkDataTask()
https://bugs.webkit.org/show_bug.cgi?id=259910
<rdar://113530127>
Reviewed by J Pascoe.
NetworkDataTask::m_session is a WeakPtr and may thus be null by the time the
NetworkDataTask runs. Null check it before calling
`unregisterNetworkDataTask()`
on it.
* Source/WebKit/NetworkProcess/NetworkDataTask.cpp:
(WebKit::NetworkDataTask::~NetworkDataTask):
Canonical link: https://commits.webkit.org/266690@main
Identifier: [email protected]
Commit: 56841855159e36c4ce337e6c1985a3a4e4c90fd8
https://github.com/WebKit/WebKit/commit/56841855159e36c4ce337e6c1985a3a4e4c90fd8
Author: Dan Robson <[email protected]>
Date: 2023-08-17 (Thu, 17 Aug 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkDataTask.cpp
Log Message:
-----------
Revert "Cherry-pick c0a7c3bf2d79. rdar://problem/114003508"
This reverts commit e6ebf7aee39a8b14045a26626a122dc105226b06.
Identifier: [email protected]
Commit: e1e3821203984ac9d25c3f6e613b71b10ea071dd
https://github.com/WebKit/WebKit/commit/e1e3821203984ac9d25c3f6e613b71b10ea071dd
Author: Dan Robson <[email protected]>
Date: 2023-08-18 (Fri, 18 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.27.13.4
Identifier: [email protected]
Commit: db16d356bd90d790b7fc3c296ef70ba4b08efa4f
https://github.com/WebKit/WebKit/commit/db16d356bd90d790b7fc3c296ef70ba4b08efa4f
Author: Yusuke Suzuki <[email protected]>
Date: 2023-08-18 (Fri, 18 Aug 2023)
Changed paths:
M Source/JavaScriptCore/heap/MachineStackMarker.h
M Source/WTF/wtf/ThreadGroup.cpp
M Source/WTF/wtf/ThreadGroup.h
M Source/WTF/wtf/Threading.cpp
M Source/WTF/wtf/Threading.h
M Source/WTF/wtf/linux/RealTimeThreads.h
M Source/WTF/wtf/threads/Signals.cpp
M Tools/TestWebKitAPI/Tests/WTF/ThreadGroup.cpp
Log Message:
-----------
Cherry-pick 3dd121c2e42e. rdar://113739113
[WTF] Revert ThreadGroup to std::shared_ptr / std::weak_ptr implementation
https://bugs.webkit.org/show_bug.cgi?id=260373
rdar://113739113
Reviewed by Mark Lam.
Speculative fix. Let's revert our ThreadGroup and Thread implementation to
use std::shared_ptr and std::weak_ptr
instead of WebKit ThreadSafeWeakPtr and ThreadSafeWeakHashSet. This is
basically partial revert of 257595@main
and 258267@main (reverting part related to ThreadGroup and Thread).
* Source/JavaScriptCore/heap/MachineStackMarker.h:
* Source/WTF/wtf/ThreadGroup.cpp:
(WTF::ThreadGroup::~ThreadGroup):
(WTF::ThreadGroup::create): Deleted.
* Source/WTF/wtf/ThreadGroup.h:
* Source/WTF/wtf/Threading.cpp:
(WTF::Thread::didExit):
(WTF::Thread::addToThreadGroup):
(WTF::Thread::removeFromThreadGroup):
(WTF::Thread::numberOfThreadGroups):
* Source/WTF/wtf/Threading.h:
* Source/WTF/wtf/linux/RealTimeThreads.h:
* Source/WTF/wtf/threads/Signals.cpp:
(WTF::activeThreads):
* Tools/TestWebKitAPI/Tests/WTF/ThreadGroup.cpp:
(TestWebKitAPI::testThreadGroup):
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/267043@main
Identifier: [email protected]
Compare: https://github.com/WebKit/WebKit/compare/19413cffce1b%5E...db16d356bd90
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
