April 2025 - webkit-dev - lists.webkit.org

InjectedBundle deprecation
by Alex Christensen 01 Aug '25

01 Aug '25

Hello WebKit developers! We are ramping up to do some serious work on Site Isolation which includes putting cross-origin iframes in a different process than the parent frame. Similar efforts have been done in other browser engines and some related work has already been done in WebKit, but not enough. This will do strange things to the InjectedBundle APIs, which have fundamental assumptions that the whole DOM is in one process and that communication only happens with one process at a time. We have never exposed InjectedBundle APIs as public API, but some other distributors of WebKit have. As we make progress on this project, we anticipate that anything in Source/WebKit/WebProcess/InjectedBundle/API is subject to deprecation and removal. This will also allow us to tighten the sandbox on the web process, resolve security and performance issues, and have cleaner code. Would the maintainers of the GTK and WPE APIs be willing to assist in migrating from those APIs and designing replacements in the UI process? Alex Christensen

5 17

Site isolation
by Alex Christensen 01 Aug '25

01 Aug '25

The SiteIsolation feature is beginning to work in the simplest of cases, but I had to do some work in the Source/WebKit/Shared/RemoteLayerTree directory, which is platform-specific. Basically all the use of LayerHostingContextIdentifier in that directory needs an equivalent implementation for other graphics implementations, like in the CoordinatedGraphics directories. There is one layout test in LayoutTests/http/tests/site-isolation/basic-iframe.html that is currently skipped on all non-Cocoa platforms. Is someone willing to collaborate to design and implement the feature in non-Cocoa ports? We are in the early stages of the project and have a long way to go, so I imagine things will continue to come up, like deciding how to implement event handling and other platform dependent features. Alex

3 6

Questions about concurrent <video> playback restrictions on Mobile Safari.
by Yury Yarashevich 15 May '25

15 May '25

Hi WebKit team, I’m curious about the original rationale behind the restriction that prevents concurrent playback of multiple <video> elements. Was it primarily introduced to save battery life? In practice, this behavior appears to have unintended side effects. There’s a reproducible issue where playback can be started with the video muted and then immediately unmuted, effectively bypassing the restriction. However, this often results in videos being randomly paused later—sometimes very frequently—leading to a “play/pause ping-pong” between Safari/WebKit and JavaScript restarting playback. This erratic behavior may actually *increase* battery consumption, despite appearing to work smoothly from the user’s perspective. Even if this workaround is eventually blocked, developers who rely on concurrent playback (e.g., outside of WebRTC contexts) will turn to more complex solutions, such as decoding video and audio using WebCodecs or/and WebAssembly, and rendering via <canvas> and AudioContext. While technically feasible, these approaches are likely to be significantly less power-efficient than simply allowing multiple <video> elements to play concurrently. Another similarly inefficient workaround would be to synthesize a MediaStream using the VideoTrackGenerator API and AudioContext.createMediaStreamDestination(). Lastly, another issue is that creating a MediaElementSource from a <video> element and routing its audio through a shared AudioContext also does not disable the playback restriction—whereas it *is* disabled when the <video> element itself is muted. This feels inconsistent and may point to a separate bug. Could you please clarify the motivation behind this restriction, and whether there are any plans to revisit or improve its behavior? Thank you!

3 5

Newly introduced nice debugging helper function, `structDump`
by Yusuke Suzuki 07 Apr '25

07 Apr '25

Hello WebKittens, I've added a new debugging helper, `WTF::structDump` to JSC `dataLog` debugging helper families[1]. This leverages clang's `__builtin_dump_struct` function[2] and generates debugging-friendly struct-dump for *any* struct / class without having any special code to these classes. Use case is, for example, ``` DFG::Node* node = ...; dataLogLn(structDump(*node)); // Or any instances of your classes / structs ``` then, it automatically generates the output like this, ``` JSC::DFG::Node { NodeOrigin origin = *0x10631d800 NodeType m_op = 59 unsigned int m_index = 323 AdjacencyList children = *0x10631d818 VirtualRegister m_virtualRegister = *0x10631d830 unsigned int m_refCount = 1 NodeFlags m_flags = 344069 SpeculatedType m_prediction = 206158430208 OpInfoWrapper m_opInfo = *0x10631d848 OpInfoWrapper m_opInfo2 = *0x10631d850 union (unnamed) m_misc = { Node * replacement = 0x0 unsigned int epoch = 0 } BasicBlock * owner = 0x1061177b0 } ``` Currently, only clang supports this builtin. On GCC, we will just use pointerDump which dumps a pointer hex value. There is a feature request bug in GCC[3], and once it gets implemented, we can support GCC too. Happy hacking! Best regards, -Yusuke Suzuki [1]: https://github.com/WebKit/WebKit/commit/3c94ba6d70070d52a469c04ece16da7d0ed… [2]: https://clang.llvm.org/docs/LanguageExtensions.html#builtin-dump-struct [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83161

1 0

Coding style change proposal: Avoid using Objective C autorelease when possible
by Chris Dumez 05 Apr '25

05 Apr '25

Hi, I would like to propose updating the WebKit coding style to recommend avoiding autorelease in Objective C whenever possible, for the following reasons: - Performance reasons: - Cleaning up objects from all over the memory space in an autorelease pool can be slow and can cause memory spikes. - Memory Safety: - Holding a RetainPtr to the object makes lifetime clearer, whereas autorelease pool draining is not as clear and can result in use-after-free bugs. - Easier debugging: - Memory corruption bugs are harder to debug when it happens during autorelease pool drain. Concretely, this means writing code like this: ``` RetainPtr extensionDatabaseQueueName = adoptNS([[NSString alloc] initWithFormat:@"com.apple.WebKit.WKWebExtensionSQLiteStore.%@", _uniqueIdentifier]); String foo = “foo”_s; [object callWith:foo.createNSString().get()]; URL foo = “https://www.webkit.org”_s; [object callWith:foo.createNSURL().get()]; ``` Instead of: ``` NSString *extensionDatabaseQueueName = [NSString stringWithFormat:@"com.apple.WebKit.WKWebExtensionSQLiteStore.%@", _uniqueIdentifier]; RetainPtr extensionDatabaseQueueName = [NSString stringWithFormat:@"com.apple.WebKit.WKWebExtensionSQLiteStore.%@", _uniqueIdentifier]; String foo = “foo”_s; [object callWith:(NSString *)foo]; // This does autorelease internally. URL foo = “https://www.webkit.org”_s; [object callWith:(NSURL *)foo]; // This does autorelease internally. ``` Example PR: https://github.com/WebKit/WebKit/pull/43656 What do you think? Thanks, Chris Dumez.

2 1

Josh Hoffman is now a WebKit reviewer
by Tyler Wilcock 04 Apr '25

04 Apr '25

Hi all, I'm happy to announce that Josh Hoffman is now a WebKit reviewer! Josh is an accessibility expert, and has led the way in several significant WebKit accessibility efforts over the years. Congratulations Josh! Tyler

1 0