Live data from Hacker News

Fixing a bug in Google Chrome as a first-time contributor

cprimozic.net

81–90 of 170 posts

Re: Fixing a bug in Google Chrome as a first-time contributor

#81
post #79

>Because of this huge codebase size, I wasn't able to get VS Code's C++ extension to work very well with the project. Features like go-to definition (which I usually rely on heavily when navigating codebases) and find references didn't work well or at all, and one of my CPU cores would stay stuck at 100% permanently while the project was open. Chromium Code Search [1] tool is very helpful with that and I believe ther…

First, thank you for sharing this helpful link, but LOL at needing to use a third party server to search plain text data that could fit in RAM (at least on this developer's machine). JavaScript- and JSON-based developer tooling is a terrible idea.

Re: Fixing a bug in Google Chrome as a first-time contributor

#82
post #40

Chromium'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.

One thing Chromium does really well is hooking up cross references in the code search tool (source.chromium.org). This makes it easy to browse, see where things are called from, subclassed, etc. Github feels far behind on this.

Re: Fixing a bug in Google Chrome as a first-time contributor

#83

This is great! You should consider fixing the Chromium bugs you run into! Chrome releases relatively quickly, so in 4-6 weeks you can have a bug fixed forever for all of your users on Chrome. 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…

There is an annoying bug in Chrome DevTools that people who want to impede debugging of their JS files exploit. I think it's probably related to making the regex engine use excess memory and crashing the tab. 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.

I haven't seen that one. I'd start by searching crbug.com. Then, the first step to a fix is always to find a reproducible example of the bug. In this case that would probably be finding an example in the wild and trying to save it locally in a way that still reproduces the bug. If you can get those files attached to the bug report there's a good chance it can be fixed. When I was fixing Chromium bugs, repro cases were worth their weight in gold.

Re: Fixing a bug in Google Chrome as a first-time contributor

#84
post #81
post #79

>Because of this huge codebase size, I wasn't able to get VS Code's C++ extension to work very well with the project. Features like go-to definition (which I usually rely on heavily when navigating codebases) and find references didn't work well or at all, and one of my CPU cores would stay stuck at 100% permanently while the project was open. Chromium Code Search [1] tool is very helpful with that and I believe ther…

First, thank you for sharing this helpful link, but LOL at needing to use a third party server to search plain text data that could fit in RAM (at least on this developer's machine). JavaScript- and JSON-based developer tooling is a terrible idea.

I'm sure it can do a plaintext search just fine. What the author is talking about is language-aware features like "go to definition". Holding all of a whole web browser's C++ parsing tree in memory is a lot bigger ask than just its plain text.

Re: Fixing a bug in Google Chrome as a first-time contributor

#85
post #41

> I'll unashamedly admit that I made liberal use of printf debugging while trying to make my way through these code paths Nothing to be ashamed of, imo; printf debugging works incredibly well!

Yep. Debuggers are more powerful , they can do everything `printf` debugging can do + more, but take more work to set up. For interpreted languages, they often take more work to use than just adding a print statement & rerunning, for compiled languages the reverse is more likely.

There are cases where printf helps but debugging doesn't. Multithreaded code is one of such cases.

Re: Fixing a bug in Google Chrome as a first-time contributor

#86

> Although the worklet was running on a worker thread, it didn't have a WorkerGlobalScope - it had a WorkletGlobalScope. 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.

These names come from the html spec: https://html.spec.whatwg.org/#workerglobalscope https://html.spec.whatwg.org/#workletglobalscope

Chromium (and most other browser engines) will use the specification names for things like this. E.g. equivalent code in WebKit, and Gecko: https://github.com/WebKit/WebKit/blob/80c1e6d05e4679c08e3a6e... https://searchfox.org/mozilla-central/source/dom/worklet/Wor...

Re: Fixing a bug in Google Chrome as a first-time contributor

#87
post #58

There's this one Chrome (?) bug I've been experiencing for a long time on Linux. 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…

That's... horrible.

Re: Fixing a bug in Google Chrome as a first-time contributor

#88
post #63

Earlier quoted context omitted.

I don't have a ± key. I'm using swaywm which seems to have no compose key set by default, I've tried all the common ones and they don't act as such. I haven't been able to detect any pattern to what triggers this, at all. It is always "±".

You could probably set up some keylogging to see if anything special is happening before it, it'd also let you know for sure if it's a keyboard issue or not.

Maybe there's buggy malware involved?

Re: Fixing a bug in Google Chrome as a first-time contributor

#90
post #79

>Because of this huge codebase size, I wasn't able to get VS Code's C++ extension to work very well with the project. Features like go-to definition (which I usually rely on heavily when navigating codebases) and find references didn't work well or at all, and one of my CPU cores would stay stuck at 100% permanently while the project was open. Chromium Code Search [1] tool is very helpful with that and I believe ther…

It's also possible to get go-to-definition etc working in VSCode locally. You need to switch from Microsoft's C++ extension to the clangd extension. Clangd scales better and is more accurate for projects using clang like Chromium. Instructions here: https://chromium.googlesource.com/chromium/src.git/+/HEAD/do...

The Chromium code search site is still very useful too.

Post reply on HN