January 31, 2013

A VERY unfortunate Mozilla "improvement"

A VERY unfortunate Mozilla "improvement"
2. filename vs title
3. Why saving by title is not necessary
4. Why saving by title is a bad idea
5. What should be done about this: Make it a Prefence
6. Two workarounds
About ME/CFS


This is about a VERY unfortunate Mozilla "improvement" introduced in version 18.0 of Firefox and also in version 2.15.1 of SeaMonkey - and I am writing as I do to keep my language diplomatic.

A VERY unfortunate Mozilla "improvement"

There is a very fine German word, which is a play on the German words for better and worse, which are respectively "besser" and "schlimmer": Verschlimmbesserung: Making something worse by trying to make it better.

This happened to the most recent versions of the two Mozilla browsers I use, Firefox and SeaMonkey, at least on Linux, and probably also on Windows, though I have not verified that:
  • The Save As option no longer saves html-pages by their filenames but by their html-titles, and also, which makes this much worse:
  • There is no option or preference or addon to do it the way it was, for many years, that at least allows one to have a choice.
I noticed this today, and lost something like four hours - so far - to find out what it is due to, for Mozilla seems to have said nothing up front. In the end, I found out by searching and what I found is an item on the Mozilla servers about it that is clear enough:
This is about SeaMonkey, that I also regularly use, as I do Firefox, and it also lists in one of the comments an Addon that is supposed to undo it, which I would not try and did not try.

Why is this a bad change, especially as is, without any option to restore the old policy in both browsers, which was to store by filename, not by title?

Let me first explain the difference, and also why naive users - the great majority - have been asking for the change, that seems to be how MS IE does it since years (which I don't know, for I have avoided that awful product since years).

2. filename vs title

The filename is part of the protocol by which computers store files. What the user gets to see as path+filename is generally a combination of slashes and letters and numerals, which is the human readable form of its hexadecimal or binary form that the computer needs, and that specifies an address on a disk or drive, normally with a directory prefix - the path - of which the filename is the last item, that names the file in the directory the path specified.

To be allowed as a filename, its human readable form must meet certain criterions. These criterions differ on different Operating Systems, and also on the same (named) Operating System at different times.

Thus, experienced users may recall that 8*3 format on DOS and early Windows:
A filename of maximally eight characters or numerals with an extension of maximally three characters or numerals, separated by a dot, and all without certain forbidden characters, such as spaces and slashes and stars and more.

Since then the criterions for filenames have been made a lot less strict, and it is now quite possible to use long descriptive names, such as "This-is-really-a-rather-long-name.html", which is the format that e.g. The Guardian uses. (One can also use spaces these days in filenames, but technically savvy people like to avoid this, for various good reasons.)

This means that at present, at least on Linux and on Windows, and probably also on Macs, one can have filenames that are as descriptive as one likes, as maker of the file, or not, where the last option also may have good reasons.

Thus, the filenames I use for Nederlog have this general form: NLyrmodach.html, where yr is two numerals for the year, mo two numerals for the month, da two numerals for the day, and ch a character that allows several files for the same day. The filename of the file this text appears in, for example, is NL130131a.html. My reason to do this as stated is to have all the Nederlog files of one year in one directory, that are automatically sorted by date through their filenames.

The title of a html-file is not part of its filename, properly speaking, but is simply something one can set (or indeeed avoid to set, or forget to set) in a html file, and was introduced as a special option in html long ago to have something more informative and longer than filenames used to be.

Thus, the title of the present file is "
VERY unfortunate Mozilla "improvement"", while its filename is "/../NL130131a.html", where the part "/../" in fact abbreviates the directory-structure that specifies the directory where my Nederlog files for 2013 are on my hard disk.

The title may contain virtually anything and any characters without any formatting: All that seems to be fixed for it is that it is valid html.
Good browsers can show both: The title followed by the filename in square brackets, for example.

It seems that naive users of Firefox have been asking for years to be able to save their pages by title rather than filename, namely because they claim that the titles "are more descriptive".

Now let me explain why this is not a good idea.

3. Why saving by title is not necessary

To start with why it is not necessary. There are two main reasons.

First, the maker of the file, or the one who uploads it for the internet, can at present and since quite while introduce long descriptive names as filenames. Indeed, that has become a rather common practice, and - for one example - how The Guardian does it

Second, in Firefox there was at least one add-on that allowed its users, if they wanted, to save files not by filename but by title.

So naive users who wanted to save by title rather than by filename could do this for quite a while: There is no need for it, as there was a proviso for it.

4. Why saving by title is a bad idea

Again there are two main reasons.

First, the title may contain stuff that makes it unfit as a filename, such as "*" or "?" (that are used as wildcards to search filenames); and the title may be missing, crappy, stupid, misleading or very long - which means that one's fileviewer with directories with many html files are suddenly full of insanely long filenames that may be descriptive, if one is lucky, but that certainly take a lot of time to read, and a lot of space in one's fileviewer.

Second, and most importantly: It destroys the properties of the URI and makes sites like mine a lot less useful.

The reason is that I have many files on my site, with many internal links. I will not explain all of the story, but simply provide an example, that explains my point, and indeed also how I found out.

Yesterday I mentioned an excellent Linux-resource:
This is organized as over 585 html-files in one directory, that are heavily crosslinked, which is precisely what hypertext - html = hypertext markup language - is all about: Linking files to each other by links that provide URLs, so as to link files that are somehow related in content in a meaningful and helpful  way.

Until version 18 of Firefox I could download all these files, put them in one directory, and be certain that all the links worked also if I was not on line - which is what I often like to be (for I don't trust the internet, and like to keep my computer unhacked).

With version 18 of Firefox, and version 2.15.1 or SeaMonkey that is no longer the case: ALL interconnections by links - that all depend on filenames - are completely destroyed because the files are saved by title - and that title may not even be a proper filename, in which case the browser must modify it to save it!

A site like mine could be saved in its entirety to another harddisk with all internal links working on that other harddisk, wholly apart from the internet, provided only that (1) the filenames were preserved and (2) the directory-structure was preserved. Likewise it could be saved in part, and links to files that were also saved would work on that other hard disk if they met the above two provisos.

None of this is true if html-files are saved by their html-titles, for these are no longer URIs - and besides, may be dangerous or useless as filenames, and also tend to be insanely long, when used as filenames, and unwieldy and unhandy in one's fileviewer.

5. What should be done about this
: Make it a Prefence

Naive users may like it, but then naive people may like lots of things that they would know is not good for them if only they knew a little more than they do.

I want my links preserved; I want the original filenames; I do not want insanely long filenames derived from arbitrarily long htm-titles; I want properly formatted filenames; and I suspect also - precisely because titles are not
URLs - this introduces yet another safety risk. [1]

So the least Mozilla should do, and as fast as possible, is this, in order of preference:
  • Make the Save As an option in the Preferences menu, where one can choose between Save As by title or by filename and/or
  • Provide an add-on to enable savvy users to save by filename rather than by title, so as to preserve links and/or to avoid insanely long and quite possibly improperly formatted filenames derived from html-titles (that may be virtually any string).
Note this is not asking much: The code existed until version 18 of Firefox, so all the good people at Mozilla need to do is add it as Preference, e.g. under General - Downloads, as follows:
Save html-files - by filename
                              - by title

where one can then set one's preference. (Also, it woukd make sense to warn naive users that htm-titles often make VERY long "filenames"!).

6. Two workarounds

There are two workarounds, at present, none pleasant:
  • Workaround 1 - kludgy: Saving from an URI (still) goes by filename: If one knows an URI for a file one wants to save, one can save it from that URL.
This is kludgy because it doesn't work anymore for files one has opened and that one considers interesting enough to save because of what one has read in them.

In the case of such an opened file, one is condemned to do this, on a modern computer, in the latest version of what is claimed to be the best browser:
  • Workaround 2 - extremely kludgy: One can manually copy the filename from the URL (it is the last part of the full URI) with one's mouse, then press Save As, then manually remove the offered title (that anyway may be a foot long or more), then paste the copied filename in its place, and then, at looooong last, save the file by its filename...
Note that I will probably anyway want to do that, because at present my html-directories have many filenames of 10 to 20 words, which looks extra-ordinarily messy and useless in my fileviewer, and does not help me one bit: If I want useful filenames I could introduce them with the old policy in terms that are meaningful to me, while also being proper filenames.

This "improvement" is a prime example of a Verschlimmbesserung! I hope Mozilla VERY soon comes with the proposed real improvement: Make Save As depend on a setting in Preferences.
P.S. Jul 10, 2013: I have sorted out some mistakes, and note four versions onwards I have received no reply and seen no change. 
[1] E.g. what happens if a title of 5 Kb or 1 MB is offered? I have no idea, but I do know a trick involving overload of a field has been much used to gain illegal access to computers in the past.

About ME/CFS (that I prefer to call M.E.: The "/CFS" is added to facilitate search machines) which is a disease I have since 1.1.1979:
1. Anthony Komaroff

Ten discoveries about the biology of CFS(pdf)

3. Hillary Johnson

The Why  (currently not available)

4. Consensus (many M.D.s) Canadian Consensus Government Report on ME (pdf - version 2003)
5. Consensus (many M.D.s) Canadian Consensus Government Report on ME (pdf - version 2011)
6. Eleanor Stein

Clinical Guidelines for Psychiatrists (pdf)

7. William Clifford The Ethics of Belief
8. Malcolm Hooper Magical Medicine (pdf)
Maarten Maartensz
Resources about ME/CFS
(more resources, by many)

       home - index - summaries - mail