The case of the disappearing favicon | Hacker News Reader

The case of the disappearing favicon

kilianvalkhof.com

39 pointskilian10 comments

I think this post is indicative of a problem that arises when a project such as firefox becomes too big. Sure, it is an open source project, so it is nice that you can file a bug report if you discover a shortcoming like the disappearing favicon.

But the author of the blog seems to be a programmer himself. Ideally, he would not only file a bug report but - since the bug seems to bother him a lot - perhaps even come up with a patch.

Instead, he writes a work-around -- and can you blame him? Compared to a two-line function, the work required to dig into a huge code base, try to understand it, come up with a patch (that doesn't break anything else), get the maintainers to integrate it, etc... seems enormous. Well, perhaps it actually isn't, who knows, but I can understand that people feel too inhibited to invest time to come up with a patch if the required effort seems so overwhelming from the start.

It appears to me that this is a general problem, and the bigger the code base, the worse it gets. Yet at the same time, the overall benefit of submitting a patch rather than coming up with workarounds grows with an increasing user base, because more people are positively affected. So I wonder if there are any realistic methods to cope with this problem: how can open source projects get people to provide more patches?!

Fixing the bug may require platform and domain knowledge way beyond the skill set of the person submitting the bug

Things like this make me wonder why anyone would want to write a huge project (like Firefox) in C/C++. I can understand wanting to re-use some legacy code, or perhaps the need for a few bits of optimized, low-level code where you really need the performance...but why not write the majority of the code in something like OCaml? I know there aren't as many good OCaml (for example) developers out there, but I'd bet that the end result would be just as fast (or faster) than the C/C++ version and have way fewer bugs (thanks to the strong type inference and succinctness of the code).

If Firefox were an OCaml project, it would have likely died before hitting 1.0.

Also, I've never used OCaml, so maybe I'm wrong here, but I highly doubt it's faster than C.

I'm not a C++ fan myself, but I think the complexity problem with Firefox is its various bits of internal infrastructure more than the language--- XUL, the rendering engine, custom string libraries, and a whole bunch of FooManagers and other custom interfaces intended to allow all the parts to be plugged together. The only thing I can think of offhand that a change of language might fix would be that a move to a garbage-collected language might allow for ripping out some of the FooManagers dedicated to allocating/tracking/freeing memory.

It also took them a few years to include the patch for HttpOnly (proposed in 2002, implemented 2008).

Really strange how long some things take to fix in Firefox, I wonder if it's politics or apathy, impossible to tell.

Out of curiosity, why would one set window.location.hash?

In order to maintain the usability of the URL in a heavily AJAX application.

For example, with movielandmarks I designed it so that you don't use back/forward at all. But I wanted to provide a useful URL for bookmarking and sharing with friends. So I used the hash for this because changing the actual URL of the page forces a refresh.

To save some state of your JS application which can be saved to bookmarks (or copy-pasted to someone else). For example, Gmail adds "#sent/12aa04feebaac50e" when I open an e-mail I just sent. Also, to get the "back" button to work properly in JS applications.

One more reason for me to keep using Opera. Thanks.

Reply on news.ycombinator.com