Notifications of features enabled or disabled via Finch flags in Stable

[Arvind Murching]

Hi,

Following up on a few exchanges, see refs below.  It would be useful for Chromium embedders (like Microsoft Edge) that do not connect to Finch servers to be notified, ideally with rationale, when a feature that is enabled by default in code is turned off via finch flags on the stable channel.

In theory, this would apply also to a feature that is disabled by default in code but is enabled by finch trials to a *significant* (say > 50%) population of stable channel users.

Thoughts?

Thanks

Arvind

Refs:

https://twitter.com/__apf__/status/1226910083549810688

https://twitter.com/mgiuca/status/1226982299515834368?s=20

https://twitter.com/blassey/status/1226941253872504832

[Brian Clifton]

Hi Arvind,

I'm definitely interested in this. The original message on Twitter from Eric Lawrence caught my attention for sure. With Brave, we are not reaching out to Finch servers and although I haven't personally narrowed down any of our webcompat issues to a problem with our flags/config/settings, we do get many reports of GPU problems (mostly from Windows users). When comparing to Chrome, I did notice that results from Finch / field trials were providing different values than the stock Chromium config for items in chrome://gpu

Is there a best known method for connecting to Finch servers, in an effort to compare the values returned to the config used (to identify variations)? This is something we'd like to explore more. Curious if other embedders have tackled this

Thanks

Brian

[Jeremy Apthorp]

Electron recently ran into an issue where YouTube was failing to load, eventually we worked out that it was an origin trial for Web Components V1 that was being enabled for that site.

It would be handy to be able to query what origin trials are enabled for a particular site, too!

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/f2b8ef9d-7758-4970-87a9-dd2e24058a6c%40chromium.org.

[Alexei Svitkine]

Generally, a feature would not get enabled by default on tip of tree until it has already launched via the experiment framework.

However, as you point out, it's does happen sometimes, unfortunately. So it's a good question of how embedders can stay aware of these instances.

One option would be for each such case requiring also a corresponding Chromium source change that sets the feature to disabled by default that is merged to the affected release branches.

Would that work as a mechanism for embedders to stay current in such situations? Both as a notification mechanism (just monitor merges to release branch) and as a way to pick up fixes (can pull these changes into your release branches).

WDYT?

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev+unsubscribe@chromium.org.

[Jeremy Apthorp]

That would be perfect for Electron as we already have automation monitoring release lines.

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/f2b8ef9d-7758-4970-87a9-dd2e24058a6c%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/34781b10-9fe2-4806-8edb-1702ce07f0ed%40chromium.org.

[Arvind Murching]

Alexei, the policy that you propose requiring a matching code change sounds like the right approach. Is this practical to enforce - specifically if all that we do is post this instruction somewhere in chromium.org, that may not suffice? Are you considering some tooling to automate this?

Thanks

Arvind

To unsubscribe from this group and stop receiving emails from it, send an email to embedd...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/f2b8ef9d-7758-4970-87a9-dd2e24058a6c%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embedd...@chromium.org.

[cha...@chromium.org]

On Saturday, February 15, 2020 at 11:18:05 AM UTC-5, Jeremy Apthorp wrote:

Electron recently ran into an issue where YouTube was failing to load, eventually we worked out that it was an origin trial for Web Components V1 that was being enabled for that site.

It would be handy to be able to query what origin trials are enabled for a particular site, too!

I'm not looking to hijack this thread, but a quick response to the origin trials comment. For a couple reasons, I don't think it's feasible to have a centralized mechanism to query enabled trials for a site. Primarily, a site can choose which pages enable an origin trial, so there isn't a single answer to "is this trial enabled for this site". That said, I'm sure there are other options to address any issues that embedders are running into with origin trials. As part of the team supporting origin trials, I'm interested to hear about any issues. Please do reach out to me, or experimen...@chromium.org.

Thanks,

Jason

On Fri, Feb 14, 2020 at 23:02 'Brian Clifton' via Chromium Embedders <embedd...@chromium.org> wrote:

Hi Arvind,

I'm definitely interested in this. The original message on Twitter from Eric Lawrence caught my attention for sure. With Brave, we are not reaching out to Finch servers and although I haven't personally narrowed down any of our webcompat issues to a problem with our flags/config/settings, we do get many reports of GPU problems (mostly from Windows users). When comparing to Chrome, I did notice that results from Finch / field trials were providing different values than the stock Chromium config for items in chrome://gpu

Is there a best known method for connecting to Finch servers, in an effort to compare the values returned to the config used (to identify variations)? This is something we'd like to explore more. Curious if other embedders have tackled this

Thanks

Brian

On Tuesday, February 11, 2020 at 7:19:27 PM UTC-7, Arvind Murching wrote:

Hi,

Following up on a few exchanges, see refs below.  It would be useful for Chromium embedders (like Microsoft Edge) that do not connect to Finch servers to be notified, ideally with rationale, when a feature that is enabled by default in code is turned off via finch flags on the stable channel.

In theory, this would apply also to a feature that is disabled by default in code but is enabled by finch trials to a *significant* (say > 50%) population of stable channel users.

Thoughts?

Thanks

Arvind

Refs:

https://twitter.com/__apf__/status/1226910083549810688

https://twitter.com/mgiuca/status/1226982299515834368?s=20

https://twitter.com/blassey/status/1226941253872504832

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev+unsubscribe@chromium.org.

[Arvind Murching]

Alexei, checking on the state of your proposal "One option would be for each such case requiring also a corresponding Chromium source change that sets the feature to disabled by default that is merged to the affected release branches."  Specifically, is this coming to effect, when?

Thanks

Arvind

[Eric Lawrence]

Checking in on this thread a year later, I wanted to note a few recent cases where Edge behavior has unexpectedly diverged from upstream in part due to Finch flags:

1) FTP Deprecation: Edge disabled FTP by default in the code and Chrome disabled it via Finch. Chrome's Finch config expired, accidentally re-enabling FTP for Chrome.

2) Cache Partitioning by Network Isolation Key: Chromium has SplitHostCacheByNetworkIsolationKey set to DISABLED_BY_DEFAULT. However, Chromium calls a function in startup ( SplitCacheFeatureEnableByDefault() ) to enable it by default if there's no finch override. Chrome's Finch is configured to disable this feature at 100% for 89 Stable; Edge did not copy this config. As a result, Edge unknowingly shipped the new split cache back in v88 Stable.  Fortunately, nobody seems to have noticed and we got our first complaint/query about this yesterday. 

3) ServiceWorker Installation: Finch enables ThrottleInstallingServiceWorker for Chrome 87 and above. Microsoft Teams noticed that their ServiceWorker installation failed in Edge but not Chrome; after investigation, we found that the absence of this flag caused network errors with Flow Control during the installations' fetch processes.

On an unrelated note: Finch configuration remains perhaps the most impactful non-transparent part of the Chromium project. This leads to even highly sophisticated browser folks getting confused (e.g. thinking H3 is disabled by default) about how Chromium behaves. Is there any chance that this might be made more transparent in the future?

thanks!

-Eric

[Alexei Svitkine]

Sorry for the delayed reply.

I wasn't aware of the specifics of those cases. It's not the intention to have these divergences, but sometimes things can be missed.

I definitely encourage you to file bugs if you see more cases like this - since ultimately individual teams are implementing their feature and getting this on their radar is the best way to get problems resolved in Chromium upstream.

We don't currently have plans for additional transparency into Chrome's server-side trials, although there are some things that exist already, like the field trial testing config.

-Alexei