Closed Bug 387258 Opened 17 years ago Closed 17 years ago

plain text txt file viewing capability lost after having downloaded a txt file with content-disposition: attachment and content-type: plain/text

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: oo.rio.oo, Assigned: bzbarsky)

References

Details

(Keywords: fixed1.8.0.15, verified1.8.1.12, Whiteboard: [sg:low] persistent DoS)

Attachments

(1 file)

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?
Component: General → File Handling
Product: Firefox → Core
QA Contact: general → file-handling
Whiteboard: [sg:low] persistent DoS
Version: unspecified → 1.8 Branch
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/.
Flags: blocking1.8.1.6?
Flags: blocking1.8.1.5?
Jesse: can you confirm this? we really can't "block" on an unconfirmed bug.
Flags: blocking1.8.1.5? → blocking1.9?
the code in question hasn't changed since then. but I think this is a duplicate.
OS: Windows XP → All
Hardware: PC → All
Version: 1.8 Branch → Trunk
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.
Keywords: qawanted
Whiteboard: [sg:low] persistent DoS → [sg:low] persistent DoS, need confirmation
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?
Status: UNCONFIRMED → NEW
Depends on: 332690
Ever confirmed: true
Keywords: qawanted
Whiteboard: [sg:low] persistent DoS, need confirmation → [sg:low] persistent DoS
Summary: plain text txt file viewing capability lost after having downloaded a txt file with content-disposition: attachment and content-type: text/plain → plain text txt file viewing capability lost after having downloaded a txt file with content-disposition: attachment and content-type: plain/text
Looks like we're stuck waiting for bug 332690 to get fixed, doesn't look all that good.
Flags: blocking1.8.1.7? → wanted1.8.1.x+
> 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.


Whiteboard: [sg:low] persistent DoS → [sg:low] persistent DoS [wanted-1.9]
Attached patch SureSplinter Review
Attachment #284314 - Flags: superreview?
Attachment #284314 - Flags: review?(cbiesinger)
Attachment #284314 - Flags: superreview? → superreview?(cbiesinger)
Flags: blocking1.9? → blocking1.9-
Comment on attachment 284314 [details] [diff] [review]
Sure

ok I guess. that list wasn't supposed to grow so much...
Attachment #284314 - Flags: superreview?(cbiesinger)
Attachment #284314 - Flags: superreview+
Attachment #284314 - Flags: review?(cbiesinger)
Attachment #284314 - Flags: review+
Attachment #284314 - Flags: approval1.9?
Attachment #284314 - Flags: approval1.9? → approval1.9+
Assignee: nobody → bzbarsky
Yeah, we need a better setup to differentiate things the user actually adds from things we auto-add...

In any case, checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Is this something we should take on the 1.8 branch?
Flags: blocking1.8.1.12?
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?
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Comment on attachment 284314 [details] [diff] [review]
Sure

If it applies, sure.  If not, it's a trivial merge.
Attachment #284314 - Flags: approval1.8.1.12?
Comment on attachment 284314 [details] [diff] [review]
Sure

approved for 1.8.1.12, a=dveditz for release-drivers
Attachment #284314 - Flags: approval1.8.1.12? → approval1.8.1.12+
Checked in on branch.
Keywords: fixed1.8.1.12
Flags: wanted1.9+
Whiteboard: [sg:low] persistent DoS [wanted-1.9] → [sg:low] persistent DoS
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
Flags: blocking1.8.0.15+
Comment on attachment 284314 [details] [diff] [review]
Sure

a=asac for 1.8.0.15

(unmodified distro patch)
Attachment #284314 - Flags: approval1.8.0.15+
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
Keywords: fixed1.8.0.15
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: