> Since an experimental feature flag should not remain off for a long time, > a per-experimental-feature file listing the tests to which activate the > feature could be considered. > > > That clashes with Ryosuke's point that moving tests shouldn't change > behaviour. >
I think it is better to discover the issue at the moment tests are moved. When moving/creating such tests in WPT, the potential issue will only arise after the export/import cycle. Chances are that the issue will get unnnoticed. > The larger problems are: > > - We don't want experimental features to be on in shipping browsers. It > might be ok for them to be always on in tests, but then MiniBrowser would > be different from WKTR. At the moment they are always on in tests, and use > their default value in MiniBrowser (and shipping). > When implementing a new feature, the first thing we usually do is having an experimental flag turned off by default. At some point, we turn on the experimental flag for tests. When ready, the flag is turned on by default. It is nice to keep the cost of implementing this workflow as low as possible. Having to tweak layout tests does not go in that direction. If this workflow was fully implementable by just updating WebPreferences.yaml, that would be great. That could also allow running mini browser in a mode where the same flags would be turned on as WKTR. > - Internal features can either be on or off by default, because we don't > expect users to toggle them. The tests should reflect their default value. > You use the header to test the non-default case. > > > So what we have right now is probably ok. The issue is with things I moved > from experimental to internal and that have a default value of off. I think > it is perfectly fine for those features to require test headers, since they > clearly aren't ready. > If these features are for debug purposes only, it seems like they would never end up being turned on by default, in which case opt-in in tests is fine. I would think there would be no need to turn on these features for WPT tests.
_______________________________________________ webkit-dev mailing list email@example.com https://lists.webkit.org/mailman/listinfo/webkit-dev