User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 After having downloaded a txt file attachment from a post on a vBulletin messageboard, Firefox will no longer open plain text files in the browser for viewing, instead prompting a download box asking how to save the file instead. After a little snooping around I noticed that when a plain text file with header options content-disposition: attachment and content-type: text/plain is downloaded a few lines regarding text/plain are added to the mimeTypes.rdf file of the active profile: ------------------------------------------- <RDF:Description RDF:about="urn:mimetype:plain/text" NC:value="plain/text" NC:editable="true" NC:fileExtensions="txt" NC:description="Text Document"> <NC:handlerProp RDF:resource="urn:mimetype:handler:plain/text"/> </RDF:Description> <RDF:Seq RDF:about="urn:mimetypes:root"> <RDF:li RDF:resource="urn:mimetype:plain/text"/> </RDF:Seq> <RDF:Description RDF:about="urn:mimetype:handler:plain/text" NC:alwaysAsk="true" NC:saveToDisk="true"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:plain/text"/> </RDF:Description> ------------------------------------------- With these lines present in mimeTypes.rdf I get prompted with the download box. Manual removal of these lines restores Firefox' capability to view text files in the browser. Unless the user figures this out and knows his way around manually altering the mimeTypes.rdf file (because these text/plain associations don't show up in the Download Actions window) this is a permanent feature destroying bug. Reproducible: Always Steps to Reproduce: 1. Download a txt file with content-disposition: attachment and content-type: text/plain. (Verified through text file attachments on vBulletin messageboards, which exhibit this behaviour.) 2. Open a local txt file in Firefox or navigate to a remote one. Actual Results: Firefox will pop open a download box and ask how to save the 'opened' txt file. Expected Results: Firefox opens the txt file for viewing in the browser

You're using a very old version of Firefox. Does this bug still exist in Firefox 2.0.0.x? On trunk?

Bug persists on Firefox 2.0.0.x Tested on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Didn't test it on current trunk as I don't have the means available to compile Firefox.

You can download trunk builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/.

Jesse: can you confirm this? we really can't "block" on an unconfirmed bug.

the code in question hasn't changed since then. but I think this is a duplicate.

I tried these searches: txt,text "file handl" disposition and didn't find anything that looked like the same bug.

qawanted: please confirm this bug.

This is basically the same as bug 332690. The issue is that the site sends a .txt file with the type "plain/text" (NOT "text/plain"), after which we think all local .txt files are "plain/text". See the discussion in bug 332690 for details. Perhaps we should always treat .txt as text/plain, without allowing the OS to override?

Looks like we're stuck waiting for bug 332690 to get fixed, doesn't look all that good.

> Looks like we're stuck waiting for bug 332690 to get fixed Why? I'm much happier forcing ".txt" to be text/plain than I am forcing ".svg" to be image/svg+xml. Perhaps we should just do it. Christian, what do you think?

that seems acceptable, yeah... but perhaps another possibility would be to give the ext->type mappings from mimeTypes.rdf lower priority than the other sources of information we have? (OS, etc)

We want it to override OS, because that lets users set up associations in the browser even if the OS is broken.... Really, we don't want this entry getting added at all, imo.

If bug 332690 isn't blocking, we're not blocking on this either. Would like a simple patch to force .txt to text/plain though.

Comment on attachment 284314 [details] [diff] [review] Sure ok I guess. that list wasn't supposed to grow so much...

Yeah, we need a better setup to differentiate things the user actually adds from things we auto-add... In any case, checked in.

Is this something we should take on the 1.8 branch?

I'm pretty sure this is a nice win for a problem that has been seen in the wild and is essentially not user-fixable (without a lot of help). Can this patch go in as-is on the 1.8 branch?

Comment on attachment 284314 [details] [diff] [review] Sure If it applies, sure. If not, it's a trivial merge.

Comment on attachment 284314 [details] [diff] [review] Sure approved for 1.8.1.12, a=dveditz for release-drivers

Checked in on branch.

verified1.8.1.12 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080128 Firefox/2.0.0.12

Comment on attachment 284314 [details] [diff] [review] Sure a=asac for 1.8.0.15 (unmodified distro patch)

MOZILLA_1_8_0_BRANCH: Checking in uriloader/exthandler/nsExternalHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v <-- nsExternalHelperAppService.cpp new revision: 1.290.4.2.4.6; previous revision: 1.290.4.2.4.5 done