April 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

Proposal: Dropping MSVC support and use clang-cl exclusively on Windows
by Yusuke Suzuki 30 Apr '24

30 Apr '24

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

2 1

Re: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build on Mac
by Steve Glass 25 Apr '24

25 Apr '24

Hi, Hi, I’m trying to build jsc on my M1 Mac following the instructions at > https://trac.webkit.org/wiki/JSCOnly and https://webkit > .org/getting-started/ . > However when I run the built binary it exits immediately with a bus error > which lldb shows to be EXC_BAD_ACCESS. I'm also trying to build JSC on my M1 Mac and my experience is the *exact* same error as Laurence has reported above. When I run I get a bus error at the same location in the code: [27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug > lldb WebKitBuild/JSCOnly/Debug/bin/jsc > (lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc" > Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' > (arm64). > (lldb) target create Web > Available completions: > WebKitBuild/ > WebDriverTests/ > WebKit.xcworkspace/ > WebKitLibraries/ > Websites/ > (lldb) target create WebKitBuild/JSCOnly/Debug/b > Available completions: > WebKitBuild/JSCOnly/Debug/bmalloc/ > WebKitBuild/JSCOnly/Debug/bin/ > WebKitBuild/JSCOnly/Debug/build-webkit-options.txt > (lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc > Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' > (arm64). > (lldb) run > Process 86562 launched: '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' > (arm64) > Process 86562 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS > (code=2, address=0x133804000) > frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove > + 168 > libsystem_platform.dylib`: > -> 0x18696f248 <+168>: stp q2, q3, [x0] > 0x18696f24c <+172>: subs x2, x2, #0x40 > 0x18696f250 <+176>: b.ls 0x18696f26c ; <+204> > 0x18696f254 <+180>: stp q0, q1, [x3] > Target 1: (jsc) stopped. > This is what 'image list' reports at this point: > (lldb) image list > [ 0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0000000100000000 > /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc > [ 1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x00000001865b0000 > /usr/lib/dyld > [ 2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x000000010781c000 > /Users/stevie/git/WebKit > /WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore > [ 3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x00000001d1096000 > /usr/lib/libedit.3.dylib > [ 4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x00000001b06d7000 > /usr/lib/libncurses.5.4.dylib > [ 5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x00000001935ae000 > /usr/lib/libSystem.B.dylib > [ 6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x00000001935a8000 > /usr/lib/system/libcache.dylib > [ 7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x0000000193563000 > /usr/lib/system/libcommonCrypto.dylib > [ 8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x000000019358f000 > /usr/lib/system/libcompiler_rt.dylib > [ 9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x0000000193585000 > /usr/lib/system/libcopyfile.dylib > [ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x00000001866a4000 > /usr/lib/system/libcorecrypto.dylib > [ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x000000018678a000 > /usr/lib/system/libdispatch.dylib > [ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x0000000186945000 > /usr/lib/system/libdyld.dylib > [ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x000000019359e000 > /usr/lib/system/libkeymgr.dylib > [ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x000000019353b000 > /usr/lib/system/libmacho.dylib > [ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x0000000192a1c000 > /usr/lib/system/libquarantine.dylib > [ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x000000019359b000 > /usr/lib/system/libremovefile.dylib > [ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x000000018c0bc000 > /usr/lib/system/libsystem_asl.dylib > [ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x0000000186639000 > /usr/lib/system/libsystem_blocks.dylib > [ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x00000001867d5000 > /usr/lib/system/libsystem_c.dylib > [ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x0000000193593000 > /usr/lib/system/libsystem_collections.dylib > [ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x0000000191bf6000 > /usr/lib/system/libsystem_configuration.dylib > [ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x0000000190c34000 > /usr/lib/system/libsystem_containermanager.dylib > [ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x00000001931d2000 > /usr/lib/system/libsystem_coreservices.dylib > [ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x0000000189d5b000 > /usr/lib/system/libsystem_darwin.dylib > [ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x000000024d32a000 > /usr/lib/system/libsystem_darwindirectory.dylib > [ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x000000019359f000 > /usr/lib/system/libsystem_dnssd.dylib > [ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x000000024d32e000 > /usr/lib/system/libsystem_eligibility.dylib > [ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x00000001867d2000 > /usr/lib/system/libsystem_featureflags.dylib > [ 29] 615EAFA2-4446-3994-89E9-858A0552F1B8 0x0000000186973000 > /usr/lib/system/libsystem_info.dylib > [ 30] 9735ABAE-2939-30EB-90D4-C6F23F795B2F 0x0000000193500000 > /usr/lib/system/libsystem_m.dylib > [ 31] B36EAAD5-558D-39E8-AB0D-FD87F2EF154B 0x000000018674d000 > /usr/lib/system/libsystem_malloc.dylib > [ 32] EBACF63D-8B18-37FF-8952-85FD99605BD7 0x000000018c02a000 > /usr/lib/system/libsystem_networkextension.dylib > [ 33] EDCEB984-2FC8-3EB5-9016-3453A3DDEE8F 0x000000018a1d1000 > /usr/lib/system/libsystem_notify.dylib > [ 34] 2F95044C-6CEF-3731-B1B9-F7D6A51B3A3F 0x0000000191bfb000 > /usr/lib/system/libsystem_sandbox.dylib > [ 35] EEA82D78-5036-3A22-8DC6-4E131A57941B 0x000000024d332000 > /usr/lib/system/libsystem_sanitizers.dylib > [ 36] 11D0DCC2-FC9F-3E2C-B2CF-0662E64DC96D 0x0000000193598000 > /usr/lib/system/libsystem_secinit.dylib > [ 37] 2A91FD2C-4CEF-3211-A025-7A1C0A8C2DB5 0x00000001868fd000 > /usr/lib/system/libsystem_kernel.dylib > [ 38] 031F3E8C-5227-3138-A444-68174C1C28CF 0x000000018696b000 > /usr/lib/system/libsystem_platform.dylib > [ 39] 45239F06-CC53-36D0-9933-7776AC7EA2FA 0x0000000186938000 > /usr/lib/system/libsystem_pthread.dylib > [ 40] 372ACDF1-29E7-34DA-B035-BD7671EB5A8B 0x000000018daaa000 > /usr/lib/system/libsystem_symptoms.dylib > [ 41] 681EBF40-B321-364A-88EA-04AB45E3DA66 0x0000000186689000 > /usr/lib/system/libsystem_trace.dylib > [ 42] 31BBAE83-7FFD-30A6-8BFC-6D5D17A6CC82 0x0000000193571000 > /usr/lib/system/libunwind.dylib > [ 43] C43D5322-9B69-37EE-B51E-45FDE5D81B5B 0x000000018663e000 > /usr/lib/system/libxpc.dylib > [ 44] 4FED965B-18AD-3A4F-8928-1F0A3C35345F 0x00000001868e1000 > /usr/lib/libc++abi.dylib > [ 45] 76C8305C-4066-390C-8F3E-F0858D756AD8 0x0000000186560000 > /usr/lib/libobjc.A.dylib > [ 46] 3FE71C4F-17CC-3B93-AE29-05CE7D116F1B 0x000000019357d000 > /usr/lib/liboah.dylib > [ 47] 08C4329E-407F-310B-B037-75A8020B2963 0x0000000186854000 > /usr/lib/libc++.1.dylib > [ 48] 50DE7E22-A040-3E0F-836E-BEF36B36EC01 0x0000000189a94000 > /usr/lib/libicucore.A.dylib > (lldb) ...and the backtrace at the point of crash looks like this: (lldb) bt > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS > (code=2, address=0x133804000) > * frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove > + 168 > frame #1: 0x000000010798f984 JavaScriptCore`JSC::performJITMemcpy(dst=0x0000000133804000, > src=0x00000001010300c0, n=64) at ExecutableAllocator.h:147:12 > frame #2: 0x000000010797ef60 JavaScriptCore`void > JSC::LinkBuffer::copyCompactAndLinkCode<unsigned > int>(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, > effort=JITCompilationMustSucceed) at LinkBuffer.cpp:433:9 > frame #3: 0x000000010797e1c4 JavaScriptCore`JSC::LinkBuffer::linkCode(this=0x000000016fdfeb60, > macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at > LinkBuffer.cpp:475:5 > frame #4: 0x00000001079bee10 JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60, > macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff, > profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:117:9 > frame #5: 0x0000000108a0c29c JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60, > macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff, > profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:116:5 > frame #6: 0x0000000108ec280c JavaScriptCore`JSC::LLInt::defaultCallThunk()::$_14::operator()(this=0x000000016fdfef17) > const at LLIntThunks.cpp:340:20 > frame #7: 0x0000000108ec2718 JavaScriptCore`decltype(std::declval<JSC::LLInt::defaultCallThunk()::$_14>()()) > std::__1::__invoke[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__f=0x000000016fdfef17) > at invoke.h:340:25 > frame #8: 0x0000000108ec26f4 JavaScriptCore`void > std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::__execute[abi:un170006]<>(this=0x000000016fdfeed0, > (null)=__tuple_indices<> @ 0x000000016fdfee2f) at mutex:632:9 > frame #9: 0x0000000108ec26c8 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::operator()[abi:un170006](this=0x000000016fdfeed0) > at mutex:624:9 > frame #10: 0x0000000108ec25c8 JavaScriptCore`void > std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>(__vp=0x000000016fdfeed0) > at mutex:660:5 > frame #11: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned > long volatile&, void*, void (*)(void*)) + 180 > frame #12: 0x0000000108eb4ce0 JavaScriptCore`void > std::__1::call_once[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__flag=0x000000010ae2af68, > __func=0x000000016fdfef17) at mutex:677:9 > frame #13: 0x0000000108e9b704 JavaScriptCore`JSC::LLInt::defaultCallThunk() > at LLIntThunks.cpp:309:5 > frame #14: 0x0000000108e9a9b8 JavaScriptCore`JSC::LLInt::defaultCall() > at LLIntEntrypoint.cpp:198:16 > frame #15: 0x0000000108e9a87c JavaScriptCore`JSC::LLInt::initialize() > at LLIntData.cpp:264:36 > frame #16: 0x00000001091ba7b8 JavaScriptCore`JSC::initialize()::$_12::operator()(this=0x000000016fdff0ff) > const at InitializeThreading.cpp:121:9 > frame #17: 0x00000001091ba6c0 JavaScriptCore`decltype(std::declval<JSC::initialize()::$_12>()()) > std::__1::__invoke[abi:un170006]<JSC::initialize()::$_12>(__f=0x000000016fdff0ff) > at invoke.h:340:25 > frame #18: 0x00000001091ba69c JavaScriptCore`void > std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::__execute[abi:un170006]<>(this=0x000000016fdff0c0, > (null)=__tuple_indices<> @ 0x000000016fdff01f) at mutex:632:9 > frame #19: 0x00000001091ba670 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::operator()[abi:un170006](this=0x000000016fdff0c0) > at mutex:624:9 > frame #20: 0x00000001091ba570 JavaScriptCore`void > std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::initialize()::$_12&&>>(__vp=0x000000016fdff0c0) > at mutex:660:5 > frame #21: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned > long volatile&, void*, void (*)(void*)) + 180 > frame #22: 0x0000000109191860 JavaScriptCore`void > std::__1::call_once[abi:un170006]<JSC::initialize()::$_12>(__flag=0x000000010ae2b7f0, > __func=0x000000016fdff0ff) at mutex:677:9 > frame #23: 0x00000001091917f4 JavaScriptCore`JSC::initialize() at > InitializeThreading.cpp:73:5 > frame #24: 0x000000010000987c jsc`jscmain(argc=1, > argv=0x000000016fdff440) at jsc.cpp:4361:5 > frame #25: 0x0000000100009680 jsc`main(argc=1, > argv=0x000000016fdff440) at jsc.cpp:3541:15 > frame #26: 0x00000001865b60e0 dyld`start + 2360 > (lldb) My software versions are different to those reported by Laurence: Versions: - WebKit main (9dc3f9d6339) - Xcode 15.3 (15E204a) - macOS 14.4.1 - CMake.app 3.24.4 I run the tests for JSC using 'Tools/Scripts/run-javascriptcore-tests --jsc-only --debug --no-build --no-fail-fast' and it is reporting bus errors everywhere. I've tried pulling newer versions of webkit but this error has persisted for the last couple of weeks. Thanks Steve

3 3

Sam Sneddon is now a WebKit Reviewer
by Jonathan Bedard 23 Apr '24

23 Apr '24

Hello folks, I am happy to announce that Sam Sneddon is now a WebKit Reviewer! Sam is an expert in Web Platform Tests and our tooling to run layout tests, along with Python in general. Jonathan Bedard

1 0

Lost docs!
by Michael Catanzaro 08 Apr '24

08 Apr '24

Hi, I've noticed we have a bunch of documentation on https://github.com/WebKit/WebKit/wiki that has not been migrated to https://docs.webkit.org/index.html. Some of the documentation looks pretty important, e.g. [1]. In the case of this specific page, we can probably just copy/paste it onto the bottom of [2] or similiar; it's easy to move since it's Markdown in either place. We should think about what to do with the other pages, though. Michael [1] https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines [2] https://docs.webkit.org/Deep%20Dive/MemoryManagement.html

3 3

ASSERT vs. RELEASE_ASSERT
by Michael Catanzaro 01 Apr '24

01 Apr '24

Hi, Just brainstorming, but I generally think it's worth enabling way more assertions in production builds to the extent we can do so without unacceptable performance impact. My ideal would be to rename ASSERT() to SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make release asserts the "default" type of assert. But I'm not ambitious enough to attempt that. Notably, this would in many cases downgrade the severity of security bugs, since hitting a RELEASE_ASSERT() is at worst a denial of service issue. Curious what other WebKit developers think about this. Michael

2 1