Last Comment Bug 387258 - plain text txt file viewing capability lost after having downloaded a txt file with content-disposition: attachment and content-type: plain/text
: plain text txt file viewing capability lost after having downloaded a txt fil...
Status: RESOLVED FIXED
[sg:low] persistent DoS
: fixed1.8.0.15, verified1.8.1.12
Product: Core Graveyard
Classification: Graveyard
Component: File Handling (show other bugs)
: Trunk
: All All
: -- major (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (Out June 25-July 6)
:
Mentors:
Depends on: 332690
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-07 12:25 PDT by oo.rio.oo
Modified: 2016-06-22 12:16 PDT (History)
15 users (show)
ted: blocking1.9-
reed: wanted1.9+
dveditz: blocking1.8.1.12+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Sure (1.01 KB, patch)
2007-10-10 08:51 PDT, Boris Zbarsky [:bz] (Out June 25-July 6)
cbiesinger: review+
cbiesinger: superreview+
dveditz: approval1.8.1.12+
sayrer: approval1.9+
asac: approval1.8.0.next+
Details | Diff | Review

Description oo.rio.oo 2007-07-07 12:25:17 PDT
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
Comment 1 Jesse Ruderman 2007-07-07 15:12:52 PDT
You're using a very old version of Firefox.  Does this bug still exist in Firefox 2.0.0.x?  On trunk?
Comment 2 oo.rio.oo 2007-07-08 01:46:49 PDT
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.
Comment 3 Jesse Ruderman 2007-07-08 02:59:59 PDT
You can download trunk builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/.
Comment 4 Daniel Veditz [:dveditz] 2007-07-09 11:09:25 PDT
Jesse: can you confirm this? we really can't "block" on an unconfirmed bug.
Comment 5 Christian :Biesinger (don't email me, ping me on IRC) 2007-07-14 23:00:11 PDT
the code in question hasn't changed since then. but I think this is a duplicate.
Comment 6 Jesse Ruderman 2007-07-15 00:13:37 PDT
I tried these searches:
  txt,text "file handl"
  disposition
and didn't find anything that looked like the same bug.
Comment 7 Daniel Veditz [:dveditz] 2007-08-07 11:57:34 PDT
qawanted: please confirm this bug.
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-08-31 09:36:21 PDT
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?
Comment 9 Daniel Veditz [:dveditz] 2007-09-06 16:57:14 PDT
Looks like we're stuck waiting for bug 332690 to get fixed, doesn't look all that good.
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-09-14 02:28:52 PDT
> 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?
Comment 11 Christian :Biesinger (don't email me, ping me on IRC) 2007-09-14 18:33:46 PDT
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)
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-09-14 19:20:30 PDT
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.
Comment 13 Ted Mielczarek [:ted.mielczarek] 2007-10-10 06:56:50 PDT
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 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-10-10 08:51:38 PDT
Created attachment 284314 [details] [diff] [review]
Sure
Comment 15 Christian :Biesinger (don't email me, ping me on IRC) 2007-10-13 14:42:11 PDT
Comment on attachment 284314 [details] [diff] [review]
Sure

ok I guess. that list wasn't supposed to grow so much...
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-10-14 11:23:31 PDT
Yeah, we need a better setup to differentiate things the user actually adds from things we auto-add...

In any case, checked in.
Comment 17 Daniel Veditz [:dveditz] 2007-12-19 10:43:29 PST
Is this something we should take on the 1.8 branch?
Comment 18 Daniel Veditz [:dveditz] 2008-01-08 10:39:06 PST
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 19 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-01-08 10:43:31 PST
Comment on attachment 284314 [details] [diff] [review]
Sure

If it applies, sure.  If not, it's a trivial merge.
Comment 20 Daniel Veditz [:dveditz] 2008-01-09 10:51:04 PST
Comment on attachment 284314 [details] [diff] [review]
Sure

approved for 1.8.1.12, a=dveditz for release-drivers
Comment 21 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-01-09 13:07:46 PST
Checked in on branch.
Comment 22 Kay Abendroth 2008-01-31 04:48:30 PST
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 23 Alexander Sack 2008-03-12 09:43:50 PDT
Comment on attachment 284314 [details] [diff] [review]
Sure

a=asac for 1.8.0.15

(unmodified distro patch)
Comment 24 Reed Loden [:reed] (use needinfo?) 2008-03-22 00:49:49 PDT
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

Note You need to log in before you can comment on or make changes to this bug.