Bug 206167

This was added to trigger features that require relaunching WebContent process, so not too surprising that it’s WK2 only.

Actually, AFAIK it works in DRT and is used for enableBackForwardCache & useEphemeralSession. Not all settings are implemented in both WK1 & WK2 though, I just gave you 2 examples that are implemented for both though.

(In reply to Alexey Proskuryakov from comment #1)
> This was added to trigger features that require relaunching WebContent
> process, so not too surprising that it’s WK2 only.

Well, technically, you generally want your test to run in both DRT & WKTR. So it is useful for a setting like enableBackForwardCache set via the test header to actually enable the back/forward cache in both WK1 and WK2 for e.g. The only difference, is that in WK1, enabling the setting usually does not require a new view / context.

Specifically, the feature was added for testing system language dependent behaviors, which cannot be reset without starting a new process. So - we may want to test that everywhere, but it will never happen.

(In reply to Alexey Proskuryakov from comment #4)
> Specifically, the feature was added for testing system language dependent
> behaviors, which cannot be reset without starting a new process. So - we may
> want to test that everywhere, but it will never happen.

I just gave you 2 examples: useEphemeralSession & enableBackForwardCache. They require a new process in WK2, therefore, they use a setting in the test header. That said, those tests can still run in WK1 (even if they do not require a new process) and as a result, those in-header-settings also work in DRT so that the tests can run on all platforms.

I suppose the whole feature concept doesn't really exist in WK1 so these need to be hacked in specifically for anything that needs support.

(In reply to Antti Koivisto from comment #6)
> I suppose the whole feature concept doesn't really exist in WK1 so these
> need to be hacked in specifically for anything that needs support.

AFAIK, it is there. Look for TestOptions in DumpRenderTree. And setWebPreferencesForTestOptions() in DumpRenderTree.cpp

(In reply to Chris Dumez from comment #7)
> (In reply to Antti Koivisto from comment #6)
> > I suppose the whole feature concept doesn't really exist in WK1 so these
> > need to be hacked in specifically for anything that needs support.
> 
> AFAIK, it is there. Look for TestOptions in DumpRenderTree. And
> setWebPreferencesForTestOptions() in DumpRenderTree.cpp

Just search for enableBackForwardCache in DumpRenderTree/ folder for an example.

Right. I just meant that these are not going to start magically working without code changes like they do in WK2.

(In reply to Antti Koivisto from comment #9)
> Right. I just meant that these are not going to start magically working
> without code changes like they do in WK2.

Maybe we're not talking about the same thing. TestOptions do not just work in WKTR, they require code to support them. The code in DRT and WKTR to support TestOptions is similar although it is slightly more annoying in DRT because you need code for 2 ports.

> Maybe we're not talking about the same thing. TestOptions do not just work
> in WKTR, they require code to support them. The code in DRT and WKTR to
> support TestOptions is similar although it is slightly more annoying in DRT
> because you need code for 2 ports.

We must indeed be talking about different thing. There is zero code in WKTR to support LayoutFormattingContextIntegrationEnabled flag for example, yet it works beautifully.

(In reply to Antti Koivisto from comment #11)
> > Maybe we're not talking about the same thing. TestOptions do not just work
> > in WKTR, they require code to support them. The code in DRT and WKTR to
> > support TestOptions is similar although it is slightly more annoying in DRT
> > because you need code for 2 ports.
> 
> We must indeed be talking about different thing. There is zero code in WKTR
> to support LayoutFormattingContextIntegrationEnabled flag for example, yet
> it works beautifully.

Oh, I see:
<!-- webkit-test-runner [ internal:LayoutFormattingContextIntegrationEnabled=true ] -->

vs

<!-- webkit-test-runner [ enableBackForwardCache=true ] -->

We're *almost* talking about the same thing. It's just that there is a special "internal:" prefix that maps nicely to internal settings in WK2. Those indeed do not require any new code in WKTR. Then again, I don't think we have the concept of internal/experimental feature in WK1.

Yeah, features marked internal and experimental get this stuff for free (along with menu entries etc).