This CL moves the base::Feature from content_features.h to
a generated feature from runtime_enabled_features.json5.
This means that the base::Feature can be default-enabled
while the web API is co...
A fork like Vivaldi, Brave or Opera could opt not to implement these changes
It doesn’t quite work like that. They wouldn’t choose to not implement the change, because the change comes from upstream via Chromium. They would have to choose to remove the feature which, depending on how it’s integrated, could be just as much work as implementing it (or more, if Google wants to be difficult on purpose). Not implementing the change is zero effort; removing the upstream code is a lot of effort.
Perhaps I could rephrase that to “could opt to unimplement”. These people are smart enough to check and verify the changes in the browsers that they ship.
These alternative browsers are essentially also forks of chromium. They pull in changes from upstream. I’m not well versed in browser engine development or how these teams keep their engines up to date, but I’m sure there’s a person or team responsible for checking and pulling the changes. They could decide to not pull that in, if that code is properly boxed and not all over the place, but still the commits to that feature will show what and where. They still have that choice to stray from upstream, but it might be hard to maintain in the long run if the code is all over the place.
A fork like Vivaldi, Brave or Opera could opt not to implement these changes, but then some websites could become incompatible to them.
It doesn’t quite work like that. They wouldn’t choose to not implement the change, because the change comes from upstream via Chromium. They would have to choose to remove the feature which, depending on how it’s integrated, could be just as much work as implementing it (or more, if Google wants to be difficult on purpose). Not implementing the change is zero effort; removing the upstream code is a lot of effort.
Perhaps I could rephrase that to “could opt to unimplement”. These people are smart enough to check and verify the changes in the browsers that they ship.
These alternative browsers are essentially also forks of chromium. They pull in changes from upstream. I’m not well versed in browser engine development or how these teams keep their engines up to date, but I’m sure there’s a person or team responsible for checking and pulling the changes. They could decide to not pull that in, if that code is properly boxed and not all over the place, but still the commits to that feature will show what and where. They still have that choice to stray from upstream, but it might be hard to maintain in the long run if the code is all over the place.