271664 2024-03-25 10:57:05 -0700 [iOS 17.4] Local WebKit builds don't use locally-built app extensions, lldb cannot attach 2025-04-24 08:48:41 -0700 1 1 1 Unclassified WebKit WebKit Process Model WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 273550 https://bugs.webkit.org/show_bug.cgi?id=272401 https://bugs.webkit.org/show_bug.cgi?id=291243 InRadar P2 Normal --- 1 ajuma webkit-unassigned achristensen ap dave+webkit dvpdiner2 justincohen jzw mike mjs pvollan rniwa rohitrao sihui_liu webkit-bug-importer oldest_to_newest 2023720 0 ajuma 2024-03-25 10:57:05 -0700 When building WebKit for the iOS simulator after 276550@main (so that USE_EXTENSIONKIT is true), local builds try to use app extensions from the simulator runtime rather than their locally-built counterparts. For example, rather than using WebKitBuild/Debug-iphonesimulator/WebContentExtension.appex, local builds instead try to use /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/ExtensionKit/Extensions/WebContentExtension.appex In practice this means that local builds are very broken, since they are combining locally-built WebKit.framework with pre-built app extensions, resulting in mismatching IPC messages. Is there some additional configuration needed to get ExtensionKit builds working with the public SDK? 2023939 1 pvollan 2024-03-26 09:08:54 -0700 (In reply to Ali Juma from comment #0) > When building WebKit for the iOS simulator after 276550@main (so that > USE_EXTENSIONKIT is true), local builds try to use app extensions from the > simulator runtime rather than their locally-built counterparts. > > For example, rather than using > WebKitBuild/Debug-iphonesimulator/WebContentExtension.appex, local builds > instead try to use > /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/ > CoreSimulator/Profiles/Runtimes/iOS > 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/ExtensionKit/ > Extensions/WebContentExtension.appex > > In practice this means that local builds are very broken, since they are > combining locally-built WebKit.framework with pre-built app extensions, > resulting in mismatching IPC messages. > > Is there some additional configuration needed to get ExtensionKit builds > working with the public SDK? Thanks for reporting this issue! The extension executables themselves are very small executables that just calls into the WebKit framework. What specific issues are you seeing? Since the IPC code is contained in the WebKit framework, I would not immediately expect there to be mismatches with regards to IPC messaging. 2023975 2 ajuma 2024-03-26 12:24:44 -0700 (In reply to Per Arne Vollan from comment #1) > Thanks for reporting this issue! > > The extension executables themselves are very small executables that just > calls into the WebKit framework. What specific issues are you seeing? The main issue is that since these executables are part of the system, SIP prevents attaching a debugger to them, even if they are ultimately calling into the WebKit framework. > Since > the IPC code is contained in the WebKit framework, I would not immediately > expect there to be mismatches with regards to IPC messaging. Sometimes on launch, NetworkProcessProxy::didReceiveNetworkProcessProxyMessage receives a WebSWServerConnection_WhenServiceWorkerIsTerminatedForTesting message which it should never receive outside of tests, so fails an assertion for this unhandled message. That made me think that the sender and receiver were using different versions of the MessageName enum, but since this is not consistent it's probably unrelated. 2024182 3 pvollan 2024-03-27 08:29:05 -0700 (In reply to Ali Juma from comment #2) > (In reply to Per Arne Vollan from comment #1) > > Thanks for reporting this issue! > > > > The extension executables themselves are very small executables that just > > calls into the WebKit framework. What specific issues are you seeing? > > The main issue is that since these executables are part of the system, SIP > prevents attaching a debugger to them, even if they are ultimately calling > into the WebKit framework. > That is a good point! I will look into ways of resolving this. > > Since > > the IPC code is contained in the WebKit framework, I would not immediately > > expect there to be mismatches with regards to IPC messaging. > > Sometimes on launch, > NetworkProcessProxy::didReceiveNetworkProcessProxyMessage > receives a WebSWServerConnection_WhenServiceWorkerIsTerminatedForTesting > message which it should never receive outside of tests, so fails an > assertion for this unhandled message. That made me think that the sender and > receiver were using different versions of the MessageName enum, but since > this is not consistent it's probably unrelated. 2025127 4 webkit-bug-importer 2024-04-01 10:58:15 -0700 <rdar://problem/125726458> 2027333 5 pvollan 2024-04-09 21:48:41 -0700 *** This bug has been marked as a duplicate of bug 272401 *** 2027505 6 pvollan 2024-04-10 11:22:24 -0700 This is still an issue, but the crash you are seeing should be resolved by https://commits.webkit.org/277304@main. 2027624 7 rniwa 2024-04-10 17:53:31 -0700 *** Bug 272442 has been marked as a duplicate of this bug. *** 2034556 8 pvollan 2024-05-10 09:47:48 -0700 *** Bug 273550 has been marked as a duplicate of this bug. *** 2112364 9 rniwa 2025-04-22 01:04:03 -0700 Was this ever resolved? 2112830 10 pvollan 2025-04-24 00:02:01 -0700 *** This bug has been marked as a duplicate of bug 273550 *** 2112832 11 pvollan 2025-04-24 00:02:25 -0700 Yes, this is a dupe of https://bugs.webkit.org/show_bug.cgi?id=273550. 2112901 12 rniwa 2025-04-24 08:48:41 -0700 Nice!