Congratulations! And thank you for the great write-up. I work with the Chromium code base a lot, and it can indeed be daunting. I use Sublime Text, which treats the code as plain text, apart from syntax highlighting. But it's also possible with at least VS Code to get some more intelligence, such as going to the definition or declaration of a function, etc.
People who have now become interested in creating their own Chromium-based browser may want to take a look at my article: https://omaha-consulting.com/how-to-fork-chromium. It gives a high-level view of what goes into maintaining a Chromium fork.
> you will (...) want to change the name of your browser [to] "Browser of Bliss" instead of as "Chromium". You will find that this is already hard to do. The browser name is hard-coded in many places in the millions of lines of Chromium source code. (...) Viasat are offering a (...) fork called Rebel that makes this easier
I am surprised that kind of change has not been upstreamed, or is Google actively working against forks?
It’s just the kind of thing that happens in a huge, production codebase.
There are plenty of reasons to be skeptical of Google, but some strings in multiple places isn’t a good reason to be skeptical of the Chromium maintainers.
I know it's naturally happening in a large codebase, I'm asking why they specifically maintain a fork just for that instead of trying to push what are probably easy (but tedious) upstream fixes.
Purely guessing: abstracting a browser name is yet another abstraction layer. A later that is not needed by chromium. Maintainers of chromium primarily care about maintainability of chromium, not other forks.
They could not accept those changes without being actively against forks. It would just mean they aren't actively supporting forks, which is a different thing.
It depends on the individual part of Chromium. Some teams seem to be much more open to contributions than others. (I believe to recall that this is also what someone at Viasat told me at some point, but I'm not sure).
Also, for example the browser name appears in a lot of places. It is very hard to fully extract it into a single configurable option.
>So how much does it cost to maintain a Chromium fork?
>It obviously depends on the number of customizations your browser has, and on how quickly you want to incorporate security fixes from upstream. Chromium is one of the world's most complex pieces of software, and you need very capable engineers and powerful hardware to match this. It is going to be expensive. And not just once, but also on an ongoing basis.
This confirms my thoughts after I tried messing with chromium's and brave's code bases.
I dunno, I've maintained a personal fork since around Chrome 100 or so. I am only targeting builds on Linux, I don't care about branding, and my patches are limited to about 300 lines total. The initial fork and figuring out the build process took probably 20 hours. After that, I've only had to spend on average around one hour per release of "engineering time" to keep my patches current. The build takes about an hour of machine time on my 5950x.
I'm not saying it's trivial by any means, but I don't think it's outside the range of a motivated hobbyist or a small startup. I don't think you really need "very capable engineers" personally. I barely know C or C++ and I haven't had too much trouble working with the codebase.
What kind of changes have you made with your patches? Did you make them yourself? I wanted to locate the code responsible for chromium's manifest v2 support so I could patch it back in once it's removed but I just couldn't get very far.
Manifest v2 is a bit tricky, because there are really three changes overlapping with each other:
- Manifest v3 site permissions changes
- Removal of protected APIs (like the blocking version of chrome.webRequest)
- Chrome Store code review changes that prohibit remotely loading sources
For now, you can either do nothing (as the rollout is not yet complete), or set the ExtensionManifestV2Availability policy to 2, which will still allow Mv2 extensions to be loaded.
>The other option is to follow their issue tracker and git history, and just revert whatever patches you don't like.
Yeah, the first thing I tried was to look at the issue tracker but as you stated they haven't rolled this out yet. So I tried to find the code myself.
Google's documentation didn't really help that much for this and seemed to be outdated in many sections. So I went and tried to do some experiments on places that seemed like they may have something to do with extension APIs.
I remember there was some build generated code that I was looking into because it related to the extension APIs but I was never able to test my guesses very well since my machine is not super fast and compiling takes so long. So eventually I threw in the towel.
I was a C++ Chrome developer till 2020, and I primarily used Sublime Text because of speed, and I found VSCode weekly releases too distracting.
I indexed code locally with CTags, and then used SublimeText CTags extension for navigation. This worked great for my local branches. When I needed to dig deep, I'd use source.chromium.org which indexes perfectly.
I am not sure if built-in indexing supports only indexing subset of the tree. YOu want to selectively index for speed and accuracy. The complete tree might contain multiple definitions of the same functions, as headers get copied, pre-processed, etc.
It supports selective indexing, you can specify paths to exclude from indexing or you might open just a single module, here is more info: https://www.sublimetext.com/docs/indexing.html
Reminds me of my early experience with larger-scale JS development (early single page apps or whatever they're called now); there were no good IDEs yet, no module / require system, no types or whatever. Sublime Text and fast global search were my go-to tools, and it gave me a newfound appreciation of consistent naming schemes and structures.
Not so much nowadays though, most of the time I use IDEA with Typescript and the like. And yet, I still feel like I lost something moving away from sublime. I've reinstalled and am trying it again lately.
Sublime Text has had some IDE-like abilities even before the LSP plugin, because its own filesystem code indexer reuses the syntax-highlighting language grammars to power best-effort goto-definition / goto-references functionality. How well that actually works varies by language.
For Chromium IntelliSence at least in the form of VSCode plug-in works pretty much out of the box with recent releases of VSCode. It is not as precise as clang LSP but the latter can easily consume over 10GB for Chromium.
People who have now become interested in creating their own Chromium-based browser may want to take a look at my article: https://omaha-consulting.com/how-to-fork-chromium. It gives a high-level view of what goes into maintaining a Chromium fork.