November 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

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

Re: [webkit-dev] Approving / Rejects PRs on GitHub when not a reviewer?
by Jonathan Bedard 29 Nov '23

29 Nov '23

> Hi, > > Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. Non-reviewers were - of course - encouraged to do informal reviews but they would do so by leaving comments. They would never r+ / r-. > > Since we?ve moved to Github, it seems we have become a lot more lax about this and I have seen non-reviewers approve and reject PRs, not just leaving comments. > My understanding is that there is no way to prevent this with Github but could we at least make it a policy that non-reviewers should not approve / reject PRs and only leave comments instead? To provide some context, one of the reasons I didn’t attempt to exactly replicate Bugzilla’s behavior when porting our review mechanisms to GitHub was that Bugzilla only allows a single reviewer, which meant that an r+ would naturally clobber an r-, regardless of who gave the r- initially. Even in Bugzilla, non-reviewers could give r+es or r-es, it’s just that Commit-Queue wouldn’t respect them. > The reason I would like us to make enforce this rule is that I find it confusing. We have a lot of new comers in the project and I do not always know if a person is a reviewer or not yet. I imagine it may be even more confusing for non-Apple people. I agree with this, especially since folks GitHub usernames are not always obvious. > I have in some cases not reviewed patches because I had seen the "green check? and thought the PR already had been approved. > I have also seen cases of PRs rejected, asking the author to do more work, that I didn?t feel was necessary. > There is no easy way from the GitHub UI to tell if the person who approved/rejected your PR is actually a reviewer, as far as I know. I think it’s fair for a non-reviewer to “Request Changes” on a PR, it’s often the case that a non-reviewer has comments that should block a change from landing. If a reviewer (or even the PR author) thinks that the blocking comment has been addressed, they can “re-request review” which will get-rid of symbol until the account whose review is requested re-reviews the PR. I think this also points to the right way to address the confusion for r+es (which I think are the bigger issue): if we formally make our policy that non-reviewers should not leave a persistent “Approved” checkmark on a PR, we could have EWS listen for PR approvals and simply request a re-review any time a non-reviewer approves a PR. In practice, this will mean that a non-reviewer which approves a PR will have their approval nearly instantly removed by a bot. We could even have the bot comment something like “Unofficial r+ from non-reviewer <github user>” to make exactly what’s going on clear. The issue with a policy change like this one is that it’s WebKit reviewers who deeply understand the policies of the WebKit project, but it’s non-reviewers who need to change their behavior. If we don’t back this policy clarification with a tools change, I think non-reviewers are unlikely to be aware project policy has changed. > > What do you think? > > Thanks, > Chris Dumez.

6 7

Approving / Rejects PRs on GitHub when not a reviewer?
by Chris Dumez 28 Nov '23

28 Nov '23

Hi, Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. Non-reviewers were - of course - encouraged to do informal reviews but they would do so by leaving comments. They would never r+ / r-. Since we’ve moved to Github, it seems we have become a lot more lax about this and I have seen non-reviewers approve and reject PRs, not just leaving comments. My understanding is that there is no way to prevent this with Github but could we at least make it a policy that non-reviewers should not approve / reject PRs and only leave comments instead? The reason I would like us to make enforce this rule is that I find it confusing. We have a lot of new comers in the project and I do not always know if a person is a reviewer or not yet. I imagine it may be even more confusing for non-Apple people. I have in some cases not reviewed patches because I had seen the "green check” and thought the PR already had been approved. I have also seen cases of PRs rejected, asking the author to do more work, that I didn’t feel was necessary. There is no easy way from the GitHub UI to tell if the person who approved/rejected your PR is actually a reviewer, as far as I know. What do you think? Thanks, Chris Dumez.

6 6

Web Authn support for webkitgtk
by ChandraSekharVarma Dasaraju 10 Nov '23

10 Nov '23

Hi , Are there any plans to enable Web Authn support for webkitgtk ? I see below bug is submitted but not sure if there is any work going on or not ? https://bugs.webkit.org/show_bug.cgi?id=205350 Thanks for your help. Thanks, DCS varma

2 1