Experimental features review

# Michael Catanzaro (3 days ago)

Last year, we cleaned up experimental features in WebPreferences.yaml to ensure no experimental features were enabled by default. Since then we have regressed a bit when enabling cool new web features. :) Currently we have 12 offenders, listed below. Most likely, the category: experimental line should be removed from these features. Alternatively, the defaultValue should be changed to either false or DEFAULT_EXPERIMENTAL_FEATURES_ENABLED (or something depending on that).

If you know about any of these settings, please keep reading and help decide what to do with them:

BlankAnchorTargetImpliesNoOpenerEnabled ThirdPartyIframeRedirectBlockingEnabled ScreenCaptureEnabled WebRTCUnifiedPlanEnabled WebRTCVP8CodecEnabled WebRTCH264SimulcastEnabled WebRTCMDNSICECandidatesEnabled IntersectionObserverEnabled VisualViewportAPIEnabled DarkModeCSSEnabled WebSQLDisabled ProcessSwapOnCrossSiteNavigationEnabled

Details:

BlankAnchorTargetImpliesNoOpenerEnabled: type: bool defaultValue: true webcoreBinding: RuntimeEnabledFeatures humanReadableName: "Blank anchor target implies rel=noopener" humanReadableDescription: "target=_blank on anchor elements implies rel=noopener" category: experimental

ThirdPartyIframeRedirectBlockingEnabled: type: bool defaultValue: true humanReadableName: "Block top-level redirects by third-party iframes" humanReadableDescription: "Block top-level redirects by third-party iframes" category: experimental

ScreenCaptureEnabled: type: bool defaultValue: true webcoreBinding: RuntimeEnabledFeatures condition: ENABLE(MEDIA_STREAM) && PLATFORM(MAC) humanReadableName: "ScreenCapture" humanReadableDescription: "Enable ScreenCapture" category: experimental

WebRTCUnifiedPlanEnabled: type: bool defaultValue: true webcoreBinding: RuntimeEnabledFeatures condition: ENABLE(WEB_RTC) humanReadableName: "WebRTC Unified Plan" humanReadableDescription: "Use WebRTC Unified Plan" category: experimental

WebRTCVP8CodecEnabled: type: bool defaultValue: true webcoreBinding: RuntimeEnabledFeatures condition: ENABLE(WEB_RTC) humanReadableName: "WebRTC VP8 codec" humanReadableDescription: "Enable WebRTC VP8 codec" category: experimental

WebRTCH264SimulcastEnabled: type: bool defaultValue: true webcoreBinding: RuntimeEnabledFeatures condition: ENABLE(WEB_RTC) humanReadableName: "WebRTC H264 Simulcast" humanReadableDescription: "Enable WebRTC H264 Simulcast" category: experimental

WebRTCMDNSICECandidatesEnabled: type: bool defaultValue: true humanReadableName: "WebRTC mDNS ICE candidates" humanReadableDescription: "Enable WebRTC mDNS ICE candidates" webcoreBinding: RuntimeEnabledFeatures category: experimental condition: ENABLE(WEB_RTC)

If the above features are to remain experimental, they should be sorted lower in the file, below this comment explaining experimental feature policy:

For experimental features:

The type should be boolean.

You must provide a humanReadableName and humanReadableDescription for

all experimental features. They

are the text exposed to the user from the WebKit client.

The default value may be either false (for unstable features) or

DEFAULT_EXPERIMENTAL_FEATURES_ENABLED (for features that are ready for

wider testing).

More offenders:

IntersectionObserverEnabled: type: bool defaultValue: true humanReadableName: "Intersection Observer" humanReadableDescription: "Enable Intersection Observer support" webcoreBinding: RuntimeEnabledFeatures category: experimental condition: ENABLE(INTERSECTION_OBSERVER)

VisualViewportAPIEnabled: type: bool defaultValue: true humanReadableName: "Visual Viewport API" humanReadableDescription: "Enable Visual Viewport API" category: experimental

DarkModeCSSEnabled: type: bool defaultValue: true humanReadableName: "Dark Mode CSS Support" humanReadableDescription: "Enable Dark Mode CSS Support" webcoreBinding: RuntimeEnabledFeatures category: experimental condition: ENABLE(DARK_MODE_CSS)

WebSQLDisabled: type: bool defaultValue: true humanReadableName: "Disable Web SQL" humanReadableDescription: "Disable Web SQL" webcoreBinding: RuntimeEnabledFeatures category: experimental

This one's weird because it's Disabled rather than Enabled... the semantics should probably be reversed. We probably want a WebSQLEnabled feature defaulting to false?

ProcessSwapOnCrossSiteNavigationEnabled: type: bool defaultValue: DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED humanReadableName: "Swap Processes on Cross-Site Navigation" humanReadableDescription: "Swap WebContent processes on cross-site navigations" category: experimental webcoreBinding: none

DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED is TRUE on macOS and iOS, bypassing DEFAULT_EXPERIMENTAL_FEATURES_ENABLED.

Contact us to advertise here
# Simon Fraser (3 days ago)

On Feb 13, 2019, at 11:32 AM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:

Hi,

Last year, we cleaned up experimental features in WebPreferences.yaml to ensure no experimental features were enabled by default. Since then we have regressed a bit when enabling cool new web features. :) Currently we have 12 offenders, listed below. Most likely, the category: experimental line should be removed from these features. Alternatively, the defaultValue should be changed to either false or DEFAULT_EXPERIMENTAL_FEATURES_ENABLED (or something depending on that).

If you know about any of these settings, please keep reading and help decide what to do with them:

IntersectionObserverEnabled VisualViewportAPIEnabled

For these two, we now have them on by default because we think they are ready to ship. They still exist as experimental features so that people can turn them off for regression testing, but is the policy now to move them back to Debug features at this stage?

Simon

# Michael Catanzaro (2 days ago)

On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser <simon.fraser at apple.com>

wrote:

For these two, we now have them on by default because we think they are ready to ship. They still exist as experimental features so that people can turn them off for regression testing, but is the policy now to move them back to Debug features at this stage?

Well, I'm really not sure, other than that the feature is no longer supposed to be experimental once it's ready to be on by default.

I notice there is a new class of features called internal features: trac.webkit.org/changeset/235921/webkit. Perhaps that would suffice for regression testing?

Michael

# Maciej Stachowiak (2 days ago)

On Feb 14, 2019, at 9:01 AM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:

On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser <simon.fraser at apple.com> wrote:

For these two, we now have them on by default because we think they are ready to ship. They still exist as experimental features so that people can turn them off for regression testing, but is the policy now to move them back to Debug features at this stage?

Well, I'm really not sure, other than that the feature is no longer supposed to be experimental once it's ready to be on by default.

I notice there is a new class of features called internal features: trac.webkit.org/changeset/235921/webkit. Perhaps that would suffice for regression testing?

I think this approach is needlessly confusing. For many features, there’s likely to be a period where the default flips, but it’s still useful for it to be switchable. Either for debugging, or because it hasn’t shipped in products yet and it is useful to compare. It would be sad if flags disappeared the moment the default flips, and likewise sad if they moved to a different menu as soon as the default flips.

(As an aside, I kind of hate experimental features being a menu like it is in Safari. Other browsers have more readable and persistent UI for this, like a special page or a settings pane. They also tend to have both default-on and default-off flags in the same place, so you don’t get lost on the day the default flips.)

# Michael Catanzaro (2 days ago)

No strong opinion from me here. I'm not familiar with how Safari's UI exposes some features but not others. In the GTK/WPE API, the features are not enumerable and only a few selected features are exposed at all, so that's not an issue for us.

I do think we have a semantic issue, though, if some features considered "experimental" are enabled by default. Not sure what the solution is. (And of course, if we change our experimental features policy, we'll want to ensure the comment in the WebPreferences.yaml file is updated.)

Michael

Want more features?

Request early access to our private beta of readable email premium.