Branch: refs/heads/safari-7618.1.15.13-branch
Home: https://github.com/WebKit/WebKit
Commit: ef0ad7f8ee466c153e3b22b355c8975144ffd7ef
https://github.com/WebKit/WebKit/commit/ef0ad7f8ee466c153e3b22b355c8975144ffd7ef
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.13.1
Identifier: [email protected]
Commit: e8b983d71be87010079e26e448de1fb52dfc03c8
https://github.com/WebKit/WebKit/commit/e8b983d71be87010079e26e448de1fb52dfc03c8
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: bfdf50754050c294ccfb3ed4ed46d99a7ba06b4f
https://github.com/WebKit/WebKit/commit/bfdf50754050c294ccfb3ed4ed46d99a7ba06b4f
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: a666863e2773f8d067f4d8b5a85679d7aa57d80e
https://github.com/WebKit/WebKit/commit/a666863e2773f8d067f4d8b5a85679d7aa57d80e
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: 846891e52c8fe0ddf23e4443ce2faa8fdaede93e
https://github.com/WebKit/WebKit/commit/846891e52c8fe0ddf23e4443ce2faa8fdaede93e
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 a666863e2773f8d067f4d8b5a85679d7aa57d80e.
Identifier: [email protected]
Commit: 890ade78f88b5e462f8f1dee0cd56acaa4c86f22
https://github.com/WebKit/WebKit/commit/890ade78f88b5e462f8f1dee0cd56acaa4c86f22
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.13.2
Identifier: [email protected]
Commit: f3114daa88af2233557055b1c6527d468f41c1d1
https://github.com/WebKit/WebKit/commit/f3114daa88af2233557055b1c6527d468f41c1d1
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/ef0ad7f8ee46%5E...f3114daa88af
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
