Branch: refs/heads/safari-7616.1.27.12-branch
Home: https://github.com/WebKit/WebKit
Commit: 52d51c5672dd40065ca16dbcb13292f7bd9e32da
https://github.com/WebKit/WebKit/commit/52d51c5672dd40065ca16dbcb13292f7bd9e32da
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
Commit: d7bf98f9420dd7fcff6074b8ea61e96873048bde
https://github.com/WebKit/WebKit/commit/d7bf98f9420dd7fcff6074b8ea61e96873048bde
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
Commit: 1119c707f2d15667066db70d913af44d941e1c5e
https://github.com/WebKit/WebKit/commit/1119c707f2d15667066db70d913af44d941e1c5e
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
Commit: 31d334ea3a59fcba14b796764a7dc57dfa461775
https://github.com/WebKit/WebKit/commit/31d334ea3a59fcba14b796764a7dc57dfa461775
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
Commit: 90d1e36ae21e73cf68ee55fc7b8f20bbd614a92d
https://github.com/WebKit/WebKit/commit/90d1e36ae21e73cf68ee55fc7b8f20bbd614a92d
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
Commit: 3a3690406bad482c86bc0fa26340c862ccc68aaf
https://github.com/WebKit/WebKit/commit/3a3690406bad482c86bc0fa26340c862ccc68aaf
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
Commit: 781cdefc43c252f7d971582acb89904571c89f98
https://github.com/WebKit/WebKit/commit/781cdefc43c252f7d971582acb89904571c89f98
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
Commit: bd66501be48747b904cd5f17253a072eb29e1a4f
https://github.com/WebKit/WebKit/commit/bd66501be48747b904cd5f17253a072eb29e1a4f
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
Commit: 5cbb600e07bc21afcce98a7769da10eb0446c643
https://github.com/WebKit/WebKit/commit/5cbb600e07bc21afcce98a7769da10eb0446c643
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
Commit: 5fd4a3661b3595370077221b59dfbfcb85129894
https://github.com/WebKit/WebKit/commit/5fd4a3661b3595370077221b59dfbfcb85129894
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
Commit: 88996ca7d0284a0bbc1f2d4dc08c52834f16fd44
https://github.com/WebKit/WebKit/commit/88996ca7d0284a0bbc1f2d4dc08c52834f16fd44
Author: Myah Cobbs <[email protected]>
Date: 2023-08-02 (Wed, 02 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.27.12.1
Identifier: [email protected]
Commit: b89253d49b3cd6e5fac8548e203122ac582526a9
https://github.com/WebKit/WebKit/commit/b89253d49b3cd6e5fac8548e203122ac582526a9
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
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: e518f3d1adf803bb1384cf349968c2c711ac9815
https://github.com/WebKit/WebKit/commit/e518f3d1adf803bb1384cf349968c2c711ac9815
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: e44faa01639796ab2a4162ab31a5293c25b61147
https://github.com/WebKit/WebKit/commit/e44faa01639796ab2a4162ab31a5293c25b61147
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"
This reverts commit d5628c0d1d4fe59b2de1788c5d4f9f4a477000ee.
Identifier: [email protected]
Commit: 3fc65eb2fc83bd96b73138fd72a72554cd20344a
https://github.com/WebKit/WebKit/commit/3fc65eb2fc83bd96b73138fd72a72554cd20344a
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
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: c4744a0b2aada6b4f1a95a19f5abc23160c60f5b
https://github.com/WebKit/WebKit/commit/c4744a0b2aada6b4f1a95a19f5abc23160c60f5b
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 3a3690406bad482c86bc0fa26340c862ccc68aaf.
Identifier: [email protected]
Commit: 0500520ad9e91f51672af8ebedab3c44f9fd8a59
https://github.com/WebKit/WebKit/commit/0500520ad9e91f51672af8ebedab3c44f9fd8a59
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: 71b60c14ecdab01b39ca202561ea51b223f3a437
https://github.com/WebKit/WebKit/commit/71b60c14ecdab01b39ca202561ea51b223f3a437
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: ad8ed2ff992809713d2419d97d84b73b8f76a992
https://github.com/WebKit/WebKit/commit/ad8ed2ff992809713d2419d97d84b73b8f76a992
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: 634dedd15e817017b3eb365b8cc99f15be88c7a3
https://github.com/WebKit/WebKit/commit/634dedd15e817017b3eb365b8cc99f15be88c7a3
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: 6d1f8f7754c663c59c42eea0191797057034afdc
https://github.com/WebKit/WebKit/commit/6d1f8f7754c663c59c42eea0191797057034afdc
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: 59abeaa908ae80f4b5dcc727a4e1399926027533
https://github.com/WebKit/WebKit/commit/59abeaa908ae80f4b5dcc727a4e1399926027533
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: e0a2de4aff82ff5a9bc40c38fc60f3c6601b4d9c
https://github.com/WebKit/WebKit/commit/e0a2de4aff82ff5a9bc40c38fc60f3c6601b4d9c
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.12.2
Identifier: [email protected]
Commit: 9df68116621ca266507bc919d884c5a5a4d7935a
https://github.com/WebKit/WebKit/commit/9df68116621ca266507bc919d884c5a5a4d7935a
Author: Kocsen Chung <[email protected]>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7616.1.27.12.3
Identifier: [email protected]
Commit: f694ce5984bfa4743695a4e285bdd4bee812f71a
https://github.com/WebKit/WebKit/commit/f694ce5984bfa4743695a4e285bdd4bee812f71a
Author: Wenson Hsieh <[email protected]>
Date: 2023-08-04 (Fri, 04 Aug 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/LockdownModeFonts.mm
Log Message:
-----------
Cherry-pick eb66cb954736. rdar://problem/112281112
[watchOS] Turning on lockdown mode should not cause certain web fonts to be
enabled
https://bugs.webkit.org/show_bug.cgi?id=259791
rdar://112281112
Reviewed by Aditya Keerthi.
To optimize performance and data use, web fonts are currently always
disabled on watchOS. However,
enabling lockdown mode on watchOS actually causes us to *enable* support
for a small subset for web
fonts, since we change `DownloadableBinaryFontAllowedTypes` state from
`None` (i.e. no web fonts
allowed at all) to `Restricted`. This subsequently causes cached fonts in
the GPU process to end up
in an unexpected state on watchOS, triggering a `MESSAGE_CHECK` and causing
the web process to
terminate.
It doesn't make sense for Lockdown mode to make web fonts *less*
restrictive, so we can simply fix
this by maintaining `DownloadableBinaryFontAllowedTypes::None` in the case
where web fonts are
already unconditionally disabled.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::adjustSettingsForLockdownMode):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LockdownModeFonts.mm:
Rebaseline an API test for compatibility with watchOS as well, where web
fonts are always disabled.
Canonical link: https://commits.webkit.org/266563@main
Commit: be537d95832ec87a3325c11f8850f71f1a1c4735
https://github.com/WebKit/WebKit/commit/be537d95832ec87a3325c11f8850f71f1a1c4735
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.12.4
Identifier: [email protected]
Commit: 58863a520c8919bcf403ee6ba4fba7dcd5c18080
https://github.com/WebKit/WebKit/commit/58863a520c8919bcf403ee6ba4fba7dcd5c18080
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: d4513469c1400a29dc6eb056a1c0cf1a99d32192
https://github.com/WebKit/WebKit/commit/d4513469c1400a29dc6eb056a1c0cf1a99d32192
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://problem/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]
Commit: e1deb17f80640b781913badba2fce9a761689e9f
https://github.com/WebKit/WebKit/commit/e1deb17f80640b781913badba2fce9a761689e9f
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.12.5
Identifier: [email protected]
Compare: https://github.com/WebKit/WebKit/compare/52d51c5672dd%5E...e1deb17f8064
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
