Because of a situation with the Debian Iceweasel maintainers’ packages for the current release (18) on Testing (wheezy), I decided I could as well take this opportunity to try to install upstream Firefox in the cleanest fashion possible.
I have actually run upstream Firefox on Debian GNU/Linux (even Nightly, or Minefield back when it was called that) in the past on multiple occasions, facing various awkward desktop integration issues along the way. Additionally, the Firefox binaries had to reside deep within my home directory, which seemed a little tacky. But I just found out that this does not necessarily have to be the case.
While searching for information about installing the original-brand Firefox on Debian, I came across this forum topic and quickly worked out my way from the instructions presented there. I think I’m missing the OP’s context for the switch (Iceweasel 3.5 on squeeze maybe?), but that is not terribly important now, three years after the fact.
There are alternative guides floating around which advise adding foreign distribution repositories to your APT sources. Needless to say, this is a really bad idea unless you are very sure of what you are doing. (Hint: You are not.)
Many of the following instructions are pretty much the same as in the forum post, just adapted to account for some minor changes over time, as well as some personal preferences. I also find my version of this guide much more palatable in presentational terms. Additionally, I am particularly adamant about not changing anything in /usr for this procedure, preferring /usr/local instead in order to avoid package conflicts in the future.
If one takes any XUL (e.g. Firefox, Thunderbird) application and tests it against Gtk+ theme engines or color schemes other than the Ubuntu defaults, various design shortcomings become evident, including things such as the developers’ inability to choose a toolbar icon set for Linux/X11 that doesn’t become uncomfortably unreadable against bright backgrounds.
I have to apologize for not doing the research on the icon part of this particular statement. It turns out this isn’t Firefox’s fault; it is just using the platform icons as it’s supposed to do on Linux/X11 since version 3.0 or so. So where do these icons come from? Let’s take a look at chrome://browser/skin/browser.css:
Since I use the Oxygen style in KDE for Qt 4 applications, I have set Oxygen Gtk for Gtk+ 2 and Gtk+ 3 applications, so those applications will use the Oxygen icon theme as well. But checking /usr/share/icons/oxygen/16x16/actions/, there are no files named gtk-*.png like Firefox wants. So it must obviously be using icons from the GNOME theme instead.
Mozilla’s decision to have Firefox use native icons on X11 seems questionable to me, since it breaks cross-platform consistency and tends to look like crap (compare Firefox on Windows, even on XP). But the actual bug here is quite clearly not theirs. The icons in question come from the gnome-icon-theme (3.4.0-2 installed) in Debian, and according to its copyright file:
One would think these people know better than this since there are other popular Linux distributions out there using bright color schemes by default, such as Fedora. The good thing about colorful icons is that they are generally designed to stand out regardless of the background color; it’s quite hard to achieve the same effect with monochrome designs.
I could not bear using Chromium for a week as I originally intended. All right, I admit I always intended to go back to Firefox, but the whole exercise didn’t go as planned for various reasons.
The thing is, I have always used Firefox since version 1.0 or so and it has basically become part of my personal life — it’s impossible for me to stay mad at it for too long after all we have been through together.
Nothing of this renders the points I previously raised here any less valid, but I have coped with those annoyances for a good while already — let’s not get too demanding in the usability department here, otherwise I may as well invest a zillion dollars in Apple products right now.
Besides, Chromium insists on taking up preposterous amounts of CPU time in the background every once in a while, even after getting rid of a certainbug with the Linux kernel and leap seconds. Despite all its inefficiencies, I have never seen Firefox indulge in such erratic (and potentially harmful for laptops) behavior like that while idle. I already did my best to diagnose the issue, but I never had that much interest in using Chromium as my primary web browser in the long term anyway. After all, I am a KDE user, which means I like options — the Chromium design philosophy is more or less the antithesis of that, and it shows.
There’s also these twoseemingly minor annoyances, and this — which makes more sense if you take this (from about 10:58 hours earlier) into consideration.
Not to mention that there’s no Chromium add-on providing a Bookmarks menu that looks nice, probably due to the previously mentioned design limitations. It’s also somehow more natural for me to have the Home button at the right end of the toolbar, but this might just be Firefox inculcating habits.
Going back to Firefox, it does seem like resetting its configuration and clearing all of my old web history before March 2012 improved overall performance. In case someone else wants to try resetting their own configuration:
Backup your profile or the whole .mozilla directory (on Linux/X11, no idea about other platforms);
Go to the about:support page, and choose the Reset Firefox option;
Follow the instructions on the screen to create a new profile preserving your browsing history, bookmarks, cookies, and saved passwords.
When done, you will be left with an additional copy of your old profile that might or might not still work — I didn’t check this. You can start Firefox with the -P switch to see the previous profile, and possibly delete it after you are done making sure all the information you need is present in the new one. You will lose all your installed add-ons, their configuration, and your browser preferences; this is pretty much the whole point of the procedure.
I for one had accumulated heaps and heaps of unused or obsolete configuration entries (both from add-ons and old Firefox versions) carried over since late 2008. That can’t possibly be healthy, especially considering that I have tried many, many add-ons and hidden configuration options over the years, and used pretty much all versions since Firefox 3.0.
It’s probably more important to keep the web history under control, though. Older versions of Firefox—if I recall correctly—had a user-visible option in Preferences to limit history to a given amount of time, but that doesn’t seem to be the case as of Firefox 13 and it’s all or nothing. Of course, it’s also possible that the current defaults do limit history and there simply isn’t a way to change that limit anymore; so if I ever changed it with a previous version, it would have become inaccessible to me later short of using about:config.
For more than a year I have been actively avoiding the web browser that all the cool kids use these days. I’m obviously talking of Google Chrome.
For all its excellent performance and ease of use, I kept being bothered by its insistence on breaking the mold and looking like a completely different thing running on my Linux system, instead of behaving like an application blending with its environment. I think it was this big annoyance that kept me from adopting it as my regular web browser for all this time. But compared to Mozilla Firefox, I think there’s just no matter of dispute anymore. Chromium/Google Chrome keeps getting better, and Firefox is stuck in the noughties, much like an evolutionary dead end in the history of fail web browsers.
It’s not entirely unexpected for me, but it’s the kind of news one hopes to never find in his front door, like a car-bomb if you will. If this goes ahead I can imagine that less and less time and human and economic resources will be spent on the Mozilla Firefox proper for the PC, once B2G catches the OEMs’ attention.
I guess it’s time for me to accept (again) that Firefox has ultimately become the open-source Internet Explorer.
And here it is, at last. Just like the last time, the new version migrates from Aurora to Beta on Tuesday but it isn’t offered via the update channels until the next Friday, while the newer ex-Nightly is published in Aurora in the meantime.
I still think this is unnecessarily awkward for users who are interested in one specific Firefox version, or who want to avoid disabling incompatible add-ons as much as possible.
With Firefox 7 entering Aurora now, I’m in a slightly uncomfortable position because I hoped to continue tracking version 6 once it moved to beta — now I’m using an old version 6 snapshot from Aurora hoping that the beta will be packaged and announced soon.
It seems somewhat inconsistent from my standpoint to let Aurora be replaced by a newer version before the previous Aurora is properly promoted to Beta.
Interestingly, the same situation appears to have occurred with the announcement of Firefox 5 beta in May, the difference being that I didn’t particularly mind because it was in preparation for the first official release after Firefox 4 and the decision to switch to a rapid release schedule, so a little schedule slip was to be expected for an initial deployment.
The announcement that Mozilla was switching to a “rapid” release cycle did not entirely catch me by surprise back in the day. With the advent of Google Chrome to rekindle the fire of the Browser Wars a couple of years ago and its significant contribution to the general adoption of HTML5, I knew Mozilla Firefox 4.0 would have little to offer that wasn’t already the standard in Chrome.
It’s kind of sad to see those who were once pioneers in open-source web technologies development — in no small part thanks to Microsoft Internet Explorer and the death of the formerly glorious Netscape Navigator — now relegated to following in the footsteps of the youngest actor in the market, an actor which really just took Apple’s Webkit library as a building foundation and released the resulting project under one (if not the one) of the most recognizable brands of the Internet.
Whatever rules Mozilla Firefox follows to determine the user’s default email client don’t seem to work properly on Debian, at least not when GNOME is not the desktop environment originally installed. For whatever reason, what Firefox tries to do with mailto links and the Send Link context menu option is to open the Evolution mail client, which is not installed with the KDE or LXDE desktop environments.
Fixing this is supposed to be trivial, and it is, but the relevant option is hidden in the worst possible place in Preferences.
Chromium/Google Chrome does not have a user-accessible setting for this, but somehow still appears to get the right idea from the desktop environment.