Hacker News Reader

Comment by ars | Hacker News Reader

Wow. I never expected I would see someone complain about this.

Firefox is following the mime types exactly the correct way.

Compare to the disaster of IE which sometimes looks at the file extension to decide how to display the document - that caused me huge problems way back.

Yes, a view as text option would be nice, but firefox is doing exactly the right thing by listening to the mime type.

If I get text/csv I don't want it showing in the browser, I want it to launch it externally. If firefox gets text/x-csrc it checks the /etc/mailcap, and does what it's told. It has no way to guess that you prefer to view it in the browser - the server said: it's a C file, and firefox listens.

How would you program it? How is it supposed to know that text/x-csrc should show in the browser, while text/csv is an external program? Both are listed in mailcap.

However, like I said, an option "View as Text" in the download box would be nice.

View on HN

I'd prefer that it display all text/* content in the browser. If I want to save it, then I'll save it.

Well then tell Firefox that. You can configure what it's behaviour is in the preferences pane. The defaults are perfect, it's your preference that's different from the standard. Which is why they put it in Preferences.

"Display it in the browser" is not an option. Have you even looked?

The preference pane does not let you create new lines -- the only way to add rules as a user is to encounter the Content-Type in the wild.

Not stock. But you can get it:

https://addons.mozilla.org/en-US/firefox/addon/8207

Awesome! I was using a hacked-on 3-year-old version of that, as it was never on AMO -- I even searched for it when commenting in this thread.

Awesome little gem: I went to Tools > Add-ons > Extensions > Find updates -- and it found and downloaded the new AMO version of my hacked local copy!

"Perfect" ?

Presumably you could add this to your mailcap:

  text/*; firefox '%s'; test=test "$DISPLAY" != ""

Firefox is following the mime types in the obnoxious spec whoring way that ignores reality, common to ideology-driven FOSS.

Since in the vast majority of cases the declared Content-Type comes from Apache sniffing the filesystem extension (or at best, the magic number), all you've done is push the problem server-side.

The end result of Mozilla's anal-retentive 'bug fix' is that less content will be served with correct Content-Type, with everything as text/plain if you're lucky (all sorts of shit is served as text/html). I ended up just editing /etc/mime.types when I was a CS Lab administrator -- faculty like it when they can view goddamn text in a browser without spawning fucked processes in the background that eventually crash your session.

I don't know why the fuck they don't have a mailcap blacklist -- not everyone uses GUI-focused distributions that let GNOME defecate in every crevice of /etc/

How would I program it? Always display plain text as text, with an explanatory infobar at the top giving other options. I swear, the infobar idiom is the only good new thing to ever come out of Mozilla.

Blasdel has some good points here, I think, but (s)he has phrased it in an unnecessarily offensive way. Please allow me to translate. I don't entirely agree, but it's not all wrong either.

----------------

Firefox is following the MIME type spec with the sort of excessive zeal for standards documents at the expense of real world practicality that you often get with open source projects.

Usually, the MIME type is coming from the web server guessing the file's type, which is not itself reliable, so you've pushed the problem to the server side. [interpolation by jerf: Slavishly following these MIME types is not a valuable thing to do, since the MIME type is not very reliable here.]

The end result of this is to ruin the entire value of the MIME type by encouraging people in the real world to serve more content up as text/plain (or even worse, text/html). I just edited /etc/mime.types when I administered a lab, because my users just wanted to see the content without spawning extra processes.

I don't know why they don't have a mailcap blacklist; not everyone uses GUI-focused distributions that spew bad values all around /etc in a misguided attempt to be helpful.

How would I program this? Always display unknown MIME types that look like text as text, with an infobar at the top giving other options. The infobar idiom is a nice feature and they should use it.

-------------------

jerf: I do quite like that suggestion. I'd also point out that while deciding whether something is text may be, strictly speaking, undecidable, in practice it's about 98% feasible.

Thanks for tempering my nerd-rage -- having someone else paraphrase your text in a different tone is an alarmingly insightful proofreading proofreading praxis that I never would have considered!

-------------------

The problem with the extra processes was not that they existed independently of Firefox, but that they were silently useless and caused the browser to crash -- launching 'less' in the background with no tty hooked up is a stunningly stupid end-result.

The problem with /etc/mailcap on an install that doesn't have all the GNOME cruft installed is that can have defaults like 'less' and 'emacs' at the head of the list for all sorts of types.

-------------------

RE: Decidability, Firefox is already doing content sniffing for the common Content-Types, even they are not anal enough to deny that all kinds of stuff is served as text/html. It's also fairly easy to detect known non-text types, as producers are kind enough to pick novel values for the first few words ("man 4 magic").

It doesn't really even have to sniff at all to get the obvious cases -- if it's unhandled and in text/, display it! (though that still wouldn't handle inanities like application/x-ruby in Ubuntu's mime.types, or the total retardation that is FF's handling of application/json)

They claim that firefox since 1.9.1 respects the needsterminal in mailcap so it shouldn't run/show less etc:

https://bugzilla.mozilla.org/show_bug.cgi?id=442629

if it doesn't you should reopen (also I wonder what it does if there are no lines without needsterminal).

Upmodded for the translation in which you filter out the offensiveness. Blasdel's tone makes it very hard for me to take him seriously. Especially the "common to ideology-driven FOSS" phrase almost snapped a nerve.

I'd prefer 3 options, saveas, open directly, view directly.

Compare to the disaster of IE which sometimes looks at the file extension to decide how to display the document - that caused me huge problems way back.

Agreeing with most of your post, I think you are wrong on this one.

IE will do lots of stuff to detemine what kind of data it is actually getting from the server, somewhat overriding the http spec. Even if something is served as a appliction/octet-stream, IE might resort to looking at the extension of the URL (or the content-disposition header, if one is present).

If these checks fails, it will resort to MIME sniffing, by analyzing the first 256 bytes of the file to see if it can figure out what kind of content it contains. This method is surprisingly accurate, and you can test it yourself. [1]

In my opinion IE does a lot of things to make life easier for it's users to overcome problems caused by people configuring their servers incorrectly, something which is getting increasingly common.

I don't think IE deserves to be ridiculed over this extra effort.

[1] For some demo-code you can try out, check the following link: http://stackoverflow.com/questions/58510?sort=oldest#sort-to...

If you served http://example.com/foo.msg as text/plain, older IE versions used to helpfully assume the user wanted to view it in Outlook Express, which exploded because it only supported some binary monstrosity and not text/plain. Dots are not special in an abs_path, and you can't make an interoperable network by assuming your peer does everything the same way you do.

Reply on news.ycombinator.com