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?

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.

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.

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.

This confirms my thoughts after I tried messing with chromium's and brave's code bases.

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.

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.

# ctags command that indexes just Google's chrome code ctags --languages=C++ --exclude=third_party --exclude=.git --exclude=build --exclude=out --exclude=tools --exclude=mojo --exclude=base -R -f .tmp_tags ctags --languages=C++ -a -R -f .tmp_tags third_party/blink mv .tmp_tags .tags

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.

Chromium Code Search [1] tool is very helpful with that and I believe there are some extensions that integrate with it.

1: https://source.chromium.org/chromium/chromium/src

It's one of these things that Jetbrains products are vastly superior in. It's fast, always works, falls back to text matching and also natively allows multiple languages per source file.

Regardless, I think it's impressive that you've taken on this task and are sharing it with the VSCode community, and appreciate you sharing.

I use it all the time as an Android app developer. Its introduction was a big deal, because before that, it was common among Android developers to pull AOSP sources (all the many gigabytes of them) to one's local machine and just grep around.

it is not as good as the search built into Azure Devops [1] however. You don't know power search until you've used a search tool built on the backs of the devs of Windows. Being able to say "Uhhhh I know it was a macro called DeBeanIt2k near a comment with "HACK" in it" gets turned into "comment:HACK macro:DeBeanIt2k" and you get answers back is super nice. There's also an API for it.

1: https://learn.microsoft.com/en-us/azure/devops/project/searc...

I find this to be ideal when working with a large codebase. I don't even need an editor with fancy intelligence features and LSP integration; a bare bones vim or emacs paired with a website with all the intelligence already there.

Is this a serious question? Assuming it is, to insert printf statement, or attach a debugger and step through the program and take backtraces to supplement or confirm the information you gather from reading the code.

The OP's scenario is being curious how Chromium does something: so it suffices to find the relevant snippet and then copy it elsewhere. The Chromium code is assumed to be already working and does not need debugging.

To clear myself of any wrongdoing in regards to copyright :) They had a very nice comment explaining how the workaround works, and we used a different image manipulation library, so I couldn't, and didn't, copy it as is.

So not only it was easy to find the workaround in their huge codebase, they also explained it well so I could replicate it in our codebase from scratch.

> The Chromium code is assumed to be already working and does not need debugging.

Even if it doesn't need debugging, debugging features can help engineers understand the code better.

I too was pleasantly surprised how readable it was.

Every once in a while, the browser detects I'm typing "±±±±±±+..." and writes that to any selected text input. It stops when I type anything, but sometimes comes back rather quickly.

I thought it was a keyboard issue, but it doesn't affect Firefox or other applications, only Chrome based ones like Spotify and VSCode.

I've found no other mention of this on the internet and I'd love to to hunt this down and fix it but have no clue where to start. I guess the first step would be to consistently reproduce the bug...

If you're interested, I screen recorded it happening once. Mind there's music playing: https://youtu.be/S7OGTULLsqg.

Here's one! (different character, but same issue it seems?)

https://www.reddit.com/r/linuxquestions/comments/1cbarz5/ele...

> and I'd love to to hunt this down and fix it but have no clue where to start. I guess the first step would be to consistently reproduce the bug...

I am not familiar with Chromium at all, and I also don't run Linux on the desktop as I'm guessing from your video you do (?) so take this with a grain of salt...

I would start looking at the focus and key event handlers. e.g. maybe log the contents of pressed_keys and/or step thru the code from the beginning of the focus handler. It looks like this might be the place:

https://github.com/chromium/chromium/blob/01ab59ae08a38a361d...

https://github.com/chromium/chromium/blob/de351fd416ec36beeb...

Even if you can't repro it, you may be able to figure out the issue by just reading thru that code with some theories in mind. e.g. Since pressing another key seems to fix it, maybe look at what the code is doing there... my guess is the release event fixes whatever corrupted state it is in upon focus.

Seems like a race condition, and exacerbated by whatever kb you are using. Are you using a Corsair or Razer kb by any chance? And is it wireless or wired?

I know you suspected it may be a kb issue but have you tried swapping kb to make sure? I junked my old corsair kb because I thought it was just stuck keys after too many “kb smash” events. Don’t recall it happening again after swapping to diff manufacturer (Wooten, wired).

Interesting bug! Not exactly following on what triggers the bug. Do you have a ± key on your keyboard (some international one)? Or does it occur after e.g. pressing "+", then "-"? Do you use compose keys? Does it do this randomly?

I haven't been able to detect any pattern to what triggers this, at all. It is always "±".

I doubt that Firefox is better, I seem to remember that building Firefox and the VIA C3 processor years back as around half a day of compiling, but was also an extremely poorly choose CPU for the task.

Back in early 2000s a friend of mine was mentioning on IRC how middle clicking on a scrollbar in Mozilla under X11 didn't jump to the clicked point like in other X11 GUI programs. I was full into the Mozilla hype back then (the project was basically at its apex of coolness :-P) and wanted to get people into it, so i thought "this is opensource, right? I can do it myself and convince people how great Mozilla is".

Problem being, i had a Pentium MMX @ 200MHz with 128MB of RAM. It took at least six hours to do a build (most likely more, i felt asleep at some point during the night, then woke up ~5-6h later, was still compiling and i left to go out with a friend and was done when i came back some time later). Even if i didn't make a change and tried to recompile it took half an hour.

Fortunately i had already done some GUI programs by that point (and even tried to make my own GUI systems and toolkits) so i had a rough idea where to look and it didn't took too long to figure out the CPP file where scrollbar behavior was implemented (though it did take some extra hours).

I did submit it and remember being impressed by the process of having my patch to be "reviewed" and then "super reviewed", thinking that it now makes sense how Mozilla is of high quality (remember, i was a teenager big into the hype, everything was filtered through the most positive lens). FWIW i was asked to make a couple of minor changes but it was merged in.

I don't think i'd have as much patience these days, the last time i tried to build some relatively complex piece of software so i can contribute to it was with Krita, but that took only about an hour (including getting everything needed to build) - and it didn't work at the end (it built but crashed at startup) so i decided to try some other time as i had lost interest by that point to debug why it didn't work :-P.

Firefox builds are seemingly more modular. I was hacking on the Firefox devtools a while back, which from source involved downloading a pre-build main brower binary and building just devtools from your source. This made it significantly faster due to not having to build the rest of Firefox from source. Of course, this will all depend on which part of the source code you're changing.

Zotero has (had?) a really cool build system. Zotero is written on an Electron-like architecture, except it uses a Gecko-based runtime instead of Blink. (Firefox is the same way and has always been this way, and this predates not just Electron, but Chrome/Chromium, too.) Similar to the way that Electron apps' build scripts generally work by downloading a prebuilt Electron (rather than requiring developers build it from source), Zotero works by downloading a release build of Firefox, unarchiving everything, sweeping away all the XHTML/XUL/CSS/JS that comprises the Firefox UI and application logic, and then swapping in the components that make up Zotero. (In other words, just how it should work 90+% of contributors who want to submit patches against Firefox nightlies, too.)

But that's also not a requirement, either, that's just what it took for a 40 minute clean build time.

My personal machine is very mid-spec'ed because my personal projects are all small and don't really require much.

Even my work machine tops out at 32Gb RAM which has always been plenty, even for our comparatively large codebases (although more is always welcome :)).

I certainly wouldn't spend that for a one-off patch to an open source project, but if you're doing this regularly it's not exactly a steep upgrade either

That, it also means you are going to spend a lot of time on it before you can even attempt to do anything.

Overall, there can be a pretty substantial amount of effort involved before you are even ready to make a PR of any kind. Then it remains to be seen if it is well received by the people who can approve it.

You mention Firefox, my dealings with various contributors and people at Mozilla over the years would make me very hesitant to even consider diving into the deep end. To be fair, I have had good interactions with various people as well. But a lot of communication also has been just outright difficult.

All of this also throws out the "if you don't like it, you can just fork it" mindset.

> The phrase "patches welcome" has come not to be.

Which I am already missing context for to make sense out of. Where was this phrase used, by who?

I get a general idea of what it is about and what the intention is but it isn't all that clear as I am missing the surrounding context.

Around 6-7 years back, I was able to make a change & build Firefox from source on a mid-range gaming laptop without much fiddling. I think the build took may be around an hour or more and it was not too long to stand out.

I haven't tried building chromium to compare but from my past experience, Firefox's build was not too challenging for first time contributors.

For a long time I would build Firefox from source every morning, and I don't have the build logs anymore but I would guess it was in the range of 60 to 75 minutes. Comparing building anything on a VIA C3 is not serious, nor is using some 5400rpm disk for the same task

Wow, your rust experience is way different from mine (not just FF, I mean invocations of rustc are where time goes to die). I also readily admit that I struggled constantly with trying to get sccache to behave sanely, so I'm open to that being part of the difference, too

https://cs.chromium.org is the easy URL to remember ("cs" for "code search")

Nothing to be ashamed of, imo; printf debugging works incredibly well!

Also watchpoints, for the equivalent but at a memory location instead of a code line.

Debugger != breakpoints.

I used to work on Chrome and WebKit and I still have committer status. I've often wondered if there are people out there who would be willing to pay a contributor to get their bug fixed, but don't know who to contact. Feel free to email me :)

Anyway, just mentioning it to see if someone here knows if it's a well known and difficult to fix bug, or if it's just a bit obscure to have had any fixes for.

It took me a while to see these were different, I thought it was a wrong copy-paste.

Naming things is hard, but this is a bad convention. Always put the changing bits at the beginning preferably, or the end otherwise, but never in the middle, especially when it's subtle in a rather verbose name.

Worker and Worklet are primitives, you can't really split them up. You can't have a LetWorkGlobalScope and an ErWorkGlobalScope, so WorkerGlobalScope and WorkletGlobalScope is the best you can do.

That said, I usually prefer the changing bit at the end. So something like GlobalScopeForWorker, GlobalScopeForWorklet. But then that's clunky, so we're back at WorkerGlobalScope and WorkletGlobalScope again.

I wouldn't necessarily call "GlobalScopeForWorker" more clunky than "WorkerGlobalScope", just a bit longer, but also more descriptive.

Using the languages namespacing features might also make it more obvious, e.g. "Worker::GlobalScope" and "Worklet::GlobalScope" or the inverted version "GlobalScope::{Worker,Worklet}".

Looking at it from a functional programming perspective, I also like approaches of the form "GlobalScopeFor({Worker,Worklet})", i.e. a function returning the respective thing.

Naming things is hard, but the possibilities are endless...

I've done this and it's always ended up biting me in the ass when I want to auto-complete and have 9 million "GlobalScope..." to chose from. Which is where "Work..." becomes handy.

But that decision was made long before OP started contributing to this project.

Doesn't make too much sense to me, but I think that's what they are saying.

I don’t write code so that drive-by internet commenters looking at a random snippet always find it unmistakably clear in ten seconds, and I don’t expect anyone else to adhere to that standard.

I dug into the source and turns out they PNG encode it, I believe at highest compression. (The comments indicate this is something to do with how old versions of MS WORD handle transparency..?)

My "workaround" was to change the compression level to 0. Not ideal but I only needed to change 1 byte in the exe, and I was glad I didn't need to rebuild all of Chrome!

Firefox has 0 lag and has the benefit that you can paste directly into file explorer, because they put the original image file into clipboard instead of image data.

... turns out we do and I helped review that patch. Doh!

For how widely the clipboard is, the actual implementation (both in the OS and in the browser) is surprisingly unloved and unmaintained.

FWIW, Chrome intentionally doesn't plumb through the original image bytes. I wasn't around when it was initially implemented, but even for many years afterwards, there were no (Windows) platform conventions for passing around non-bitmap images on the (Windows) clipboard. And another (probably unintentional) benefit was "the encoded image bytes are from an untrustworthy source and could trigger bugs in buggy image decoders", while bitmaps are (relatively) safe in comparison.

Of course, this is a rather arbitrary line, because it's easy to get the original image bytes out of the sandboxed renderer, e.g. by dragging out the image or by saving the image.

At this point, someone could probably try plumbing through the original bytes or even implementing delayed rendering... but it's quite expensive in terms of time, especially to test all the random things that might break. :(

Similar to blaming the file for maintainers, the diff of those commits can direct you to their tests. The full patches that those commits belong to can also be useful for finding undocumented habits that have lead to approval.

https://stackoverflow.com/a/30998048

It completely escapes me how you can find that in such a codebase.

llvm took forever to compile, and then for some reason i needed to have two versions of llvm - i don't recall why offhand. So i have a devuan VM on my desktop here, i set up a gentoo chroot, updated it and installed distcc, installed distcc on the netbook - just like i've always done in these circumstances. Believe me when i say: it's still like magic, even if "distcc-pump" no longer works.

total time to get the netbook to a stable, running as i want it, useful machine - ~1 week. Results? It's actually useable - more usable than it was with windows 7 on it when it was new, and much more usable than whatever ubuntu i had installed on there 7 years ago or whatever.

I did, however, make a mistake. I didn't need to use i686 (32 bit) - the atom is a dualcore and on ark it shows that CPU is 64 bit. So i'll probably do all this again (after a reboot onto gentoo boot media and 'dd'ing /dev/sda2 to a network location, just in case). I may even see if it's possible to resurrect pump, because that will speed things up even more. If pump is working, the only thing that sucks about "emerge" on gentoo on a slow machine is waiting for the spinner at the beginning and the "installing ..." parts of the flow, due to memory and CPU contstraints. I'm using an SSD in there so at least i got that going.

These types of projects undergo constant code-change/refactoring/re-architecture etc. If you don't add a test for your specific issue, there is a non-trivial change that it'd be broken again in some future release.

Its somewhat worse if an issue gets fixed, and broken again, vs. it being broken the whole time. E.g. with the former users have likely started to rely on the fixed behaviour, then will experience disruption when it breaks again.

if the author doesn't want to do it, the PR will likely remain abandoned unless an external contributor comes along to finish it, or a maintainer takes over.

I had a similar experience when building Firefox from source >.<

though I recall I had more trouble when pulling the codes as I was naive and pulled all the history

Firefox took 2 hours to compile in my pentium dual-core Intel laptop, it was in August so warm inside the house, the 2 hours compiling at closer 100% cpu made the laptop halt due to excessive temperature before finishing. I also recall the build failed because of out-of-memory error (ram exhausted) I had 2GB and had to expand to 4 GB or something like that.

After overcoming the struggles I was finally happy as the fix was committed.

I personally never have been able to muster up the courage or energy to try and dive into the code base there, though. Part of that is simply because such a huge code base is daunting to delve into. But an even bigger stumbling block was always the prospect of having to deal with the entire process of submitting the fix and getting it approved. Certainly with Mozilla the interactions I have had on Bugzilla with various people there as well as in other places simply made me decide to work around the issues.

I am honestly surprised how relatively smooth the process seems to have been for the author, dealing with Chromium developers.

Can you elaborate on your experience?

What it mostly comes down to is that communication several times seemingly seemed a one way street. Where I provided information (often explicitly asked for) only to be effectively ghosted. Not in the sense that I was dealing with busy people where it just took time for them to get back to it again. But really getting no response at all. Often when I then did follow up on it (several months later) I would see the bugzilla ticket change a tag or some other meta attribute but nothing more.

To be clear, this isn't even unique to Mozilla/Firefox. I had similar experiences on other open source projects, although it differs really per project. It is more that with something as big as a browser, where setting up the development environment can already take up the better part of a day, it becomes an extra barrier for even trying.

My negative experience with Firefox was with this 6 year old feature request relating to container colors. [0] They have hardcoded some colors & icons (6 or 8 I think?) as possible options. The problem is: If you have more than half a dozen of Gmail accounts that you want to containerize (e.g. for client work), it is really hard to keep them apart at first glance. Compare this to Google Chrome, where you can choose the browser color for each associated Gmail account individually.

I tried to manually extend & build it for myself, but the codebase relating to that was just a mindfuck to work on...

    [0] https://github.com/mozilla/multi-account-containers/issues/1566

Too many times submitting a feature request or reproducible bug report in github that's "ranked by thumbs up" and then having that closed as wont fix.

Which is also worth something.

Chromium is open source, in my opinion, because Google can brag about open source, it has all the right buzzwords. But also gives them free R&D and labour.

I think given the size and wealth of Google, this is entirely inappropriate and people shouldn't be contributing to it, because it will only encourage this parasitic and exploitative behaviour.

So you would rather have chromium be closed source, or for people to fix the bug but hoard the patches? Do you hate the idea of google benefiting from your work so much that you're willing screw over yourself (in the form of having to maintain the bugfixes yourself) and others (because they don't get the bugfixes) in the process? Are you also against contributing improvements to other OSS projects (eg. linux kernel) because corporations might benefit from it and "gives them free R&D and labour"?

There certainly are OSS projects out there where the majority of work is done by volunteers and where companies profit from their labor. This isn't really one of them, at least not in the way you are describing it.

Applying one "truth" to the entire world generally means that you're simplifying things to such a degree that they become meaningless or even ridiculous parodies of themselves.

I feel like that this might be what you are doing here.

Yep. The way you do it on Linux is to grab your distro's package build script and use that. It will specify all of the build- and run-time dependencies (which you use your standard package manager to resolve), and contain whatever commands are required to build it. Usually you just install dependencies and run one command, and you've got a package you can install like any other.

Here, for example, is the script for Arch Linux's Firefox package: https://gitlab.archlinux.org/archlinux/packaging/packages/fi...

Just install the dependencies listed there, run "makepkg", and boom, Firefox pops out the other end. If you're doing active development, you can probably figure out a quicker change/build/test loop, but that'll get you started.

> but it's sounds like a nightmare on windows.

I wouldn't wish the hell of software development on Windows upon my worst enemy :)