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?
(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.
(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.
(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.
<rdar://problem/125726458>
*** This bug has been marked as a duplicate of bug 272401 ***
This is still an issue, but the crash you are seeing should be resolved by https://commits.webkit.org/277304@main.
*** Bug 272442 has been marked as a duplicate of this bug. ***
*** Bug 273550 has been marked as a duplicate of this bug. ***