Bug 206167
| Summary: | WK1 DumpRenderTree doesn't support enabling and disabling features in test header | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Antti Koivisto <koivisto> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | ap, bfulgham, cdumez, simon.fraser, zalan |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Antti Koivisto
The support is in WK2 only.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
This was added to trigger features that require relaunching WebContent process, so not too surprising that it’s WK2 only.
Chris Dumez
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.
Chris Dumez
(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.
Alexey Proskuryakov
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.
Chris Dumez
(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.
Antti Koivisto
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.
Chris Dumez
(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
Chris Dumez
(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.
Antti Koivisto
Right. I just meant that these are not going to start magically working without code changes like they do in WK2.
Chris Dumez
(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.
Antti Koivisto
> 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.
Chris Dumez
(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.
Antti Koivisto
Yeah, features marked internal and experimental get this stuff for free (along with menu entries etc).