Re: [webkit-dev] Experimental features review
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental features review
> On Feb 14, 2019, at 9:01 AM, Michael Catanzaro wrote: > > On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser 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: > https://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.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental features review
On Wed, Feb 13, 2019 at 9:16 PM, Simon Fraser 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: https://trac.webkit.org/changeset/235921/webkit. Perhaps that would suffice for regression testing? Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Experimental features review
> On Feb 13, 2019, at 11:32 AM, Michael Catanzaro 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Experimental features review
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: 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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev