We're talking about the company that had to contribute arbitrary-length command lines to the Linux kernel, and whose flags library supports reading the flags from a file, in case your appetite for flags is insatiable.
Lots of flag libraries support @argfiles, it's useful for Windows amongst other places.
The real fun story about Google and flags is from the days when their flags library supported flags being passed in gzipped base64 form ... via a flag. I think the reason was there was a server that could take the whole configuration in the form of a flag, but it had got too large for Linux at some point and they didn't want to load the config from a file because there was better support for canaried/partial rollouts of flag changes than data file changes. Or something like that.
It's actually even more. --enable-features takes a list of features, and --force-fieldtrials takes a list of field trials. And each argument of --enable-features can itself have "sub-features", so you can have syntax like --enable-features=CoolFeature:Widget/1/Bells/cow*
I don't know if the syntax for all of this is actually documented anywhere, but anything in chrome://flags seems to be plumbed through via --enable-features. You can see the syntax in chrome://versions?show-cmd-variations.
It would be cool if someone updated the autogen table to also include the list of available features and field trials.
I didn't know that's where the feature flags lived. I imagine documenting them is tough because it'll heavily depend on the version since they graduate to become standard features over time.
I've been nerd sniped and am trawling through the code trying to understand what this means.
Apparently there is something called a "Birch Bar" which I've never heard of, it seems to be related to calendar events... which, is weird as I have never seen a native calendar in chrome.
It made me chuckle that the comment in "--accept-lang" states "When commenting your switch, please use the same voice as surrounding comments", and the very next flag breaks that rule.
do you or anyone else happen to know an extension that allows getUserMedia to work without https? i just need a photo from a webcam (a la <input file capture> that opens a camera on a smartphone) for a local network webapp. configuring https just for this is fickle.
I've tested 300+ of them for the purpose of reducing browser fingerprintability while building ArchiveBox's puppeteer support. It was quite a journey!
Lots of subtle GPU rendering stuff that can easily give away a headless browser, or that differs between OS's in ways that can be used to detect when a browser doesn't match the expected behavior for the OS it reports to be running on.
This could be a good thing. Too many applications are overly opinionated, make decisions on behalf of the user (without the ability to override), minimize user choice, don't respect the user's configuration, and in general, do things their way rather than the user's way. More switches is often better.
I've actually made it a design principle that whenever two or more choices seem to present themselves and I have to decide whether to do it the one or the other way, provided it's not too difficult to implement both, I do that and then I have the much lesser burden of deciding on the most reasonable default. This is also the result of decades-long frustrations with app behavior that is artificially restricted
I agree; it also makes using Chromium for all sorts of automation a lot easier. I found these because I wanted to automate generating PDFs of a report page.
I remember doing this expansion when I worked there: every module you include has its own set of command flags, and none get suppressed when you include them, so you end up with colossal unions like this. It's not as though any one team said, "Hey, let's have 1600 flags!"
I had to use some odd Chrome command line arguments to keep a particular fragile kiosk-mode-like use of a prototype working long enough.
It worked for our purposes, but we feared an update might break it. I went to some effort to prevent updates outside our control.
(The command line arguments can be removed over time. Also, the behavior/correctness can change over time. I wouldn't expect all combinations of arguments to be tested in all future releases.)
They do: Borg (Google's internal orchestration system) is very, very flag-driven and it's commonplace for services to have hundreds or thousands. That's presumably how Chromium ended up the same way.
Yes, everything internally has many flags (hundreds or thousands), so much so that they raise the command line size limit (ARG_MAX) in the kernel. I think it was around 2GB when I left. The internal frameworks really encourage using flags too, there's a @Flag decorator for Java that's sprinkled all over the code and sometimes nested extremely deeply down chains of classes that promote this behavior (abseil, (https://abseil.io/docs/cpp/guides/flags) has macros for this too).
So either they intentionally made -- be the none one, or they unintentionally ended up having it be that because the argument names are extracted from the strings and someone put an empty string for the none one.
It seems weird that it would be intentional though so my guess it was by accident. (For example separate people made the arg parsing thing from the person that put an empty string there.) I say it seems weird because conventionally many cli utilities use -- to mean end of arguments. For example so that an argument that is the name of a file can start with dash dash followed by something without being interpreted as a flag. And also so that a command that executes another can separate its own arts from the args of the command it is executing. Things like that.
https://github.com/torvalds/linux/commit/b6a2fea39318e43fee8...