Bug 88657 – [WK2] Missing API to check whether WebKitTestRunner is being used

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit2

[Mario Sanchez Prada]

In WK1, some ports use specific functions in WK1 to detect when DumpRenderTree is being used (see DumpRenderTreeSupport{Gtk|Qt}::setDumpRenderTreeModeEnabled), so they can make interesting decisions when initializing the WebView, such as installing mock clients instead of the "good ones" (e.g. GeolocationClientMock).

However, that feature seems to be missing in WK2 (or at least I could not find it) and I think it would be very useful too for similar situations, hence this bug. Maybe there's already a way to do this, in that case feel free to point it out and/or close this bug. Thanks

(CCing people I think might be interested on this)

[Mario Sanchez Prada]

Created attachment 146565 [details]
Patch proposal

[Mario Sanchez Prada]

This doesn't depend on 59201. It *blocks* 59201

[Mario Sanchez Prada]

Ping reviewers?

[Benjamin Poulain]

Comment on attachment 146565 [details]
Patch proposal

View in context: https://bugs.webkit.org/attachment.cgi?id=146565&action=review

> Source/WebKit2/ChangeLog:9
> +        New API to allow declaring that WebKitTestRunner is running (on
> +        initialization) and checking that value from the WebProcess.

But why?

[Mario Sanchez Prada]

(In reply to comment #4)
> (From update of attachment 146565 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=146565&action=review
> 
> > Source/WebKit2/ChangeLog:9
> > +        New API to allow declaring that WebKitTestRunner is running (on
> > +        initialization) and checking that value from the WebProcess.
> 
> But why?

The reason is to do something similar to what it's done in WK1, where you need to  know when WebKit is running for its normal use case or when it's running for serving the DumpRenderTree, since the kind of geolocation provider that must use is different.

In the former case, the normal geolocation provider (e.g. Geoclue based) will be used, but for layout tests we need a special kind of geolocation provider (the mock provider) which allows us also to specify the position, so we can later check that the actual and expected results are the same.

As you can see in the patch for bug 59201, this new API is used in WebPage.cpp precisely to know when we will use the normal geolocation provider or the mock provider, so that's the reason of this API.

[Benjamin Poulain]

> The reason is to do something similar to what it's done in WK1, where you need to  know when WebKit is running for its normal use case or when it's running for serving the DumpRenderTree, since the kind of geolocation provider that must use is different.
> 
> In the former case, the normal geolocation provider (e.g. Geoclue based) will be used, but for layout tests we need a special kind of geolocation provider (the mock provider) which allows us also to specify the position, so we can later check that the actual and expected results are the same.
> 
> As you can see in the patch for bug 59201, this new API is used in WebPage.cpp precisely to know when we will use the normal geolocation provider or the mock provider, so that's the reason of this API.

This is not how you are supposed to do those tests.

Even if we had to change a client, that should be done through the injected bundle.

[Mario Sanchez Prada]

(In reply to comment #6)
> [...]
> This is not how you are supposed to do those tests.
> 
> Even if we had to change a client, that should be done through the injected bundle.

You are right. This is all conceptually broken, now I see it.

Thanks for the explanations. I'm now closing this bug