185618 - Offer choice to open natively with Content-Disposition: attachment (View/Show in browser)

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Jesse Glick]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

Try clicking on the supplied link:

http://www.netbeans.org/issues/showattachment.cgi?attach_id=8339&file=NBSplash_3_4_1.gif

This is an attachment to an Issuezilla (derived from Bugzilla) report. This
version of Issuezilla has been patched to send a header including:

Content-disposition: attachment;
filename=NBSplash_3_4_1.gif
Content-Type: image/gif; name=NBSplash_3_4_1.gif

When I click on it in Moz 1.2.1, I get a dialog with the options:

1. Open using an application (GIF image: image/gif) [Choose...]
2. Save this file to disk

Both of which are fine, but what I really wanted was to just view the image!

This was originally reported in the NetBeans website issue-tracking system:

http://www.netbeans.org/issues/show_bug.cgi?id=29561

However I believe that the server behavior here is reasonable. The server does
not know and cannot reasonably know which MIME types the browser is capable of
displaying directly and appropriately. Also, in the majority of cases, the user
does in fact wish to save the attachment to disk, and in this case it is
desirable for the server to supply an appropriate filename (based on the
filename used when originally uploading the attachment). So the server sends
what I think is the correct set of headers.

Yet for the user to actually view the GIF in Mozilla, it is necessary to save
the file to disk (/tmp, say), copying the filename in the Save dialog, then jump
to the URL field, and type in "file:///tmp/", press Ctrl-V, enter. Annoying.

http://bugzilla.mozilla.org/show_bug.cgi?id=98360#c38

seems to provide the explanation (if I understand correctly):

"This patch does these.	The one thing it does not do is to properly retrieve
the helper app for a type that we handle internally (eg image/gif).  This is a
fairly small issue, imo, since most of the time this situation is encountered
the user will want to save anyway."

Most of the time, but the behavior is annoying the rest of the time, when the
user just wants to look at the sent file directly in the browser. This would
apply to images, text, HTML, etc.

I suggest that if "attachment" is given as the content disposition for a link
which is clicked, where the content type is one that can be displayed directly
in Mozilla (either natively like HTML or via plug-in like PDF), that a dialog be
shown (as RFC #2183 seems to require) as now, but that there be three options:

1. Open using an application (GIF image: image/gif) [Choose...]
2. Save this file to disk
3. View in Mozilla

where #3 would behave as if you had just clicked on a plain link with no
Content-Disposition header at all (i.e. file is not saved except perhaps to
cache, opens in current window or tab, etc.).

Reproducible: Always

Steps to Reproduce:
1. Click on link:

http://www.netbeans.org/issues/showattachment.cgi?attach_id=8339&file=NBSplash_3_4_1.gif
Actual Results:  
Dialog pops up which permits GIF to be opened with a helper app, or saved to disk.

Expected Results:  
Dialog pops up which permits GIF to be opened with a helper app, or saved to
disk, or viewed directly.

Comment 1

[Christopher Hoess (gone)]

> The server does not know and cannot reasonably know which MIME 
> types the browser is capable of displaying directly and appropriately.

Yes, it can. It's called the "Accept: " header. I suggest patching IssueZilla 
to make use of it and cease to send "Content-Disposition: Attachment" for 
MIME-types explicitly listed in the Accept: header, rather than insisting that 
Mozilla do an end run around this (mis)use of HTTP.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Just as a quick hint, I _would_ like to add a "view in browser" option to that 
dialog, and whether content-disposition is set should be irrelevant to offering 
that option.

Adding this function just requires a pretty comprehensive rewrite of how we do 
helper apps (and possibly chunks of the uriloader), is all.

Note that in IE the header you are sending will cause a filepicker to come up, 
so the _only_ thing the user will be able to do is save to disk.... So you have 
a problem no matter what.

If all you want is to suggest a filename, just do:

Content-disposition: inline; filename="whatever"

and the browser will show the content inline if possible, putting up that same 
dialog if not possible.  In either case, attempting to save will use the 
filename from the header.

Comment 3

[Jesse Glick]

Thanks to both of you for the comments!

To Christopher: true, I had thought of that, but wasn't sure how well it would
work. Given this header:

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1

what should the server conclude? This version of Mozilla will display image/gif
inline just fine (even if it is only "20% preferred") but will not display
application/lala inline (though it is "10% preferred"). The header correctly
indicates that image/png is preferred to image/gif; it does not indicate that
both are natively displayable.

To Boris: thanks for the tip re.

Content-disposition: inline; filename="whatever"

which I confirmed works exactly as desired in my copy of Mozilla at least. I
will reopen the request for our version of Issuezilla to use this header - feel
free to close this issue as WONTFIX unless you still think it would be nice to
offer a "view inline" option on the save dialog anyway.

I don't have a copy of IE to test with. M$ discontinued their Unix version,
looks like, and my XP partition is quite busted. :-/

Comment 4

[Darin Fisher]

hmm.. i'm thinking WONTFIX since mozilla is behaving as expected when a 
 
  Content-disposition: attachment;

response header appears.  is there really any value in changing our behavior? 
will users really care?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> unless you still think it would be nice to offer a "view inline" option on
> the save dialog anyway

I do think it would be nice, but that's already covered by another bug (with 
many dups).  Which I can't find at the moment.

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 187549 has been marked as a duplicate of this bug. ***

Comment 7

[Jesse Glick]

Related: bug #171296

Comment 8

[Frank Wagner]

Is RFC2616 the right place to look? In section 19.5.1 about Content-disposition,
there isn't mentioned 'inline' as a disposition-type. Couldn't the following
paragraph be interpreted as if 'attachment's are shown like inline if they are
not application/octet-stream:

"If this header is used in a response with the application/octet-stream
content-type, the implied suggestion is that the user agent should not display
the response, but directly enter a `save response as...' dialog."

So Mozilla seems to be more consistent, but http-services not violating RFC2616
by using 'attachment' just to give a name (like 'inline') have a problem. 

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yes, but "what does IE do?"

Comment 10

[Alan Monroe]

Nobody seems to have mentioned this, but this problem didn't exist in 1.2 and
earlier.

It becomes a very big problem if you are a person that frequents web-based
forums based on software like vbportal or phpbb. One such forum is located at
vpforums.com. Virtually every post in some topics contain attached screenshots.
In 1.2 and earlier I can just click and view them - No muss no fuss. Going to
1.3 or later, the forum becomes completely unusable since you get prompted on
every click, and there's no option for "use Mozilla's internal gif/jpeg viewer".
If there were, I'd set that and check the "do not ask" box.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Nobody seems to have mentioned this, but this problem didn't exist in 1.2 and
> earlier.

We didn't support content-disposition:attachment very well back then.

> One such forum is located at vpforums.com.

That's vbulletin.  They're purposefully sending a content-disposition header
that is malformed in such a way that IE treats it as "inline" and any browser
that follows the spec treats it as "attachment".  Their newest version is fixed
to just use "inline"; I suggest you contact the forum operator and ask him to
upgrade.

None of which affects this bug, of course.  We all agree this needs fixing. 
Want to do it?  I can point you to the code...

Comment 12

[Matthias Versen [:Matti]]

*** Bug 208639 has been marked as a duplicate of this bug. ***

Comment 13

[Hixie (not reading bugmail)]

Having read all these comments, I cannot work out what the bug is. Is it that we
want an option to view inline things that are marked as being attachments?

Mozilla needs a general "override server mime type, treat this file as _foo_"
option somewhere, just to handle the numerous misconfigured servers. Would this
just fall under that?

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

hixie: Yes, your first paragraph is what this bug is about, as I understand it.

I don't think it would fall under the second thing - that second suggestion
would probably only be usable if the file is being displayed in a browser
window, right? But disposition:attachment files are never shown there, all the
user sees for them is a dialog telling them they should save the file or open
them with another app.

Comment 15

[Hixie (not reading bugmail)]

Yeah, I guess it would be covered by:

1. This bug, which is about adding "( ) Open in Mozilla" to the download dialog.
2. Adding an option somewhere that overrides Mozilla's current determination of
   the MIME type for the currently opened file.
3. Adding an option in the normal "unrecognised type" download dialog for doing 
   the equivalent of 2 but when the file wants to be downloaded, not opened.

I hate the idea of adding all this UI though, especially for a feature that will
be understood by even fewer people than the character encoding menu.

Comment 16

[Darin Fisher]

-> future

Comment 17

[Mike Connor [:mconnor]]

*** Bug 208697 has been marked as a duplicate of this bug. ***

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 166393 has been marked as a duplicate of this bug. ***

Comment 19

[Jerry Talkington]

I think that this should be marked as a bug, not an enhancement.  Section 15.5
states very clearly that Content-Disposition is not part of HTTP, but it is
described since so many people (incorrectly) implement it.  Section 19.5.1 then
goes on to say that if a UA is going to implement it, that it should only be
used as a suggestion for the file name.

So, the only time that this header should have any bearing is when a user
decides that they want to save a page element (or requests an object that has a
content-type that we don't decode,) and then only to suggest a file name.

Comment 20

[Graham Reed]

Attachment: Example of new prefs to disable force-external of attachment.

First off, this patch is only intended to be a demo of how I dealt with the
issue here.

It modifies the nsDocumentOpenInfo::DispatchContent to check for a preference
when forceExternal would be set true.  It checks for 3 prefs, based on the mime
type:

network.attachment.force-external.general/specific
network.attachment.force-external.general/*
network.attachment.force-external.*/*

If a pref is found, then its value is used for forceExternal instead of 'true'.


This is particularly useful if you're stuck on some annoying webmail system
which insists on sending "Content-Disposition: attachment" for inline images.

Obviously, I'd rather fix the webmail system; but as I can't get at that, I can
hack mozilla instead.  (Maybe not well, but hey, gotta start somewhere.)

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

why not modify the helper app dialog to show a "View in Browser" option?

(like the patch in bug 57342 does)

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 229785 has been marked as a duplicate of this bug. ***

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 192704 has been marked as a duplicate of this bug. ***

Comment 24

[John]

sorry to cc spam. I've just been hoping for this for so long.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 251215 has been marked as a duplicate of this bug. ***

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

not a networking issue

Comment 27

[Robin Lu]

Attachment: patch

provide an option to view it with browser. 
I just add a few lines to make browser open the file after it has been
downloaded to the tmp directory.

Comment 28

[Robin Lu]

Comment on attachment 161817 [details] [diff] [review]
patch

bz, can you help me to review the patch? Thanks in advance.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 161817 [details] [diff] [review]
patch

>Index: uriloader/exthandler/nsMIMEInfoImpl.cpp
>+    urlString.AssignWithConversion(url.get());

This breaks for non-ASCII URIs.

>+    return watcher->OpenWindow(nsnull, 
>+                   "chrome://navigator/content/navigator.xul",  "_blank",

This introduces a dependency from this code (which is core code) to the exact
embedding app (SeaMonkey).  For example, this will not work with Firefox.  Nor
with other embedding apps.  That's not acceptable.

Further, for cases when this is content we actually _can't_ view, this will
lead to an infinite loop of browser windows.

Finally, this will open a new window for some reason.  We really want to just
load the data in the window where it started to load (so session history and
the like is preserved).

biesi mentioned a patch earlier in this bug that does something like this, no?

Comment 30

[Robin Lu]

(In reply to comment #29)
> >+    urlString.AssignWithConversion(url.get());
> This breaks for non-ASCII URIs.
It works fine with a URI having Chinese characters
and XRemoteService.cpp does the same thing:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xremote/src/XRemoteService.cpp#792

> This introduces a dependency from this code (which is core code) to the exact
> embedding app (SeaMonkey).  For example, this will not work with Firefox.  Nor
> with other embedding apps.  That's not acceptable.
I can change that to use the preference value of "browser. chromeURL".

> Further, for cases when this is content we actually _can't_ view, this will
> lead to an infinite loop of browser windows.
do you have any advise on how to avoid it?

> Finally, this will open a new window for some reason.  We really want to just
> load the data in the window where it started to load (so session history and
> the like is preserved).
I think as far as we respect the content-disposition and treat it as an
attachment, it could not be so unacceptable as to download it and view it in a
new brower window. Is that right?

Comment 31

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 161817 [details] [diff] [review]
patch

a slightly better way to go if you want to take this route is probably to get
the nsIRefreshURI off the window context and setup a refresh uri using that;
that way, the url will be loaded in the current window

this patch needs to modify pref-applications-edit.xul  as well (iirc that's the
name)

uris are utf-8. do NOT use AssignWithConversion for them; use CopyUTF8toUTF16.

"Open in Browser" should only be shown if the browser can actually handle the
file. not sure what a good way to detect this is, though...

I suppose I'm not totally against this approach. I fear this might cause a
correctness issue though, where we try to load the local file with a wrong mime
type (i.e. one different from the one sent by the server).

all in all, I prefer the patch I mentioned somewhere above...

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #30)
> and XRemoteService.cpp does the same thing:
>
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xremote/src/XRemoteService.cpp#792

this doesn't mean it's a good thing... note that AssignWithConversion is
deprecated. I'm working on removing it from the mozilla code.

Comment 33

[Robin Lu]

(In reply to comment #31)
> all in all, I prefer the patch I mentioned somewhere above...
I have looked at your patch in bug 57342 and I think it can solve more problems
than mine. I will stop updating my patch. Hope that patch could be checked in soon.

Comment 34

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 264493 has been marked as a duplicate of this bug. ***

Comment 35

[Vincent Lefevre]

Why is it marked as "enhancement"? Not being able to open web pages / images in
the browser window is a bug, even if this is under particular conditions (e.g.
when non-standard HTTP headers are used).

Comment 36

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 274265 has been marked as a duplicate of this bug. ***

Comment 37

[Ken Easson]

For some reason Windows Media Player playlist's (.asx) requires the
"Content-Disposition: attachment" be included in the headers sent from a php
script, or the player replies with "The source filter for this file could not be
loaded".
The error occurs with either no content-disposition or content-disposition: inline.

Thus, there does not appear to be any way to open a dynamic playlist (php)
stream for asx files without asking each time what to do with the file, as the
browser ignores the 'do this automatically'.

Comment 38

[reb]

Discussion trend so far worries me. Remapping mime-types, new dialogue options
are well and good but not on target for this bug. If you get to the dialogue,
its already too late.

Comment #19 hit the nail on the head: Using disposition attachment in the
Browser to trigger the dialogue in fact is *not* standards compliant at all.

Simply disable handling of disposition=attachment for the Browser: behave as-if
it were inline, as older mozilla (1.1? and earlier) and Communicator 4.x did.
Should be by default but can be a user pref if you insist. Of course don't
interfere with Save-As and Save-Link-As. Of course still offer the dialogue if
mime-type is not handled by any of: internal, registered plugins, registered helper.

Would I say No to precision control for specific mime-types? Absolutely, unless
it still offered: global disable option first, followed by options to white-list
specific few types for which to enable the "attachment" (dialogue) behavior.

Not that relevant here but currently arguing with server folk who are sending
PDF's with "attachment" who believe their server is not misconfigured and say:
"You get the dialogue with option to launch the helper, so what's the problem?"
Answer: It defeats tabbed-browsing, it defeats byte-serving, it defeats
"#anchorName" for targets within the PDF, wastes a second external acroread
process... In other words it strips all benefits of PDF, dumbing it down to the
level of PostScript.

Comment 39

[Chris Frey]

I fully agree with comment #38 and #19.  An option in the about:config list to
turn off content-disposition would be fantastic.

Comment 40

[Reinout van Schouwen]

Another testcase is
http://www.groenlinks.nl/2ekamer/notities/Notitie.2005-09-20.1114/publication/download_file
(an HTML file this time!).

We would like to see this fixed for embedded as well; Epiphany displays the same
problem.

Comment 41

[Matthias Versen [:Matti]]

*** Bug 315736 has been marked as a duplicate of this bug. ***

Comment 42

[Kai Engert (:KaiE:)]

*** Bug 186236 has been marked as a duplicate of this bug. ***

Comment 43

[Grant M.]

This behavior is just wrong. A plain-text email should not include any file with a content disposition of inline, even if it's another text file. If thunderbird wishes to include files as inline, then it needs to support drag-n-drop on any of those platforms. I attached an html file to a plain-text email, and it included it as 'inline'!

Comment 44

[Jesse Ruderman]

See discussion about security considerations starting at bug 57342 comment 159.

Comment 45

[Vincent Lefevre]

(In reply to comment #161 of bug 57342)
> Content-disposition is described in http://www.faqs.org/rfcs/rfc2183.

This is a RFC about E-mail messages, not HTTP headers. So, it doesn't
apply directly to HTTP (see below).

> It is also mentioned in the "Security considerations" section of the
> HTTP spec (http://www.faqs.org/rfcs/rfc2616), although it's not clear
> what security considerations it's talking about.

The security consideration is about the directory path information.
See Section 19.5.1:

   The receiving user agent SHOULD NOT respect any directory path
   information present in the filename-parm parameter, which is the only
   parameter believed to apply to HTTP implementations at this time. The
   filename SHOULD be treated as a terminal component only.

Indeed, taking into account the directory path information would be a
security hole: for Unix, imagine that the filename-param is "../.profile"
and that the user's download directory is just under his $HOME.

Then, note that this header is non-standard in HTTP. But Section 19.5.1
describes how it can be implemented and particularly says that the goal
is to provide a *default filename* (comments #8 and #19 recalled that).
It says:

   The Content-Disposition response-header field has been proposed as a
   means for the origin server to suggest a default filename if the user
   requests that the content is saved to a file.

Note the "if". This doesn't say that the user agent should propose a
dialog; this just says that when the user does a "Save As", a default
filename is suggested (and this is only a suggestion). Well, there's
an exception (and it doesn't depend on whether the content disposition
is "inline" or "attachment"):

   If this header is used in a response with the application/octet-
   stream content-type, the implied suggestion is that the user agent
   should not display the response, but directly enter a `save response
   as...' dialog.

But anyway, proposing this dialog also makes sense when there are no
Content-Disposition headers, since the contents can't be displayed.

The HTTP/1.1 RFC does not say that a difference between the "inline"
and "attachment" dispositions should be made. And even if one wants to
make a difference in a web browser, then it should be the following.
First read http://www.faqs.org/rfcs/rfc1806.html Section 2.2:

2.2  The Attachment Disposition Type

   Bodyparts can be designated `attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user. The MUA might instead present the user of a
   bitmap terminal with an iconic representation of the attachments, or,
   on character terminals, with a list of attachments from which the
   user could select for viewing or storage.

If one wants to transpose that ("their display should not be automatic"
but the user can view them with an action, such as a click) to a web
browser such as Firefox:

  * For elements img and object, the user would need to click on the
    link so that the corresponding image or object could be displayed
    (but this behavior would still be optional, since non-standard).

  * For element a, the contents of the document at the given URL is
    never display automatically; the user needs to click (or do some
    other action) to follow the URL. So, in this case, the "attachment"
    disposition shouldn't change anything.

IMHO, this clearly shows that the current behavior of Firefox, i.e. not
showing the contents of the URL (if in a supported media type) when the
user requests it, is buggy. Even with a MUA, it is possible to view an
attachment (in addition to be able to save it).

Based on this analysis, I suggest that the severity should be increased
from "enhancement" to "normal" (or even "major" since this bug may
prevent from viewing some sites that use the Content-Disposition header
in a perfectly documented manner).

Comment 49

[mmortal03]

Which bug broke the old behavior of "View Image"?  I think "View Image" is
either now working like "Load/Reload Image" or not at all.  "View Image" should allow one to view just that image in the current window, or if middle clicked, in a new window, as it used to be.  A new option should be created for loading/reloading an image in the current page, and that other option needs left alone. It would say "Load Image" if the image didn't initially load, and "Reload Image" if the image did load.  Please refer me to the right bug report if this one isn't it. I searched all over for bugs regarding "View Image", and found very few possibly relevant bugs.

Comment 50

[mmortal03]

I apologize for any ambiguity in the previous message.  It looks as if "View Image" is in fact just broken (just for me, or not, I am not sure).  "Show Image" is in fact a separate option.  If there is a bug report for "View Image" being broken, please refer me in that direction.  If this is the one, then thanks.

Comment 53

[reb]

One can hack the binary executable, void your warranty: locate appropriate occurrence of "Content-disposition" string, deliberately and very carefully respell it without length change of string or file, and suffer side-effects like no longer seeing filename option that rides in same header.

Could an extension (or yuck a proxy) edit/filter response-headers on-the-fly in time to usefully address this?

Comment 54

[Vincent Lefevre]

Following the answer to my bug report in Debian, FYI, the current Firefox behavior is covered by the recent draft (first version on 2010-08-30):

  http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-03

(note: this is just a draft). It says:

   If the disposition type matches "attachment" (case-insensitively),
   this indicates that the user agent should prompt the user to save the
   response locally, rather than process it normally (as per its media
   type).

Personally I find this rather annoying that web sites force me to do things I do not want, in particular when I've entered the URL in the address bar, and at least the choice should be offered to the user. I event think that user agents should be able to ignore "attachment" completely (i.e. treat "attachment" as "inline").

Comment 55

[James May [:fowl2]]

The important thing is to treat the content as unique origin (ie. no origin).

Comment 56

[Adam Borowski]

I agree with that IETF draft: Content-disposition being "attachment" vs "inline" lets the server suggest the default action.  Thus, having the dialog pop up is fine.

But, not allowing content types that Firefox can handle (text/plain, image/png, etc) is to be viewed directly is a clear-out bug.  Dancing through hoops like saving the file to some random place then opening it manually is a ridiculous workaround.

The dialog already has "open with XXX", "open with YYY", "save as"; it's a matter of adding "open with Firefox".  Since there is a checkbox to do that automatically on all future files, a separate config option as suggested in #39 would be redundant if we got that.

Comment 60

[Nicolas Barbulesco]

(In reply to Robin Lu from comment #30)

> > Finally, this will open a new window for some reason.  We really want to just
> > load the data in the window where it started to load (so session history and
> > the like is preserved).

> I think as far as we respect the content-disposition and treat it as an
> attachment, it could not be so unacceptable as to download it and view it in
> a
> new brower window. Is that right?

For me, this would not be acceptable. Please see this request :

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

Comment 61

[Shad Sterling]

I started thinking about how I would prefer this be handled, and this is what I came up with.

1. Create error/info pages for cases where Firefox receives a response with a type it has no mechanism display in its own tab or where a response cannot be displayed because the content does not match the type, include information about the type and disposition, include buttons to invoke part 2 (including use defaults without prompt) and part 3 (including reversion without prompt), include buttons to open files this content was saved to by part 2 in helper apps.

2. Replace the current Save As dialog box (which at least on Mac OS is a separate window that can get lost behind everything) with a tab-bound sheet, add an option to go back one stop in session history if saving succeeds, add options to control automatic invocation of Save As and automatic saving on similar future responses, add a button to invoke part 3.  Saving content to which part 1 applies adds a button to the page described in part 1.

3. Add a "Reinterpret Content" sheet to change the effective type used to render the contents of the current tab (without reloading) or to select a helper when opening from part 1, include interpretation choice which always invokes part 1, include option to open Save As after reinterpreting, include options to automatically reinterpret similar future responses, include options to revert a changed interpretation of the current tab to either the default or the result of applicable automation rules.

4. Revise handling of request responses to honor the automation options in parts 2 and 3.  I think the current behavior would make a reasonable default.  This automation does not apply to navigation within the session history (e.g. with back or forward buttons), only to new responses.

This way, every link adds a page to the session history, the page associated with a downloaded file has a button to open that file in the helper app, and a Save As prompt can't get lost behind other windows.  The rules for automatic invocation of Save As and automatic saving wouldn't need to change much, but should give the user explicit control of how(/if) that behavior is affected by a disposition header.  The rules for automatic reinterpretation might be difficult to get right, but could initially be a simple list of from→to pairs that gets checked before any rendering or saving is done.  There is a funny case where a response could be automatically saved and then rendered in the tab without mentioning the save to the user; that could be prohibited, or handled by a notification bar.

Most comments in favor seem to want part 2 without part 1, which might be easier to implement, but I think it's more natural to put something in the session history for every request and keep external actions external.  Part 3 is really more bug 57342, so I'll mention this comment there too.

Comment 63

[James May [:fowl2]]

This was fixed for PDFs in bug 773942
Fixed in general in bug 1639067 🎉

Comment 64

[Gingerbread Man]

(In reply to James May [:fowl2] from comment #63)

Fixed in general in bug 1639067 🎉

That's about files that have already been downloaded and the downloads panel (the doorhanger you get when clicking the downloads icon). This is about the download prompt, which you get when the server sends Content-Disposition: attachment.

Open in Browser can be used as a workaround.
https://addons.mozilla.org/firefox/addon/open-in-browser/

Comment 65

[James May [:fowl2]]

It does seem I spoke too soon - bug 1639067 only seems to have added a few extra file types (xml,svg,webp,avif). Those types do now show the "Open in [Browser]" option in the download dialog.

Comment 66

[Ted Pianalto]

Attachment: thehodesul19771305.txt

Thanks from leulispheback1982.