October 2024 - 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

Site isolation platform code
by Alex Christensen 14 Jan '25

14 Jan '25

Hey everyone! I’ve been doing a bunch of work on site isolation recently, and I’ve been doing my best to make all my changes platform-independent so it just works for everyone. However, there are two places I could use some collaboration with other WebKit developers: 1. createNewPage in WebKitUIClient.cpp needs some hooking up of the API::PageConfiguration in a way I couldn’t figure out in the few minutes I looked at it. This should be pretty straightforward to someone who knows the glib code better than I do. 2. We have a growing number of tests in LayoutTests/http/tests/site-isolation that exercise drawing code, which will take a significant amount of work to get implemented on non-Cocoa platforms. A lot of changes are happening in this area right now with the adoption of Skia, and it would be great if it were done in a way that could support site isolation. Thanks, Alex

2 2

Naming scheme for fooIfExists/ensureFoo - Round 2
by Ryosuke Niwa 08 Jan '25

08 Jan '25

Hi all, We discussed this topic 11 years ago in https://lists.webkit.org/pipermail/webkit-dev/2013-June/025056.html but we seem to have never codified it in our coding style guideline. It really bothers me that we have a mixture of two styles so I’d like to propose that we pick one style and put that into style guideline & style checker. The question is as follows. A pair of functions which lazily construct an object and one which returns nullptr if the object had not already been constructed can be named: StyleResolver* styleResolver(); StyleResolver& ensureStyleResolver(); or: StyleResolver* styleResolverIfExists(); StyleResolver& styleResolver(); Which one should we use? - R. Niwa

7 7

Set once pointer types and static analysis
by Ryosuke Niwa 13 Nov '24

13 Nov '24

Hi all, In WebKit, it’s fairly common to write a member variable as RefPtr or std::unique_ptr that later gets lazily initialized to some value but never unset or assigned of a different value after that. e.g. class Foo { Bar& bar() { if (!m_bar) m_bar = Bar::create(); return *m_bar; } Ref<Bar> protectedBar() { return bar(); } RefPtr<Bar> m_bar; } Assuming there is no other code modifying m_bar, foo->bar()->method() is always safe to call even if method wasn’t a trivial function. Right now, static analyzer doesn’t recognize this pattern so we’d be forced to write code like this: foo->protectedBar()->method() where ensureProtectedBar is a wrapper around ensureBar which returns Ref<Bar>. A suggestion was made that static analyzer can recognize this patten. Specifically, if we introduced a new smart pointer types that only allow setting the value once, static analyzer can allow foo->bar()->method()and avoid ref-churn in some cases: e.g. class Foo { Bar& bar() { if (!m_bar) m_bar = Bar::create(); return *m_bar; } SetOnceRefPtr<Bar> m_bar; } SetOnceRefPtr::operator=(T*) release asserts that m_ptr isn’t set, and doesn’t have a move constructor, operator=(nullptr_t), leakRef(), releaseNonNull(), etc… which can override the value of m_ptr after setting the value via operator= or in constructor. We could create various variants: SetOnceRef, SetOnceUniquePtr, SetOnceUniqueRef. Do you think this will be useful? - R. Niwa

5 9

Proposal: bundled/vendored code belongs under ThirdParty/
by Michael Catanzaro 07 Oct '24

07 Oct '24

Hi developers, I request that bundled or "vendored" sources copied from other upstream projects should live under a directory named "ThirdParty" so we can keep track of it. Not knowing about bundled sources causes various problems, e.g. we've previously shipped unused libavif and dav1d sources in WebCore due to not knowing about them. Ideally third-party code should be placed in Source/ThirdParty. If the requirements of Apple's internal build system do not allow for putting the code in Source/ThirdParty, then you can create a new ThirdParty directory wherever needed, e.g. Source/WebCore/PAL/ThirdParty. Currently we have at least wtf/simde and wtf/simdutf violating these guidelines. If somebody with XCode could please create a wtf/ThirdParty and move the directories to there, that would be helpful. Unfortunately it's not easy to move sources without XCode. If you know of other bundled sources elsewhere in WebKit, let's do the similar moves for those as well. (This rule doesn't need to apply for minimal one-time copying, like taking just a useful file or two from an upstream project and incorporating it into WebKit. Of course that is fine. We just shouldn't have entire upstream projects hidden in WebKit.) Thanks, Michael

3 4

Initializing member variables
by Ryosuke Niwa 03 Oct '24

03 Oct '24

Should we do: struct Foo { int bar = 0; } Or struct Foo { int bar { 0 }; } We do both at the moment. - R. Niwa

7 8

Introducing the Safer CPP Checks Queue
by Brianna Fan 03 Oct '24

03 Oct '24

Hi all, As of this morning, the macOS-Safer-CPP-Checks-EWS <https://ews-build.webkit.org/#/builders/120> queue is live! It reports unexpected bugs caught by WebKit's smart pointer checkers. You'll see the results reflected on your PR status bubbles. Currently, this queue does not block merging as we monitor results and performance for a couple weeks. Resources: WebKit Guidelines for Safer C++ Programming <https://github.com/WebKit/WebKit/wiki/Safer-CPP-Guidelines> Expectations for each checker are located in `Source/[Webkit|WebCore]/SaferCPPExpectations` If your PR contains a fix: Use `Tools/Scripts/update-safer-cpp-expectations` to update expectations automatically using unexpected results generated from each build. Thank you for supporting WebKit's memory safety efforts and keeping these checks green! Cheers, Brianna F

1 0

Re: [webkit-dev] Proposal: bundled/vendored code belongs under ThirdParty/
by Michael Catanzaro 01 Oct '24

01 Oct '24

Thanks. On Tue, Oct 1 2024 at 10:08:35 AM -04:00:00, Sam Weinig <weinig(a)icloud.com> wrote: > Having a single place seems more straightforward than multiple. Are > there technical reasons this can’t be done? Are there non-technical > reasons it shouldn’t be done? I understand the sources in PAL are there due to special requirements of Apple's internal build system. Perhaps the same applies for WTF? > Are there technical / non-technical reasons (other than the obvious > effort it would require) why this would be a problem? When operating systems build WebKitGTK, they do so in isolated environments without access to the internet. So all the third-party code that's not an external system dependency has to go into our tarballs somehow; downloading it at build time will not work. Copying it into the source tree as we do now is probably easiest, though it could also be done when creating release tarballs. Michael

1 0