UPDATE (2014-05-26): I've finally given up on Firefox; this is a sad moment, since I've been using it and its predecessors for many years. But Firefox has one or more deeply embedded bad bugs which cause scripts on many websites to run uncontrollably. Even with a clean, new install of Firefox 29, in short order it is consuming 80+ of the CPU ordinarily and well over 100% (on a multi-core system) in many cases. It's bad enough that cursor movement becomes jerky. If you search around, these problems have been reported for years, but the FF developers just deny them. Unfortunately, they've now caused performance to degrade to an unusable level. See the Packages -> Net/Web section for workable replacements. I'll leave these "Fixing Firefox" notes here, but they are no longer useful. Firefox must fix itself before you can fix it.
(This present Notebook discusses solutions for flaws in Firfox as installed. For installation notes and for the identification of the two absolutely necessary Firefox plugins (NoScript and "Disable Ctrl-q"), see ../ Packages --> Net/Web (Firefox))
For an index of Arch Linux browser-related topics, see: https://wiki.archlinux.org/index.php/Category:Web_Browser
Firefox is comprehensive, but increasingly bloated. It may well be worth considering other browsers (such as Midori). On older or less powerful systems you can no longer run Firefox at all - it simply consumes too much system capacity.
But if for no other reason that the "NoScript" addon, Firefox remains the leading candidate for a browser in a system which can handle a heavyweight application. It's also obviously better than the two big commercial browsers (IE and Safari, which won't run in our environment anyway) and the other heavyweight contender (Konquerer). And, yes, I've tried Chrome (but not Chromium); I regretted the experience.
To turn off the annoying URL suggestions that now by default disfigure new Firefox blank tabs (and violate your privacy), go to the "about:config" URL, search for the "browser.newtab.url" item, and change its value "about:newtab" to "about:blank".
First, it is always necessary to change the default Firefox behavior in its regular interactive configuration ("Preferences") to force it to ask you where to save files. If you don't do this, it will save them to a single "Download" directory. You then have to go in and manually move them to their proper location in your filesystem. Required manual intervention of this kind is a deliberate waste of your time.
At some point (I haven't bothered to track down the point at which they introduced this "feature" (that is, bug)), Firefox changed the behavior of its file saving mechanism so that it guessed the location in your filesystem at which you wished to save a file. This means that each time you go to save a file, the location that you're at in your filesystem can change.
Rather obviously, the violates the basic principle that a user interface should present a consistent view to the user. What makes it worse is that in my experience (saving many hundreds of files - I do a lot of web-based research) it often not only guesses wrongly but differently for successive downloads. So let's say you're downloading five or ten items from a site. They should all go in the same place in your filesystem. You navigate through the filesystem to pick the location to which they should be saved. You save the first one; fine. The process of saving the rest is repetitive and should not require much mental attention: click, save, repeat. But by the tenth one suddenly you discover that Firefox has changed its idea of where it should save these files and is saving them someplace else entirely. Worse, it may well have saved some of the middle ones in other locations.
This means that for every single download you have to remember to check carefully to ensure that Firefox is still saving files where you just told it to save files. If you don't, you may well have to go back and do it all over. This is an affront to all good user interface design.
Fortunately, since Firefox 11 it has been possible to disable this [expletive deleted] behavior and restore consistent behavior. Unfortunately, this configuration is hidden in a poorly documented configuration line which doesn't even exist in a default installation. To fix this problem:
(Note the capitalization in the above; it's important.) This probably won't exist, so you'll have to create it. It should be of type "Boolean". To create a new "about:config" entry of this type, right-click anywhere in the window and select the "New" -> "Boolean" option. Enter "browser.download.lastDir.savePerSite" as the Preference Name. We want to disable the "save per site" behavior, so set its value to "False" in the next window.
For more information on how to use the Firefox "about:config" mechanism, see http://kb.mozillazine.org/About:config
For more on this bug and its fix, see (for example): https://support.mozilla.org/en-US/questions/922886
It is interesting to compare this Firefox "save per site" bug (I call it that because, while a feature it is a clear violation of the principle of consistency in user interface design) with the disappearance of the basic UNIX concept of the Current Working Directory from GTK .
Both "features" were well-intentioned, and both came from the same basic impulse: to guide the user to what an omniscient system believes they should do rather than to show the user what is in fact present in their system. (The reason that this sounds Orwellian is that it is Orwellian.)
But the situation with replacing the concept of the CWD in GTK with an oracle's eye view of "recently used" files is much worse than Firefox's "save per site" problem. GTK-based applications such as the GIMP which lost the CWD in their FileChooser are working within a filesystem and by their nature are directed inward toward that file system and its organization - toward the structure of information that the user has created and lives within. Eliminating the basic concept of the CWD is a direct attack on the user and is crippling.
Firefox is of course a GTK application, but fixing the GTK CWD bug doesn't actually help us here. With, say, the GIMP we're using a tool within the context of our own working environment (the filesystem). You're at a particular place in the filesystem, and when you fire up the GIMP it really matters that the GIMP knows where you are. Otherwise it's like having to drive to the hardware store every single time you need a different wrench.
A web browser such as Firefox, by way of contrast, looks outward. We're looking out at the world. When we discover something that we wish to save, there is little reason to believe, a priori, that Firefox was started in the place we wish to save it.
So adding an option whereby Firefox might suggest a place to save something you download isn't all bad. Sometimes it guesses correctly (and it's kind of neat when it does). If this had been presented as a second option, right after the previous location, then it would have been fine.
There is a concept analogous to the concept of the CWD in saving files from the net: the last location you saved to. This is always known, and is only changed explicitly by the user. It necessarily presents a consistent file-saving interface.
One of the principles of all good software is that it must be correct first, and fancy later. (This is one of the principles of Arch Linux, but it is a part of the very nature of good software - and is rare today.) There is an analogous principle in user interface design: it must be consistent first, and can be fancy only later.
The consistent (and therefore correct) behavior in GTK is to use the CWD, and in Firefox is to use the last directory saved in. GTK's "recently used" and Firefox's "save per site" behaviors are at best fancy additions.
As of Release 20, running on an older Kubuntu 11.10 system (yes, I know that this is quite old as I write this in 2014 - a whole comple of years) the autocompletion of both URLs and text-box fill-ins in Firefox quickly became so slow that it would routinely drop characters. You often had to wait a full five seconds between individual keystrokes. This is behavior that would have been unacceptable in 1950. To find it in new software over 60 years later is appalling.
In Firefox 15 (at least, maybe slightly earlier) fragment URLs (the ones with "...#location-in-file") of at least the "file://" type lose the after-the-pound fragment when they include a filename which is a symbolic link. The hyperlink, which now no longer has the #fragment location within the page, just takes you to the top of the page. This is newly broken behavior (it was correct in all versions through at least 13). I had to rebuild an 80 Gigabyte website to work around this bug.
This forces any development version of a website, or any information organized locally using HTML (which is very, very useful) to avoid symbolic links. Symbolic links are integral to UNIX, but Firefox breaks UNIX.
Apparently, at least when working locally, Firefox cannot detect the fact that a CSS file has changed. This makes developing CSS files almost impossible, since you cannot use Firefox to view any changes you have made to a CSS file - it'll just continue to use the old one.
Preliminary note: The URL bar on Firefox is officially called the "Awesome Bar." That is without question the dorkiest name ever given to a software component. I'm embarrassed even to use it, so I'll continue to call it the URL Bar (which is what it is; as we shall see, it is not, in fact, awesome).
Wham, you're jerked over to whatever tab is already open (possibly in another viewport/workspace). This is almost certainly NOT what you want to do. If you wanted to go to the other tab, you'd have gone there. If you're using the URL bar to open the page in a new tab, it seems prima facie [expletive deleted] obvious that you want to open the page in the new tab. This is, after all, exactly what you told Firefox to do.
The disturbing thing is that if you search online for this topic, many people have noted this misbehavior. But the Firefox developers are so tied to some particular way of thinking that they cannot even understand the scenario. In one forum, when this faulty behavior was pointed out as undesirable and explained clearly, the first Firefox developer to respond (who will remain nameless here) said "Can you explain this in more detail?" and proceded to describe how doing something else entirely seemed to work for him.
All portions of this document not noted otherwise are Copyright © 2014 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]