[Webkit-unassigned] [Bug 222885] Formalize rules for what is an Experimental Feature

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=222885

--- Comment #16 from Maciej Stachowiak <mjs at apple.com> ---
(In reply to Sam Weinig from comment #15)
> (In reply to Maciej Stachowiak from comment #14)
> > (In reply to Sam Weinig from comment #7)
> > 
> > 
> > Seems like this would make it inconvenient for people to try turning such
> > features off (at least in Apple ports), and would create a confusing
> > disconnect for anyone testing on/off comparisons, where they now have to
> > look in a different place.
> > 
> > I can see how it is conceptually wrong to call a shipping feature
> > “experimental” but this aspect of the proposal seems to have serious
> > downsides, unless we change the UI to make internal flags much more easily
> > accessible, and put them closer to experimental flags.
> > 
> > By way of comparison, other browsers with feature flag UI do not move flags
> > to a totally different and less easily accessible place when they become on
> > by default. And I don’t think we should do so either.
> > 
> > Maybe this means we should drop the label “experimental” and just call them
> > something neutral like “feature flags”.
> 
> This is getting a bit too into Safari's UI probably, but the Develop menu
> has other features in it that aren't "experimental" (see the "Disable
> Styles", "Disable JavaScript" section). There is nothing stopping Safari
> from adding these features where it is useful to disable them to other parts
> of the menu. I also think it would be a useful exercise to make a decisions
> when a feature has shipped if it really is useful to have a way to disable
> it, and thus it's manual inclusion in the Develop menu will require more
> thought. I am not convinced that most features need a way to be disabled
> after shipping, so this seems ok to me.

I don't think it is reasonable to label flags for disabling recently-enabled features "Internal", and then hand-curate a list at the Safari level of ones that get put in the Develop menu instead of the place where all other Internal flags go. I think this is a poor approach because:

(a) It's misleading to call these types of flags Internal if they are not actually intended to be treated this way.

(b) WebKit has more expertise than Safari on which flags of this type should be offered for convenient disablement. This is analogous to the way WebKit has more expertise in which flags represent experimental features that are ready to try, so we don't ask WebKit-based browsers to manually curate their own list, we give them one.

(c) This hand-curated list would have to be manually kept in sync with the status of things in WebKit, including things where we might remove the runtime feature flag entirely.

(d) We sort of support running old Safari with new WebKit; that would automatically pick up new Experimental flags, but not flags in this category.

> 
> That said, if we want to make it "easy" to have a way to disable some
> features after shipping, we could make another group, "Toggle-able Features"
> say, that exists parallel to the "Experimental" and "Internal" Features
> groups. Then, Safari could decide how it wants to display these.

I agree that making a distinct group for recently-enabled features would be a better proposal.

This would also let browsers put both this category and "Experimental" flags in one UI, or in separate places, as they prefer.

Personally, I'd argue that any runtime feature flag representing a web-exposed feature, where we have not yet chosen to remove the flag and leave the feature enabled always, is likely worth toggling for testing. But if we think it needs to be a more case-by-case process, the WebKit project is in a better position to execute that process.


> 
> 
> I am making this argument because I think it is valuable to have clear
> delineation of what we think is "experimental", as it makes a clear
> indication both to those working on WebKit and to web developers on the
> status of the feature. The more we conflate shipping and experimental
> status, the muddier and more confusing that becomes.

Part of the problem here is trying to use a hierarchy of menus as the UI. Other browsers have a page-like experience that lets you toggle flags but also makes clear what the default value is. With such a UI, they have no need to distinguish flags that are default-off, but worth testing (what we call "Experimental") from flags that are enabled by default but sometimes worth turning off for testing; and no need to put them in different places.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210322/ce6158a9/attachment.htm>