> 33 million lines of code in total
Is that a fact? That seems insanely large.
Fixing a bug in Google Chrome as a first-time contributor
151–160 of 170 posts
Re: Fixing a bug in Google Chrome as a first-time contributor
#152> 33 million lines of code in total Is that a fact? That seems insanely large.
> That seems insanely large.
Browsers contain a lot of logic
Re: Fixing a bug in Google Chrome as a first-time contributor
#153Chromium's codebase isn't so bad for a first timer. Years ago our product had a bug on Windows where if you paste an image from the clipboard, the image had garbage in it (something to do with alpha channels). I realized Chrome has no such bug so they probably had a workaround. It took me like 30 minutes of lurking around in the codebase for the first time to find their workaround and apply it to our code.
last year I worked with js and chrome gave me a weird exception (I think it was something with websockets and ssl? I don't remember). I googled the exception, and found the exception in the chromium sourcecode and quickly found out when exactly that exception was triggered, and could then easily fix my js.
I too was pleasantly surprised how readable it was.
Re: Fixing a bug in Google Chrome as a first-time contributor
#154Earlier quoted context omitted.
From your post > 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 activel…
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.
[deleted]
Re: Fixing a bug in Google Chrome as a first-time contributor
#155Congratulations! 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…
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. # ctags command that indexes just Google's chrome code ctags -…
Don't know on what version of Sublime you are but the newest release has indexing built-in and it works really well.
Re: Fixing a bug in Google Chrome as a first-time contributor
#156Earlier quoted context omitted.
45 minute build for 32 million lines of code seems pretty reasonable, to me. What are some projects of equal complexity with lower build time in other languages?
There are no projects with equal complexity, let alone in other langs that im aware of
It's bigger than Linux?
Re: Fixing a bug in Google Chrome as a first-time contributor
#157Earlier quoted context omitted.
My point is that for engineers like myself, it's much easier to read code if I can also have access to debugging features. > 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.
Sure. Doesn't that depend on the complexity of the code you are looking at though? In many cases you can go through code, find the bit you are looking for and have pretty good idea of what it does. Which sometimes is all you need.
It's a tool. It's never required. Even for complex code. But it's helpful to some. Even for simple code.
Re: Fixing a bug in Google Chrome as a first-time contributor
#158Earlier quoted context omitted.
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.
If the browser name is referenced in multiple places, it seems to me that by defining it in one place actually increases the maintainability.
Re: Fixing a bug in Google Chrome as a first-time contributor
#159Earlier quoted context omitted.
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…
Why are you running your own fork, if I may ask.
Mostly for anti-fingerprinting features, but also just because I like to control the browser, since I spend all day in it.
Re: Fixing a bug in Google Chrome as a first-time contributor
#160Earlier quoted context omitted.
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…
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.
That looks something like this on Linux:
echo '{"DefaultBrowserSettingEnabled": false, "ExtensionManifestV2Availability": 2}' > /etc/chromium/policies/managed/default_managed_policy.json
At the moment, the only thing I can find in Chromium that uses that preference is some code that reports to Google on the impact of disabling Mv2.[1]
The other option is to follow their issue tracker and git history, and just revert whatever patches you don't like.
1: https://source.chromium.org/chromium/chromium/src/+/main:chr...