Bug 194515 – [WKTR] Unify setup for content extensions tests among ports

• Status: ASSIGNED
• Component: Tools / Tests

[Adrian Perez]

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.

[Michael Catanzaro]

This might even come for free, now that you fixed that one refcounting issue.

[Adrian Perez]

(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 :)

[Adrian Perez]

Created attachment 361804 [details]
Patch

[Michael Catanzaro]

Comment on attachment 361804 [details]
Patch

Wait for EWS before using cq+.

[EWS Watchlist]

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.

[EWS Watchlist]

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

[Adrian Perez]

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).