December 2023 - 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

Stricter type checking in downcast<>()
by Chris Dumez 20 Dec '23

20 Dec '23

Hi, I have recently landed stricter type checking in downcast<>() [1]. It is stricter because the check is now happening in release / production builds on some platforms (ARM-based). My objective is to enable to check in release on all platforms in the near future (still a small performance hit on remaining platforms at the moment). Because of this, it is now recommended to use dynamicDowncast<>() instead of is<>() + downcast<>(), to avoid duplicating the type check. dynamicDowncast<>() is also less error-prone and often results in more concise code. If you have a case where performance matters and you’re confident a type check is not required, you may rely on uncheckedDowncast<>(). uncheckedDowncast<>() behaves the same way downcast<>() used to before my change (type check on debug builds only). One such example I’ve seen in our codebase is when using a switch statement based on the type: ``` switch (node.nodeType()) { case Node::DOCUMENT_TYPE_NODE: uncheckedDowncast<DocumentType>(node)->foo(); ``` Please let me know if you have any concerns / questions. Cheers, Chris Dumez. [1] https://commits.webkit.org/272296@main

1 0

Patch WebKit to support custom Audio I/O handlers
by webkitdev＠duck.com 20 Dec '23

20 Dec '23

Dear Everyone! Currently, we are working on a project that aims to extend Selenium's functionality in regard to the Audio Input and Output, which Selenium currently does not support. The goal is to be able to provide custom audio input/output to an internal website, which we want to test automatically. For this, we are currently evaluating a rather complex approach involving using special Linux VMs and PulseAudio, thus rerouting the audio through the PulseAudio server. This approach is, of course, rather unsatisfying and error prone. Which is why we are thinking about forking WebKit and implementing a custom audio backend relaying the audio input and the audio output of the website to a custom handler. Which is why I want to ask: * I am a novice in the WebKit project, how would you suggest starting this task? * If we really were to go this route, would you be interested in an upstream patch or would you prefer a fork instead? * (off-topic) Are there any different approaches other than the two suggested above? Yours faithfully, Alexander

1 0

Patch WebKit to support custom Audio I/O handlers
by webkitdev＠duck.com 20 Dec '23

20 Dec '23

Dear Everyone! Currently, we are working on a project that aims to extend Selenium's functionality in regard to the Audio Input and Output, which Selenium currently does not support. The goal is to be able to provide custom audio input/output to an internal website, which we want to test automatically. For this, we are currently evaluating a rather complex approach involving using special Linux VMs and PulseAudio, thus rerouting the audio through the PulseAudio server. This approach is, of course, rather unsatisfying and error prone. Which is why we are thinking about forking WebKit and implementing a custom audio backend relaying the audio input and the audio output of the website to a custom handler. Which is why I want to ask: * I am a novice in the WebKit project, how would you suggest starting this task? * If we really were to go this route, would you be interested in an upstream patch or would you prefer a fork instead? * (off-topic) Are there any different approaches other than the two suggested above? Yours faithfully, Alexander

1 0

WPT import status
by Sam Sneddon 19 Dec '23

19 Dec '23

https://github.com/WebKit/WebKit/pull/21912 hopefully serves as good progress here: this PR is almost largely done by automated tooling. The first commit is the result of `import-w3c-tests` (the long standing command), but with no further work (to the expectations or baselines). It then ran through EWS with the `no-failure-limits` label, before I added a second commit: the output of `update-test-expectations github-pr`, albeit limited to only changes it made to the relevant (dom) directory. This is where all the baselines come from in the PR. This a roughly a workflow that’s useable in some cases today. The most obvious limitation is that it only deals with baseline files (*-expected.txt), and not TestExpectations files (which means for things where the result is stored there—including reftest failures, debug differences, timeouts and crashes—it doesn’t work). Of the limitations this causes, reftests are by far the more apparent and mean this doesn’t work for most CSS tests yet. The other obvious limitation is that it doesn’t deal with flaky tests, as shown by the PR failing after the second commit. The final limitation, hinted at above, is that this doesn’t take any consideration of the current results on main—so it rebaselines far too much, depending on how well gardened main is when the PR run. That said, the first and last of these are very much things we care about fixing, and we’ll see how problematic the second requiring manual intervention is. I’d encourage people importing directories which have few reftests to try using the scripts mentioned above, and file any bugs they find. What would be super helpful, to avoid making “turn on automated import” too painful, is updating directories we have imported that haven’t been updated recently. And finally, as an aside, the `import-expectations.json` file now explicitly skips every top level directory we don’t import: I’d encourage you to take a look at what’s marked as skip, and if there’s more you think we should be importing (especially because we have implemented the spec in question!), I’d encourage you to do so by running `import-w3c-tests` with that directory, which will also change the relevant line in `import-expectations.json` from “skip” to “import”. Happy New Year, (Web)Kittens, Sam PS: Apparently I messed up and my original draft with many more links to bugs didn’t get saved to a server-side draft mailbox, and I’m now on vacation, so please accept this much less-useful-than-intended email on current WPT import work! (I’ll try to reply with all the links once I get home in the New Year, although I will remain on leave for a while beyond.)

2 1

webkit-unassigned
by Alexey Proskuryakov 18 Dec '23

18 Dec '23

Hello, Does anybody make use of the webkit-unassigned mailing list? I'd like to disable it, to reduce exposure of spam and accidental postings. - Alexey

3 9

Meaning of '7' in WebKit Versioning
by 강수진 18 Dec '23

18 Dec '23

Meaning of '7' in WebKit Versioning Hello, I have a question about the versioning rules in WebKit. I am aware that the version of WebKit used varies based on the iOS version. For example, in iOS 17.0, the WebKit framework's WebKit.tbd file shows the current version as 616.1.27, while in iOS 16.4, it's 615.1.26. When I checked the corresponding source for each version on WebKit's GitHub, I noticed that the tags for these versions are labeled as WebKit-7616.1.20. Upon inspecting Version.xcconfig, I found that 616.1.20 represents the Major, Minor, and Tiny versions, respectively. However, I couldn't determine the significance of '7'. I speculated that '7' might represent the SYSTEM_VERSION_PREFIX since BUNDLE_VERSION_Production is set to $(SYSTEM_VERSION_PREFIX)$(FULL_VERSION); in the same file. But considering the system version prefix for iPhone SDK is set to 8, '7' couldn't denote that. After some research, I found that '7' signifies the release year of Mac OS 10.7 (Lion), which was launched in 2011. Could you please clarify the meaning of '7' in tags like WebKit-7616.1.20?

2 2