Branch: refs/heads/safari-7618.1.15.12-branch
Home: https://github.com/WebKit/WebKit
Commit: e6a859812f68d2c7e1bff4a0acea2b5f8627f85b
https://github.com/WebKit/WebKit/commit/e6a859812f68d2c7e1bff4a0acea2b5f8627f85b
Author: Kimmo Kinnunen <[email protected]>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M
LayoutTests/fast/canvas/offscreen-giant-transfer-to-imagebitmap-expected.txt
M
LayoutTests/platform/ios/fast/canvas/offscreen-giant-transfer-to-imagebitmap-expected.txt
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
Log Message:
-----------
Cherry-pick 26aaa25dcbdc. rdar://122309325
REGRESSION(267824@main): Changing HTMLCanvasElement width, height causes
intermediate buffer allocations
https://bugs.webkit.org/show_bug.cgi?id=268745
rdar://122309325
Reviewed by Simon Fraser.
Resizing is intended to leave the buffer unallocated, so that
sequential width, height assignments will not allocate multiple times.
This intention was nullified by CanvasRenderingContext2DBase::reset().
Calling resetTransform redundantly would recreate the buffer
immediately from width, height attribute setters.
The transform reset is redundant, the context transform is reset when
the context state saver is restored and re-saved.
Clearing the canvas doesn't need to use public
CanvasRenderingContext2DBase::clearCanvas() that will mutate the context
state. The state is in known state with initial transform, and thus it
doesn't need transform mutation.
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::CanvasRenderingContext2DBase::reset):
Canonical link: https://commits.webkit.org/274135@main
Identifier: [email protected]
Commit: 7ff929c51b262132ce42e0f4f80edadb785a6e78
https://github.com/WebKit/WebKit/commit/7ff929c51b262132ce42e0f4f80edadb785a6e78
Author: Ben Nham <[email protected]>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
Log Message:
-----------
Cherry-pick f4ce57789de5. rdar://121185956
hideContentUntilPendingUpdate async IPC call during backgrounding blocks
process suspension
https://bugs.webkit.org/show_bug.cgi?id=268799
rdar://121185956
Reviewed by Chris Dumez.
On iOS, when the UIProcess goes into the background, it eventually calls in
to
hideContentUntilPendingUpdate through this call stack:
```
WebKit::RemoteLayerTreeDrawingAreaProxy::hideContentUntilPendingUpdate()
WebKit::WebPageProxy::applicationDidFinishSnapshottingAfterEnteringBackground()
WebKit::ApplicationStateTracker::didCompleteSnapshotSequence()
```
The problem is that we recently added an async
`DrawingArea::DispatchAfterEnsuringDrawing` IPC with
reply handler call to hideContentUntilPendingUpdate (see 269776@main,
270672@main, 271260@main). An
async IPC with a reply handler in the UIProcess implicitly takes out a
background activity which
prevents the WebContent process (and also the UIProcess) from suspending
until the reply handler
runs. Unfortunately, since the WebContent process is in the background,
presumably it doesn't
render, so the DispatchAfterEnsuringDrawing reply handler doesn't run, and
the background activity
also never completes. We basically end up blocking process suspension
entirely until the 15 second
timer in ProcessStateMonitor expires and forcefully invalidates all
background activities for all
processes.
We need to fix this by reworking the logic somehow or by making this
DispatchAfterEnsuringDrawing
IPC not create a background activity. Here I'm just trying to make the IPC
call not start a
background activity.
Note that there's also a DispatchAfterEnsuringDrawing call in WebPageProxy
that I didn't touch since
I don't have evidence that it's causing a background power regression, but
I wonder if that also
should avoid creating a background activity.
*
Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::hideContentUntilPendingUpdate):
Canonical link: https://commits.webkit.org/274157@main
Identifier: [email protected]
Commit: 5e0a5632b3321dabf1f2b427c0dc681153cf90bc
https://github.com/WebKit/WebKit/commit/5e0a5632b3321dabf1f2b427c0dc681153cf90bc
Author: Russell Epstein <[email protected]>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7618.1.15.12.1
Identifier: [email protected]
Commit: 9952c70b8dc64278be024239d63f0e93b7edc55c
https://github.com/WebKit/WebKit/commit/9952c70b8dc64278be024239d63f0e93b7edc55c
Author: Elliott Williams <[email protected]>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WTF/wtf/spi/cocoa/IOSurfaceSPI.h
M Source/WTF/wtf/spi/darwin/XPCSPI.h
M Source/WebCore/PAL/pal/spi/cocoa/AVFoundationSPI.h
A Source/WebCore/PAL/pal/spi/ios/BrowserEngineKitSPI.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
Log Message:
-----------
Cherry-pick 5cdf58dba105. rdar://121706323
Cherry-pick 274016@main (98226f6cc5f3). rdar://problem/121706323
[iOS] Update SPI headers for iOS 17.4
https://bugs.webkit.org/show_bug.cgi?id=268210
rdar://problem/121706323
Reviewed by Jonathan Bedard and Alexey Proskuryakov.
Add platform flags for libxpc (which is API as of iOS 17.4+) and for
other SPI that were promoted to API as part of the BrowserEngineKit
introduction. Use them to avoid redeclaring things that are now
publicly available.
Additionally, write new BrowserEngineKit SPI declarations for symbols
that are used in testing and by SPI clients of WebKit.
* Source/WTF/wtf/PlatformHave.h:
* Source/WTF/wtf/spi/cocoa/IOSurfaceSPI.h:
* Source/WTF/wtf/spi/darwin/XPCSPI.h:
* Source/WebCore/PAL/pal/spi/cocoa/AVFoundationSPI.h:
* Source/WebCore/PAL/pal/spi/ios/BrowserEngineKitSPI.h:
* Source/WebKit/Platform/spi/ios/UIKitSPI.h:
* Tools/TestRunnerShared/spi/UIKitSPIForTesting.h:
Canonical link: https://commits.webkit.org/274016@main
Canonical link: https://commits.webkit.org/272448.522@safari-7618-branch
Identifier: [email protected]
Commit: f9c31bfd8bc3cf9eb83ff42fa470f7833e549e76
https://github.com/WebKit/WebKit/commit/f9c31bfd8bc3cf9eb83ff42fa470f7833e549e76
Author: Myah Cobbs <[email protected]>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WTF/wtf/spi/cocoa/IOSurfaceSPI.h
M Source/WTF/wtf/spi/darwin/XPCSPI.h
M Source/WebCore/PAL/pal/spi/cocoa/AVFoundationSPI.h
R Source/WebCore/PAL/pal/spi/ios/BrowserEngineKitSPI.h
M Source/WebKit/Platform/spi/ios/UIKitSPI.h
M Tools/TestRunnerShared/spi/UIKitSPIForTesting.h
Log Message:
-----------
Revert "Cherry-pick 5cdf58dba105. rdar://121706323"
This reverts commit 9952c70b8dc64278be024239d63f0e93b7edc55c.
Identifier: [email protected]
Commit: 9dac2ef3ce41b21cb27908703dd76410ae999e47
https://github.com/WebKit/WebKit/commit/9dac2ef3ce41b21cb27908703dd76410ae999e47
Author: Dan Robson <[email protected]>
Date: 2024-02-15 (Thu, 15 Feb 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-618.1.15.12.2
Identifier: [email protected]
Commit: ce155b8048b9f1e541a2302054f3fa4e0a6a3deb
https://github.com/WebKit/WebKit/commit/ce155b8048b9f1e541a2302054f3fa4e0a6a3deb
Author: Justin Michaud <[email protected]>
Date: 2024-02-15 (Thu, 15 Feb 2024)
Changed paths:
M Source/JavaScriptCore/Scripts/process-entitlements.sh
Log Message:
-----------
Cherry-pick 8179ae2db1bf. rdar://122826926
Clean up JSC shell entitlements to fix RAMificaton.
rdar://122826926
Reviewed by Yusuke Suzuki.
In https://commits.webkit.org/272448.472@safari-7618-branch, we switched
to the new allow-jit entitlement. This broke RAMiciation runs because
the JSC binary doesn't have the
com.apple.developer.web-browser-engine.webcontent
entitlement. This patch adds it.
* Source/JavaScriptCore/Scripts/process-entitlements.sh:
Canonical link: https://commits.webkit.org/272448.538@safari-7618-branch
Identifier: [email protected]
Compare: https://github.com/WebKit/WebKit/compare/e6a859812f68%5E...ce155b8048b9
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
