Preferred embedder support for web platform APIs with significant browser integration

[Rick Byers]

Hi,

I've seen some examples of new web platform APIs with browser integration being broken for a long time in various Chromium-based products. Eg. FedCM has a mix of blink and browser UI code and while major Chromium browsers like MS Edge work well, some limited testing has shown that a number of other browsers fail in different ways - from just failing to show any UI and not resolving promises, to failing with various error codes.

I worry this is problematic for the web ecosystem because it makes feature detection unreliable and instead encourages web developers to follow the much-hated pattern of allow-listing specific browser UA strings for specific functionality (thereby making it difficult for other browsers to get the same experience when they fix their issues).

In general I'd hope that every serious Chromium-based browser is running test suites like web-platform-tests and then fully disabling web APIs they don't support (eg. it's a simple RuntimeEnabledFeature to just turn FedCM off), but apparently that's not happening in practice or maybe enough has been implemented to pass the automated tests without actually wiring up to browser UI for real users?

We're not likely to be able to prioritize taking on additional work on the Chrome team to help identify and mitigate such cases (sorry your product quality is your problem, not ours 😉). But I'd be interested in any simple low-cost options to help mitigate the problem. For example, perhaps we could track such web-exposed-browser-UI features a bit differently in runtime_enabled_features.json5 such that embedders can have them disabled by default and then override enable them on a case-by-case basis? That doesn't mean we'd have test coverage for that unsupported configuration in upstream chromium bots (unmodified Chromium builds would continue to have these features enabled and fully tested), but at least that might make it easier to manage defaults downstream and be aware of relevant changes. Thoughts?

Thanks,

   Rick

[Marshall Greenblatt]

On Tue, Jun 24, 2025 at 4:21 PM Rick Byers <rby...@chromium.org> wrote:

Hi,

I've seen some examples of new web platform APIs with browser integration being broken for a long time in various Chromium-based products. Eg. FedCM has a mix of blink and browser UI code and while major Chromium browsers like MS Edge work well, some limited testing has shown that a number of other browsers fail in different ways - from just failing to show any UI and not resolving promises, to failing with various error codes.

I worry this is problematic for the web ecosystem because it makes feature detection unreliable and instead encourages web developers to follow the much-hated pattern of allow-listing specific browser UA strings for specific functionality (thereby making it difficult for other browsers to get the same experience when they fix their issues).

Google (and potentially other sites) block login from third-party browsers based on UA strings, and other libraries (like some media players and ads serving platforms) just break outright if they don't find an expected UA string. All else being equal, this is strong encouragement for third-party browsers to be disingenuous about their UA, and makes it very problematic to rely on UA for accurate feature detection.

 

In general I'd hope that every serious Chromium-based browser is running test suites like web-platform-tests and then fully disabling web APIs they don't support (eg. it's a simple RuntimeEnabledFeature to just turn FedCM off), but apparently that's not happening in practice or maybe enough has been implemented to pass the automated tests without actually wiring up to browser UI for real users?

As an embedder, configuring RuntimeEnabledFeatures (REF) at build time requires custom changes to a frequently updated file (runtime_enabled_features.json5), likely resulting in frequent merge conflicts. We might therefore prefer to configure REF at runtime, however that is not supported (by default) with access restricted to a list of friend classes. None of this encourages embedders to customize REF settings :).

 

We're not likely to be able to prioritize taking on additional work on the Chrome team to help identify and mitigate such cases (sorry your product quality is your problem, not ours 😉). But I'd be interested in any simple low-cost options to help mitigate the problem. For example, perhaps we could track such web-exposed-browser-UI features a bit differently in runtime_enabled_features.json5 such that embedders can have them disabled by default and then override enable them on a case-by-case basis? That doesn't mean we'd have test coverage for that unsupported configuration in upstream chromium bots (unmodified Chromium builds would continue to have these features enabled and fully tested), but at least that might make it easier to manage defaults downstream and be aware of relevant changes. Thoughts?

In my experience it's generally best (from the embedder perspective) if features are either (a) fully implemented without //chrome dependencies (e.g. in //content and/or //components), or (b) off-by-default at the //content layer (browser-side). A good example of this pattern is BackForwardCache which is fully implemented at the //content layer (I think), requires a method to enable, and has had behavioral changes clearly communicated. Problems often arise from features that are on-by-default (e.g. not configurable or default-enabled via REF/Feature flags) and that also require implementation from //chrome to fully support. Problematic examples include hard-to-discover Mojo binding dependencies for features like MediaFoundationRendererNotifier that (back in M102) required a stub binding implementation to avoid runtime crashes (no blame here, just recounting the first example that I spotted in the code).

You also raise a valid point about test coverage. Lack of test coverage for implementations not shared by //chrome will substantially limit any potential value from a behavior-standardization perspective (because nobody will know if the behavior is actually standard, or just broken, without testing in each individual third-party browser).

Thanks,

   Rick

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAFUtAY87fq637nNE9Gk%2B6pBZdTbhzVF_CnzpBaXf3gwDE%3DVMuw%40mail.gmail.com.

[Marshall Greenblatt]

On Jun 24, 2025, at 17:39, Marshall Greenblatt <magree...@gmail.com> wrote:



On Tue, Jun 24, 2025 at 4:21 PM Rick Byers <rby...@chromium.org> wrote:

Hi,

I've seen some examples of new web platform APIs with browser integration being broken for a long time in various Chromium-based products. Eg. FedCM has a mix of blink and browser UI code and while major Chromium browsers like MS Edge work well, some limited testing has shown that a number of other browsers fail in different ways - from just failing to show any UI and not resolving promises, to failing with various error codes.

I worry this is problematic for the web ecosystem because it makes feature detection unreliable and instead encourages web developers to follow the much-hated pattern of allow-listing specific browser UA strings for specific functionality (thereby making it difficult for other browsers to get the same experience when they fix their issues).

Google (and potentially other sites) block login from third-party browsers based on UA strings, and other libraries (like some media players and ads serving platforms) just break outright if they don't find an expected UA string. All else being equal, this is strong encouragement for third-party browsers to be disingenuous about their UA, and makes it very problematic to rely on UA for accurate feature detection.

 

In general I'd hope that every serious Chromium-based browser is running test suites like web-platform-tests and then fully disabling web APIs they don't support (eg. it's a simple RuntimeEnabledFeature to just turn FedCM off), but apparently that's not happening in practice or maybe enough has been implemented to pass the automated tests without actually wiring up to browser UI for real users?

Web property owners (like Google) also try to detect and block third-party browsers using feature detection heuristics. This further incentivizes third-parties to provide superficially-working-but-actually-broken feature implementations, instead of just disabling those features.

[José Dapena Paz]

El mar, 24-06-2025 a las 16:21 -0400, Rick Byers escribió:

Hi,

I've seen some examples of new web platform APIs with browser integration being broken for a long time in various Chromium-based products. Eg. FedCM has a mix of blink and browser UI code and while major Chromium browsers like MS Edge work well, some limited testing has shown that a number of other browsers fail in different ways - from just failing to show any UI and not resolving promises, to failing with various error codes.

My experience with some features is that it involves a significant effort to implement some of them and verify if they are working properly. And the amount of features to try is really big. WPT helps when it is available... It would be great if we could associate specific runtime features with a set of tests though, so it would be easy to try a specific feature end to end.

I can imagine having some WPT "features" concept, that provides, for each, a list of tests that validate that feature. These features could be pointed from a field in runtime_enabled_features.json. This way, running WPT it would be possible to provide per-feature pass rates. Apparently WPT already provides this through its folder structure, so maybe it is just referring to a specific path in WPT. Also, we have many web platform features that are not in WPT that we will want there. PWA is definitely one of them.

We had historically some bad incentives. One that was very popular: HTML5test. It would be tempting to actually make the APIs work with fake or stub implementations to just raise the score. The idea was right in my opinion: an exhaustive test of different features. But the implementation would not really assess if the API was useful.

In any case, for specific features that anybody detects as broken, some kind of reporting to the vendors should be done. I.e. if you spent some time trying FedCM with other browsers, those browsers should know they are failing!... Maybe asking browser vendors to provide a contact address for reporting problems, so they can review that internally? I am not asking here that Chrome or Google does that systematically or owns that responsability. But for the cases it is actually something Google is testing, then making sure the feedback gets to the downstream browsers would be good!

I worry this is problematic for the web ecosystem because it makes feature detection unreliable and instead encourages web developers to follow the much-hated pattern of allow-listing specific browser UA strings for specific functionality (thereby making it difficult for other browsers to get the same experience when they fix their issues).

UserAgent detection is still a problem, with major content providers locking out browsers just with it still nowadays. Marshall already added some considerations about this. 

In general I'd hope that every serious Chromium-based browser is running test suites like web-platform-tests and then fully disabling web APIs they don't support (eg. it's a simple RuntimeEnabledFeature to just turn FedCM off), but apparently that's not happening in practice or maybe enough has been implemented to pass the automated tests without actually wiring up to browser UI for real users?

RuntimeEnabledFeatures could likely support some kind of overlays to be more useful. And those overlays should be used already by Chrome:

• Content layer or Blink layer providing defaults to false if the feature is not implemented completely in that layer.
  
• Then, Content Shell and Chrome, providing their overlays for enabling features that are implemented in each layer.

Another possibility is just having the RuntimeEnabledFeatures be enabled or disabled, but make sure an explicit check for platform implementation is done. So, default override in content layer is disabling the feature, and only enable it when it is explicitely enabled by a content layer embedder (content shell, chrome or others).

There is a big problem often with some important web platform features: they are partially or mostly implemented in //chrome. We have this problem with several components, but a significant one is PWA. We end up with solutions where //chrome is still used for other browsers that ship  a completely different user experience.

We're not likely to be able to prioritize taking on additional work on the Chrome team to help identify and mitigate such cases (sorry your product quality is your problem, not ours 😉). But I'd be interested in any simple low-cost options to help mitigate the problem. For example, perhaps we could track such web-exposed-browser-UI features a bit differently in runtime_enabled_features.json5 such that embedders can have them disabled by default and then override enable them on a case-by-case basis? That doesn't mean we'd have test coverage for that unsupported configuration in upstream chromium bots (unmodified Chromium builds would continue to have these features enabled and fully tested), but at least that might make it easier to manage defaults downstream and be aware of relevant changes. Thoughts?

One thing that comes to my head: allow to specify, for some runtime enabled features, a method to validate implementation is available, so, when it is not, it returns false:

{

  name: "Feature",

  status: "experimental",

}

We could have a new object RuntimeEnabledFeaturesCheckerBase, generated automatically that, for each feature, generates a virtual with default value "true":

  virtual bool FeatureAvailable() const { return true; }

Then, a class RuntimeEnabledFeaturesChecker that implements access to the actual checker methods, so a specific implementation can be added for each:

  bool FeatureAvailable() const override {

    return FeatureManager::IsImplemented();

  }

This way, we can still use RuntimeEnabledFeatures::FeatureEnabled, but it will actually allow to add specific checks to make sure the feature implementors opt in to enable them. Problem: each feature that we consider problematic would need to at least provide a check that is safe enough to know the feature is actually available. That is not high cost, but not exactly low cost either. So, to me it looks simpler to take the runtime_enabled_features override, and make sure the features that are not completely implemented in content layer/Blink are by default disabled there, and only enabled in the //chrome overlay. Origin trials provide somehow a way to do this, but it may be confusing to mix locking out non implemented features with the trials.

To wrap up:

• Web platform features that are implemented significantly in //chrome should be moved away from there (and leave in //chrome only the minimal integration parts that are specific to Chrome browser, providing abstractions to allow other browsers to implement their parts).
• More and more work on better WPT is important. It should be easy to know a specific feature is properly tested. A way to associate WPT with specific features would be really great, with per feature pass rates.
• Having a way to report directly to specific browsers they are broken (i.e. by them providing contact addresses to Chrome maintainers).
• runtime_enabled_features.json need some way to default to reject if the feature is actually not really implemented.

[Erik Anderson]

Other folks have provided a good overview of the complexity of this space. I’ll offer some additional thoughts from the Microsoft Edge team.

 

It would be valuable to have a consistent, easy-to-use pattern to enable embedders to:

1. Become aware of platform APIs that require meaningful app-level code to make the API work sensibly. Even if they primarily just use this to prioritize testing it in their app.
2. Have these features be implemented in Chromium in such a way that they can easily be turned off by the embedder if they so choose.

 

I don’t think trying to structure things in a way where it’s always off-by-default for embedders is likely helpful. That’s because embedders that wants things on by default would just modify any such code downstream to flip the default over.

 

That said, if there is sufficient embedder interest, Chromium could perhaps implement something similar to what EnableExperimentalFeatures does, but with a new marking. That new method might check some build flag like CAUTIOUS_CHROMIUM_EMBEDDER (which neither Chrome or Chromium would set, but an embedder could choose to). If that flag would set, it could turn all of the features classified in this way off.

 

To enable an embedder to turn on a subset of these APIs (where app-level code exists), a potential idea would be to have a separate, embedder-specific JSON configuration file that allows overriding the feature marking individually. I say “separate file” because we’re really worried about the ongoing conflict/merge complexity of trying to tackle it in a huge file like runtime_enabled_features.json5. If there was instead something similar to fieldtrial_testing_config.json where an embedder could add embedder-specific overrides one-by-one, that would largely mitigate the maintenance concern. Or maybe the suggested FeatureAvailable pattern could work if there was a central, isolated file for an embedder to place those overrides.

 

From: embedd...@chromium.org <embedd...@chromium.org> On Behalf Of José Dapena Paz
Sent: Wednesday, June 25, 2025 12:45 AM
To: embedd...@chromium.org
Subject: [EXTERNAL] Re: [embedder-dev] Preferred embedder support for web platform APIs with significant browser integration

 

You don't often get email from jda...@igalia.com. Learn why this is important

--

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 visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/848ae4e6684d1b4594b4677dbbe5f29bf1739639.camel%40igalia.com.

[Rick Byers]

Thanks folks! A few responses:

On sites conditioning functionality on UA strings: I think we all agree this is bad. I've fought against this a bunch myself too, but as soon as a web developer points to a popular chromium browser which has an API which passes feature-detection checks but is broken and doesn't fail gracefully then I loose the argument and the web developer feels vindicated in their UA-string-based opt-in approach supporting only the specific browsers they've tested and validated to be working. This is what's motivating this thread for me - I think we need to fix things such that it's rare for web developers to find features exist but non-functional in chromium-based browsers if we want any hope of making more progress against the UA-string conditioning problem.

In terms of reaching out to broken browsers, absolutely I personally do that when I notice or hear about such breakage. But also we (Chrome team) generally do not proactively test other Chromium browsers, so this isn't really a solution in any sense. 

Good points about merge conflicts with runtime-enabled-features.json5 being a pain. This suggests one quick and easy pragmatic improvement - update the build infra to look for an additional file which can override values. I've filed this issue to track that and I'm happy to help ensure consensus and code reviews if someone in the downstream community wants to take on writing a patch for this.

There was some discussion of features being off by default in upstream Chromium and then enabled by Google Chrome. I'm not personally aware of any features which are upstream on-by-default but don't actually work there, are others? This matters of course for example for vanilla Chromium builds used in some Linux distributions. We wouldn't want to actually flag features off in upstream Chromium which do actually work there, eg. we still want all the testing that occurs on the public bots. So I don't think any of the suggestions to enable a separation of Chromium from Chrome would be helpful, would they?

In contrast I think there's a strong argument for better respecting the content API boundary - having blink/content leave features off and get enabled at the chromium layer. In particular, looking at FedCM and how it's explicitly disabled by WebView (our second upstream content embedder), I'm convinced that's that's broken and should be fixed to be disabled by default in content and enabled by Chromium. I've filed this bug to ask the FedCM team to explore fixing this and establishing a pattern we can apply more broadly to similar features. Perhaps finding a good way to fix this bug is the main thing to be done in response to this thread? Once we have an example of one feature doing this well I can work on ensuring we have good docs and bugs filed for a set of known features which should also follow the pattern.

Regarding mapping feature flag names to WPT coverage information per feature, I think this is related to work the WebDX CG folks are doing to catalog all features. There's some of this today on webstatus.dev, but that's not the right place to have chromium-specific details like chromium flags, so probably we also need some chromestatus.com work. Perhaps @foolip can share more and point to details on the WPT/features mapping work? I certainly hope that we'll eventually have both a great WebDX feature ID <-> WPT mapping and a chromestatus feature (including flag name) <-> WebDX feature ID mapping. 

Rick

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

[Marshall Greenblatt]

On Tue, Jul 1, 2025 at 12:39 PM Rick Byers <rby...@chromium.org> wrote:

Thanks folks! A few responses:

On sites conditioning functionality on UA strings: I think we all agree this is bad. I've fought against this a bunch myself too, but as soon as a web developer points to a popular chromium browser which has an API which passes feature-detection checks but is broken and doesn't fail gracefully then I loose the argument and the web developer feels vindicated in their UA-string-based opt-in approach supporting only the specific browsers they've tested and validated to be working. This is what's motivating this thread for me - I think we need to fix things such that it's rare for web developers to find features exist but non-functional in chromium-based browsers if we want any hope of making more progress against the UA-string conditioning problem.

In terms of reaching out to broken browsers, absolutely I personally do that when I notice or hear about such breakage. But also we (Chrome team) generally do not proactively test other Chromium browsers, so this isn't really a solution in any sense. 

Good points about merge conflicts with runtime-enabled-features.json5 being a pain. This suggests one quick and easy pragmatic improvement - update the build infra to look for an additional file which can override values. I've filed this issue to track that and I'm happy to help ensure consensus and code reviews if someone in the downstream community wants to take on writing a patch for this.

There was some discussion of features being off by default in upstream Chromium and then enabled by Google Chrome. I'm not personally aware of any features which are upstream on-by-default but don't actually work there, are others?

I think we need to differentiate here between //content (WebView) and //chrome (Browser) embedders. There are many features enabled by default that don't have a functioning implementation at the //content layer. This includes basically everything that depends on a Chrome subsystem like UI, history or permissions to function properly.  Some examples of basic functionality that we would prefer to have working by default at the //content layer include dialogs (Javascript alert/confirm/prompt, input type=file/color, datalist, printing, certificate selection, permissions, etc.), visited links, and DevTools. The most visible example for web users might be input type=file, input type=color and datalist HTML elements where the element displays as expected but otherwise doesn't function.

 

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/9beacb9b-36ff-4ace-960e-8cadf8f6a333n%40chromium.org.

[Mike Jackson]

Hi - 

Last week, I worked with Rick to land 6731644: Reland "Implement a simple mechanism for downstream forks to customize runtime-enabled-features.json5" | https://chromium-review.googlesource.com/c/chromium/src/+/6731644. This change adds infrastructure that enables embedders to define new feature flags or override existing ones specified in runtime_enabled_features.json5. Examples can be found in runtime_enabled_features.override.json5. Please feel free to reach out or provide feedback. Thank you again Rick for all your help and support with landing this change. 

-Michael

[Rick Byers]

Thank you Mike. This turned out to be a bit more work for you than I had predicted, thanks for following through! I hope this makes managing feature configurations easier for Edge and other downstream Chromium forks.

I also hope it helps reduce the risk of features being enabled but broken, frustrating adoption for browsers that do support them correctly. But probably we really need a good solution to having embedder-coupled features disabled by default at the content layer for that (/cc @Christian Biesinger who is looking into it). 

Rick

You received this message because you are subscribed to a topic in the Google Groups "Chromium Embedders" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/embedder-dev/KpiAwIIlqSM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to embedder-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/ece0f0aa-0c3a-4dea-8646-1b7be0bf0b44n%40chromium.org.