Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cprimozic.net

Post reply on HN
Print view View original

101–110 of 170 posts

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

#101

Post by henning »

trustno2 wrote: post #94
henning wrote: post #81

Earlier quoted context omitted.

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.

It's not searching plaintext though. VSCode itself can deal with big text data being thrown at it, this will be some of the language server stuff

I'm glad VSCode handles large text files better for you than it does for me. Editing anything large in VSCode makes it slow to a crawl on my machines.

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

#102

Post by henning »

coldpie wrote: post #84
henning wrote: post #81

Earlier quoted context omitted.

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.

You're assuming that the only way to a definition of an identifier is 1) parse the entire source tree 2) keep the entire source tree in memory 3) use that in-memory source tree to go to definition. If you accept those constraints and then implement in a slow language, then yes, it won't work.

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

#103

Post by bfgeek »

ramshanker wrote: post #95

Excellent. One small question If anyone can answer. When an outside contributor is submitting a fix like these, do open source software maintainers ask for test also to be written? Fix itself is worth acceptance. What if contributor don't have any more time/interest beyond submitting the fix.

It depends on the project, but most large scale projects require test(s) for the fix, and will block submission unless its provided.

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.

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

#104

Post by seanthemon »

cryptonector wrote: post #88
Suppafly wrote: post #73

Earlier quoted context omitted.

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?

Buggy malware is jusy a feature

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

#105

Post by kllrnohj »

mrweasel wrote: post #15

Not that I really see away around it, given the size and feature set of Chrome, but those build requirements are just crazy. It kinda throws the open source and "everyone can contribute" model out the window, if you can't afford a pretty insane workstation then you're going to have a bad time. I doubt that Firefox is better, I seem to remember that building Firefox and the VIA C3 processor years back as around half a…

16 core CPU, 64GB RAM, and 100GB of storage is definitely not a budget build, but I don't really see how that would be a "pretty insane workstation", either. That's firmly in consumer space these days and has been for a few years.

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

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

#106

Post by frou_dh »

Cthulhu_ wrote: post #16
mherrmann wrote: post #10

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…

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…

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.

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

#107

Post by mordnis »

phil294 wrote: post #92
macqm wrote: 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…

I've been working on an extension https://github.com/phil294/search-plus-plus-vscode-extension for instant search results in gigantic repos like this one because it's a recurring pattern that bothers me. And eventually I'd like it to use its index to provide full go-to, autocomplete etc. on a pure plain text basis, because why not? I don't get the obsession with full-fledged language integration when plain text-based…

Is it something similar to ctags? https://github.com/universal-ctags/ctags

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

#108

Post by dieortin »

skobes wrote: post #82
kgeist wrote: 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.

I’m pretty sure that code search webpage is the external facing version or Google’s internal code search, which they use to index their huge internal monorepo, so it makes sense that it works well.

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

#109

Post by andai »

I noticed in Chrome based browsers that when I copied an image to clipboard, whole UI would freeze. For large images it would become unresponsive for 5-10 seconds.

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.

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

#110

Post by cxr »

creesch wrote: post #100
cxr wrote: post #70

Earlier quoted context omitted.

"Patches welcome" vs "patches wanted"[1]. 1. https://www.colbyrussell.com/2013/08/06/patches-wanted.html >

That little snippet doesn't quite provide enough historical context for me to agree or disagree with it.

Huh?
Post reply on HN