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

161–170 of 170 posts

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

#161

Post by cxr »

creesch wrote: post #146
cxr wrote: post #110

Earlier quoted context omitted.

Huh?

The thing you linked starts with > 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.

K. To start with, it's been a common phrase in open source since before "open source" was invented and fairly self-explanatory; it means what it means on its face. Even if that weren't the case and someone were just encountering it for the first time in 2024, a 2-second attempt to get acquainted will not leave anyone wondering.

There are 200 results for "patches welcome" on HN:

https://hn.algolia.com/?dateRange=all&page=5&prefix=false&qu...>

The top results on Google for the phrase "patches welcome", most being posts written around the 4-, 5-, 6-year mark after the post I linked to, are all based on the same premise: "patches welcome" is (a) common, and (b) not what anyone wants to hear.

https://www.google.com/search?num=100&q=%22patches%20welcome...>

E.g.:

> "Patches Welcome". We've all seen it in the Open Source community. Nothing makes me angrier than these two words.

https://fy.blackhats.net.au/blog/2016-02-17-patches-welcome/>

But I'm also missing some context here; my "Huh?" was rather more directed at the part of the remark that says "[...] for me to agree or disagree with it".

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

#162

Post by bobajeff »

aftbit wrote: post #160
bobajeff wrote: post #139

Earlier quoted context omitted.

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, whic…

Thanks for your advice.

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

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

#163

Post by atotic »

sevnin wrote: post #155
atotic wrote: post #141

Earlier quoted context omitted.

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.

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.

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

#164

Post by mccr8 »

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…

Firefox uses unified builds, where a bunch of .cpp files are globbed together and compiled at once. That helps a lot, but a build still takes a bit of time unless you are on an absurdly fast machine. Chrome used to also support this, called "jumbo builds", but they didn't want to deal with the maintenance overhead. Presumably all of the Chrome developers employed by Google are using some kind of massive distributed build infrastructure so there's little impact of slower builds on individual developer productivity, so the use case of building on a single computer is not as prioritized.

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

#165

Post by mananaysiempre »

mananaysiempre wrote: post #130
henning wrote: post #102

Earlier quoted context omitted.

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.

You’re rather underestimating the vast expanse that is the Chromium codebase, I think. That said, distributing tags files was a common thing once, and a dedicated symbol package you could just download and feed into your language server (instead of being constantly tethered to a symbol server) could make for a nice affordance today.

So this actually exists, as it turns out. You can run clangd-indexer to produce a static index and then load it with clangd -index-file. The caveat is that

> [r]unning clangd-indexer is expensive and produced index is not incremental.

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

#166

Post by dankwizard »

RexM wrote: post #142
dankwizard wrote: post #137

Earlier quoted context omitted.

When you sit down at the dinner table, do you have your own fork or share one with the guests? Exact same logic applies.

Because you don’t want to share germs with other users of the browser? The logic makes no sense and I honestly can’t tell if you’re joking.

People on this website often have difficulty detecting sarcasm, you're not alone.

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

#167

Post by sevnin »

atotic wrote: post #163
sevnin wrote: post #155

Earlier quoted context omitted.

Don't know on what version of Sublime you are but the newest release has indexing built-in and it works really well.

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

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

#168

Post by trustno2 »

henning wrote: post #101
trustno2 wrote: post #94

Earlier quoted context omitted.

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.

Interesting.

The only time I had problems was very big JSONs with everything on one line, but prettifying fixed that. (Or was it XML? I forgot. One of those.)

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

#169

Post by filcuk »

throwaway35023 wrote: post #158
poincaredisk wrote: post #56

Earlier quoted context omitted.

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.

I think what they're saying is that Chromium will remain Chromium, so maintainers have little incentive to worry about this
Post reply on HN