May 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

PSA: some WebKit project “pulse” activity metrics
by sideshowbarker 27 May '24

27 May '24

Some links with data and charts showing project commit/PR activity metrics: - https://git-pulse.github.io/snapshots/?project=WebKit_WebKit - https://git-pulse.github.io/snapshots/WebKit-WebKit-2024-05-26-pulse.html >From those, some “good” metrics for the project that particularly stand out: - 1123 PRs merged per month (3rd highest) - 1224 commits per month (6th highest) - 130 unique committers per month (9th highest) - 9.42 commits per committer (on average) per month (9th highest) Those are averages over the last 12 months. And the rankings are relative to the 78 other extremely-high-activity projects tracked by this tool. The only two projects that have more PRs merged per month are the Homebrew project repos — but their PR numbers are so ridiculously higher than all other projects that they’re essentially in a class by themselves. https://git-pulse.github.io/snapshots/WebKit-WebKit-2024-05-26-pulse.html is a report that has the specific per-month numbers (rather than just averages) for the project — along with some charts of the data. ----------------------------------------------------------------------- Caveat: I created the tool used for generating all this stuff, and you can find the source at https://github.com/git-pulse/tools — and if you want to, you can run it yourself locally in your WebKit repo, like this: curl -fsSLO https://git-pulse.github.io/tools/git-pulse && bash ./git-pulse (That generates output to the shell/terminal while it’s running, and then generates HTML output when it’s done. And due to GitHub API throttling, it takes a while — maybe 5 minutes or more — to run to completion.) Caveat: In general the numbers this tool ends up generating seem accurate — but I’m not a statistician and there may be some bugs in calculations I have it using to generate its numbers. ----------------------------------------------------------------------- And finally, some maybe-not-as-good metrics that stand out: - open PRs: 946 (2nd highest) - rate at which number of open PRs is increasing: 33 per month (#1 highest) The only other project with more open PRs is the Web Platform Tests (WPT) project — and statistically speaking, it’s almost the same: 957. And beyond the fact that the rate at which the number of open PRs for the WebKit project is highest among all 78 projects tracked by this tool — it’s also increasing at nearly _twice_ the rate as the project with the next-highest rate of increase (which is “only” 17 per month). Among all the projects tracked, the _average_ rate of increase in open PRs each month is zero — and almost 20 of the other projects actually have a _decrease_ in the number of open PRs per month. The WPT project — which has the highest number of open PRs — actually also has the highest decrease in open PRs per month: It’s closing 15 more PRs per month than are being opened each month — vs the WebKit project gaining 33 new PRs per month (and over the last year, gaining 429 unclosed PRs in total). I’m not stating those numbers as any kind of criticism or sign of anything that necessarily needs fixing — I’m just noting how much those numbers stand out relative to those of some other projects. And again, see the caveat above: I’m not a statistician — and to the degree that any of these numbers actually mean anything at all, I’m anyway personally not qualified to offer any useful analysis on them from any kind of actually-informed point of view. -- https://sideshowbarker.net/

1 0

Removing webkit-tools-completion.sh
by Jonathan Bedard 14 May '24

14 May '24

I’m working on unwinding Subversion support in WebKit. There is an old script, webkit-tools-completion.sh, which references various old scripts (namely, webkit-patch). Is anyone using this script or should we remove it? Pull-request in question is https://github.com/WebKit/WebKit/pull/28536. Thanks for your thoughts, Jonathan Bedard WebKit Continuous Integration

1 0

WebXR support timeline?
by Wladislav Artsimovich 14 May '24

14 May '24

Dear WebKit Devs, I'm deep in a WebXR project and am super excited about the potential this standard brings. I was a bit sad to see, that Webkit and by extension Apple's iOS & iPadOS Safari does not support it. Recently Safari on VisionOS launched support for WebXR, whereas Webkit and thus Safari on iOS does not. With https://bugs.webkit.org/show_bug.cgi?id=208988 being stalled, are there news? Is there a potential timeline? Is there lack of manpower and could I help out in remaining tasks? Best regards, Vlad

1 0

Proposal: Dropping MSVC support and use clang-cl exclusively on Windows
by Herb Sutter 08 May '24

08 May '24

Hi! Herb here from the MSVC team. It makes total sense to use the right compiler for the job and prune unused configs (and it sounds like no one is relying on building with MSVC, correct?). I just wanted to ask about this part, in case there were things we could do better: > 1. MSVC does not support various C++20 features, so it is putting our C++20 adoption much behind (For example, we cannot use concept). By using clang-cl, we can start much newer set of C++20 features, improving code quality, static checks etc. We’ve had full C++20 including concepts for a couple of years so I wasn’t sure what problem you were running into… are you encountering bugs in those features? or you can’t turn on /std:c++20 for some reason? or are you using an older pre-concepts (pre-VS2022 17.0) compiler? Thanks for any feedback you have time to share. Herb _____ +1 Cheers, Keith > On Apr 30, 2024, at 10:06 AM, Yusuke Suzuki via webkit-dev <webkit-dev at lists.webkit.org <https://lists.webkit.org/mailman/listinfo/webkit-dev> > wrote: > > Hello WebKittens! > > Right now, MSVC support is putting significant burden on JavaScriptCore. It lacks many features for JSC development, > as a result, we have so many workarounds for MSVC in JavaScriptCore (For example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot compile it reasonably). > > I talked with JSC team and Don at Sony, and now I would like to propose dropping MSVC support on Windows port and using clang-cl exclusively on Windows. > > There are many motivating factors for this change. > > 1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there is zero test coverage on MSVC build right now. > 2. On the other hand, EWS is using MSVC for build test. This discrepancy is making maintenance of Windows ports harder and harder. > 3. MSVC has various compilation issues which makes JSC lesser quality. Lack of `__builtin_frame_address` support makes JSC bloating JIT code much. CheckedArith has bunch of special code due to lack of overflow-detecting `__builtin_add_overflow` like operations, and so on. (but TBH, given there is zero coverage, we even don't know whether it is working right now!) > 4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are using clang-cl, not MSVC. > > Not only solving existing issues, using clang-cl opens significant code / implementation quality improvements opportunities for Windows. > > 1. MSVC does not support various C++20 features, so it is putting our C++20 adoption much behind (For example, we cannot use concept). By using clang-cl, we can start much newer set of C++20 features, improving code quality, static checks etc. > 2. This paves a way to make Windows JSC implementation super solid. clang-cl offers sysv-abi feature for function attributes. This allows using Linux / macOS amd64 ABI on certain annotated functions. This basically means that we potentially unify our interpreter and JIT implementations completely in Linux / macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super solid, plus, it paves a way to fully enable all JIT tiers on Windows including FTL). > > We already discussed with Don and we agreed on this. > And now I would like to formally propose MSVC deprecation towards more cleaner and solid Windows port. > > Best regards, > -Yusuke Suzuki > _______________________________________________ > webkit-dev mailing list > webkit-dev at lists.webkit.org <https://lists.webkit.org/mailman/listinfo/webkit-dev> > https://lists.webkit.org/mailman/listinfo/webkit-dev

5 6

RFC: Improving “RefPtr inside destructor” checking
by Geoff Garen 03 May '24

03 May '24

It’s a use-after-free error to create a RefPtr<T> during ~T(), and have that RefPtr live past the end of ~T(). In debug builds, we try to catch this error by eagerly assertion !T::m_deletionHasBegun in the RefPtr<T> constructor. At the same time, our smart pointer rules sometimes require us to use RefPtr<T> inside functions that are reachable from destructors. To suppress the assertion in these cases, we use RefPtrAllowingPartiallyDestroyed<T>. Problems I see with the current approach: * We don’t do any checking in release builds * RefPtrAllowingPartiallyDestroyed<T> complicates our smart pointer rules, when we want them to be simple I’d like to improve this situation. Enable checking in release builds There are two ways we can check in release builds without adding overhead. Option 1: deref() checks for outstanding pointers after running ~T(), and if there are some, crashes eagerly. We did not like this behavior in CheckedPtr<T>. It produced crash backtraces where we simply didn’t know what pointer had lived to long, or which code had made a mistake. But RefPtr<T> is different. If Option 1 crashes, we know that the error of escaping a pointer after destruction happened inside the destructor that is crashing (or one of its callees). So maybe we have enough information to go on. Option 2: Scribble and leak the object, and crash later, just like CheckedPtr. Option 2 has the upside that the crashing backtrace will usually point directly to the errant pointer. Option 2 seems fine too, but it has the downside that, if you escape a pointer in the destructor, and then make more pointers after the destructor, the pointer that ultimately crashes may be far removed from the pointer the originally escaped. Any strong preferences, or should I just try something? Remove RefPtrAllowingPartiallyDestroyed<T> and the debug-only !T::m_deletionHasBegun check. Once we have a form of checking that works in release builds, the existing debug-only assertion is arguably redundant. Getting rid of it and getting rid of RefPtrAllowingPartiallyDestroyed<T> can simplify our smart pointer rules. One downside to removing RefPtrAllowingPartiallyDestroyed<T> it that it can be nice during code review to enforce a discipline that RefPtrAllowingPartiallyDestroyed<T> should only be used on the stack. (This discipline is pretty obvious in a lot of cases, but not all — see WebCore::HTMLMediaElement::speakCueText and WebCore:: MediaSource::ensureWeakOnHTMLMediaElementContext.) Any strong preferences, or should I just try something? Thanks, Geoff

1 0