After bug #193622 the WPE and GTK ports both use the same code for configuring content extensions in WKTR, using the C API. Ideally the Cocoa port would use the same as well, and avoid needing to have its own implementation.
This might even come for free, now that you fixed that one refcounting issue.
(In reply to Michael Catanzaro from comment #1) > This might even come for free, now that you fixed that one refcounting issue. It may help, yes :)
Created attachment 361804 [details] Patch
Comment on attachment 361804 [details] Patch Wait for EWS before using cq+.
Comment on attachment 361804 [details] Patch Attachment 361804 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/11123709 Number of test failures exceeded the failure limit.
Created attachment 361807 [details] Archive of layout-test-results from ews107 for mac-highsierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
My suspicion here is that the static WKWebViewConfiguration globalWebViewConfiguration; inside “TestControllerCocoa.mm”, which contains a .userContentController property is what it gets used as page configuration, instead of what the generic TestController code configures -- which effectively results in the content extension configured by ::configureContentExtensionForTest() not being used at all because the WKPageConfigurationRef passed from the generic TestController code to Cocoa's ::platformCreateWebView() is just ignored. Maybe the least path of resistance is setting the .userContentController property for the global configuration (or, better: the one copied one from it, when WK_API_ENABLED is set).