2005763 - Runtime switch or preference to disable "early beta or earlier"

Status: RESOLVED WORKSFORME

(Firefox :: General, enhancement)

Description

[Florian Scholz (Open Web Docs)]

I'm a compatibility data collector for the mdn/browser-compat-data project (used for MDN, caniuse, Baseline, and many more projects).

Whenever browsers release a new beta version, I file pull requests to collect compat data systematically (example PR: https://github.com/mdn/browser-compat-data/pull/28624).

I use the beta channel for browsers, so that the compat data is up-to-date in time when we have a new stable release version.

Unfortunately, the Firefox beta is not always the same as the future stable Firefox release due to the "early beta or earlier" flag in https://searchfox.org/firefox-main/source/modules/libpref/init/StaticPrefList.yaml. I would love to have a Firefox beta that behaves like the future Firefox stable, so that I can test for correct compatibility information.

For Chrome, I ran into the same problem. Luckily, Chrome provides https://chromium.googlesource.com/chromium-variations/ and so open -a Google\ Chrome\ Beta --args --fake-variations-channel=stable disables variations and makes Chrome Beta act like the future stable Chrome browser release.

Could I have something similar for Firefox? Thanks!

Comment 1

[Mathew Hodson]

You could also wait to run the collector until Beta 7 is released. Starting in Beta 7 each cycle, experimental features are deactivated (EARLY_BETA_OR_EARLIER). Beta 7 of Firefox 147 releases December 22. See https://whattrainisitnow.com/release/?version=147

Comment 2

[Florian Scholz (Open Web Docs)]

Thanks for letting me know! Unfortunately, Beta 7 is quite late in the cycle. Usually work on documentation and compatibility data starts the day the first beta is released (and a new stable version is shipped). We want to publish information about newly shipping features in time on stable release day and so it makes sense to start that work once the new cycle begins to give enough time to work on docs and compat data.

Comment 3

[:Gijs (he/him)]

Hi Florian. I'm not 100% sure this is what you want, but would https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=build%2Crelease help? These are jobs creating nightly builds as release variations. This link should always point to the latest version of the macOS build created in this way. So that's (at time of writing) the most recent 148 nightly, built as if it were stable release.

Comment 4

[Florian Scholz (Open Web Docs)]

Thanks for providing yet another workaround. I guess I could get a release-like Firefox this way early enough. It adds yet another manual step to my process, though. (Note that the three main browser engines release up to 40 new versions per year in total and compat data collection is a semi-automated process on my side)

That said, there is also some automation I'm running which uses Selenium to launch lots of browsers and their versions. And these scripts allow me to set runtime flags or preferences: https://github.com/openwebdocs/mdn-bcd-collector/blob/b0227b155e8b343aaa15dc2f1634cc9f53fd668f/scripts/selenium.ts#L414-L450.

So, I guess my dream scenario would be to have a preference setting or a runtime flag to get a release-like beta analog to what Chrome provides with --fake-variations-channel=stable.

Comment 5

[:Gijs (he/him)]

(In reply to Florian Scholz (Open Web Docs) from comment #4)

So, I guess my dream scenario would be to have a preference setting or a runtime flag to get a release-like beta analog to what Chrome provides with --fake-variations-channel=stable.

Building the equivalent switch would require a significant amount of work for Firefox, because build channel defines are currently compiled in. So changing them at runtime is not really feasible at the moment. To have a flag like that would require shifting everything that currently relies on compiled in defines to use a runtime mechanism instead. So at the moment, I don't think it's very likely that such a change would be made in the near future.

If you're already using selenium, would you be able to (python or similar) script fetching the correct zip file using the index link I provided (which has an API etc. as well)? That might at least take some of the manual work out of it.

Comment 6

[Florian Scholz (Open Web Docs)]

Got it, thanks Gijs! I appreciate your help.

I will try to work with the link you provided. I guess next week (January 12, 2026) we will see the first 148 beta, so I guess I need use your CI build link shortly before the release-like Nightly becomes 149 to get a release-like 148.

Comment 7

[:Gijs (he/him)]

With bug 2051729 this define is going to go away very soon. Should we close this out, either now or at that point?

Comment 8

[Florian Scholz (Open Web Docs)]

Yeah, I think we can close this out. Thanks again for the guidance.

Comment 9

[Mathew Hodson]

Starting in the 155 cycle, all betas will have the same feature flags as the future release.