"Always do this from now on" does not work

[Rüdiger Kupper]

Downloading an unknown file type in Firefox displays a dialog for choosing which application to use for opening the file.
The dialog contains a check box labelled "Always do this action from now on".
Checking this option does not work: When I download a file of the same type next time, the same dialog is displayed again.

This feature is broken for as long as I can remember (> 10 years). It's time it was fixed (or removed).

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: firefox 15.0.1+build1-0ubuntu0.12.04.1
ProcVersionSignature: Ubuntu 3.2.0-31.50-generic 3.2.28
Uname: Linux 3.2.0-31-generic x86_64
NonfreeKernelModules: nvidia
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ruediger 2536 F.... pulseaudio
BuildID: 20120907231657
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfe220000 irq 49'
   Mixer name : 'Analog Devices AD1984'
   Components : 'HDA:11d41984,17aa20bb,00100400'
   Controls : 32
   Simple ctrls : 20
Card29.Amixer.info:
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 7KHT24WW-1.08'
   Mixer name : 'ThinkPad EC 7KHT24WW-1.08'
   Components : ''
   Controls : 1
   Simple ctrls : 1
Card29.Amixer.values:
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Channel: Unavailable
Date: Wed Oct 10 18:17:44 2012
EcryptfsInUse: Yes
ForcedLayersAccel: False
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
IpRoute:
 default via 172.31.0.1 dev wlan0 proto static
 169.254.0.0/16 dev wlan0 scope link metric 1000
 172.31.0.0/20 dev wlan0 proto kernel scope link src 172.31.9.26 metric 2
MostRecentCrashID: bp-7716491c-74b4-4213-bbf0-37b512110505
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=15.0.1/20120907231657 (In use)
RelatedPackageVersions:
 rhythmbox-mozilla 2.96-0ubuntu4.2
 totem-mozilla 3.0.1-0ubuntu21.1
 icedtea-6-plugin 1.2-2ubuntu1.2
RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: Upgraded to precise on 2012-04-28 (165 days ago)
dmi.bios.date: 03/18/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETC9WW (2.29 )
dmi.board.name: 6457BBG
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7LETC9WW(2.29):bd03/18/2011:svnLENOVO:pn6457BBG:pvrThinkPadT61:rvnLENOVO:rn6457BBG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 6457BBG
dmi.product.version: ThinkPad T61
dmi.sys.vendor: LENOVO

[Erik-staats (erik-staats)]

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Many users have requested in bug 331259 and others the ability to automatically download files even when the file is sent with the "Content-disposition: attachment" header. They would like to ability to bypass the security guidelines in RFC 2183 and automatically download these files.

The fix in bug 331259 addressed an issue with saving the automatic download checkbox settings and did not attempt to address any issues related to RFC 2183.

Hopefully, this bug will serve as a better location for the discussion of the user requests, since bug 331259 has been marked fixed.

Reproducible: Always

[Kevin Brosnan (kbrosnan)]

Bugzilla is not a place for discussion. Please use nntp://news.mozilla.org/ mozilla.dev.apps.firefox or http://groups.google.com/group/mozilla.dev.apps.firefox

[Kevin Brosnan (kbrosnan)]

Automatically downloading attachment sent files is bug 285976.

[Erik-staats (erik-staats)]

(In reply to comment #2)
> Automatically downloading attachment sent files is bug 285976.

It sounds like bug 285976 is to disable the "automatically download" checkbox with "Content-disposition: attachment" headers. That's not what users are requesting in bug 331259.

[Jruderman (jruderman)]

Sounds reasonable to me. As far as I know, web sites use "content-disposition: attachment" as a security measure to mean "don't treat this as a web page served from this server", not "make sure the user is prompted before the file is downloaded".

Boris seems to be claiming otherwise in bug 285976, but I'm not convinced. Even with his "deliberately unhelpful PDF reader application" use case, remembering the action as "download" wouldn't be a problem. The only problem would be remembering the action as "open with (deliberately unhelpful PDF reader application)" and then not figuring out how to undo that remembering. That problem exists even without content-disposition: attachment and I don't think working around it is a major use case for content-disposition: attachment.

RFC 2183's wording only makes sense to me in the context of mail messages, not in the context of link clicks. I don't see how fixing this would be a security problem. What would be a security problem is "fixing" bug 185618.

Boris, are you actually against having this UI change in Firefox, or are bug 236541 comment 38 through 48 just about implementation details?

[Bzbarsky (bzbarsky)]

I can live with remembering the "save" action, no problems. We just shouldn't be remembering the "open in app" or "view in browser" actions in this case.

Note that the behavior websites _really_ want here, typically, is to force save with no user choice (what IE does), and we're just giving the user more options. We've had bug reports about the user having said options, but we sort of stand by that.

This is basically what bug 236541 comment 38 says, and honestly, I'm sort of tired of going over this argument again and again and again....

[Domenic (domenic)]

Not fixing this bug (and I mean a real fix, not Boris's preferred one) has caused me to switch to Chrome, which doesn't have this problem.

Sorry guys, Firefox was fun, but I download way too many .torrents to put up with this shit. I just want to open the damned things with with muTorrent instead of going through a downloading + finding in Explorer + opening adventure safari.

[Shawn Wilsher (sdwilsh)]

Can we *please* not have this turn into bug 331259 and actually follow bugzilla etiquette [1] here? That means no comments saying "Please fix this" or "This made me switch to browser X". The only impact it has on getting this fixed is a negative one because developers don't want to pay attention to a bug that has all sorts of comments like that. Please don't scare away the developers.

[1] https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

[Mbeltzner (mbeltzner)]

From what I can tell reading through some of the backlog litany here, there are two issues concerning this bug:

Issue 1: "content-disposition: attachment" was created specifically and only to allow a server to specify "this file should be treated as an 'attachment' and only saved to the disk, not displayed inline"

Is there any other reason why servers would use "content-disposition: attachment" other than to signal that the file is not to be loaded inline? Are we running into a case where the actual State of The Web differs from the Intent of the Spec?

Issue 2: When users click "[ ] Always do this" the UI should listen

bz, you point out in comment 5 that this is probably OK to do as long as the actions don't include "view inline" or "open in app." I understand your objection to "view inline" since that's the entire point of "content-disposition: attachment", but "open in app" is simply saving the user a double click and I don't see any real argument why just because something is meant to be an attachment doesn't mean that if a user takes the action to click on it we can't automate the "open" step after the "download" step.

It sounds to me like what we actually want to do is ensure that "view inline" is never offered for files that are served with "content-disposition: attachment". Is that bug 285976?

[Gavin Sharp (gavin-sharp)]

bz isn't CCed, but he explained his reasons for why opening with a helper app is not a good idea in bug 236541 comment 40, bug 236541 comment 102, and bug 236541 comment 107.

[Gavin Sharp (gavin-sharp)]

(In reply to comment #8)
> It sounds to me like what we actually want to do is ensure that "view inline"
> is never offered for files that are served with "content-disposition:
> attachment". Is that bug 285976?

No. That bug is about disabling the "always do this" check box for content-disposition: attachment (because in those cases we're not going to honor it anyways).

[Mbeltzner (mbeltzner)]

(In reply to comment #9)
> bz isn't CCed, but he explained his reasons for why opening with a helper app
> is not a good idea in bug 236541 comment 40, bug 236541 comment 102, and bug
> 236541 comment 107.

bug 236541 comment 40 - this is about helper apps that view the content inline, which isn't the same as "Open in app" which launches an external application

bug 236541 comment 102 - this is about files which are downloaded to a temp directory, used by a helper app which views the content inline, and then deleted

bug 236541 comment 107 - OSX downloads now default to the Downloads directory, and seems to also be related to a common request to have PDFs viewed inline

In all these cases, I'd be fine if the files served with content-disposition: attachment were *not* handled by helper apps (which I see as equivalent to "view in browser") but rather forced to be downloaded and handled by external apps.

Allow me to make my point clear with an example: let's say I've got a page with a link to a PDF or a WMV:

 - if served using content-disposition: attachment, the options that the user would have would be "Save to disk" and "Open with [some app]". In both cases the file would be downloaded using the download manager, if the user selected "Open with [some app]" we'd run the open step as well. "View in Browser" would not be available, nor would we hand the file to a plugin/viewer registered to handle that content.

 - if served any other way, plugins/viewers would be able to download the file to a temp directory, view the content inline and then dispose of it; "View in Browser" would be an option in the handler window

This allows the UI checkbox to be honoured while, I believe, covering the cases and spirit of the RFC.

[Kevin Brosnan (kbrosnan)]

(In reply to comment #8)
> Is there any other reason why servers would use "content-disposition:
> attachment" other than to signal that the file is not to be loaded inline? Are
> we running into a case where the actual State of The Web differs from the
> Intent of the Spec?

Blogger uses content-disposition: attachment on images ex. http://4.bp.blogspot.com/_7ZYqYi4xigk/SLwuftMrEII/AAAAAAAABtU/eTT5kKVNxBE/s1600-h/collage_and_text.png which is actually a HTML page and if you right click and choose view image it is served as an attachment.

[Shawn Wilsher (sdwilsh)]

(In reply to comment #12)
> Blogger uses content-disposition: attachment on images ex.
> http://4.bp.blogspot.com/_7ZYqYi4xigk/SLwuftMrEII/AAAAAAAABtU/eTT5kKVNxBE/s1600-h/collage_and_text.png
> which is actually a HTML page and if you right click and choose view image it
> is served as an attachment.
I'm betting that's so people cannot hotlink images to their site from another site.

[Gcklema (gcklema)]

(In reply to comment #5)
> I can live with remembering the "save" action, no problems. We just shouldn't
> be remembering the "open in app" or "view in browser" actions in this case.
>
> Note that the behavior websites _really_ want here, typically, is to force
> save with no user choice (what IE does), and we're just giving the user more
> options. We've had bug reports about the user having said options, but we
> sort of stand by that.

Boris, I thank you (or whoever did it) for changing the behavior to disable the dialog when the option to "save to disk" is selected, and allowing users more choices and more freedoms to browse the web how they see fit. I believe the current issue (and it is an issue for many people) should follow the same spirit. No one's asking for an easy UI implementation that would easily bypass RFC 2183 (and thus increase the likelihood that people will accidentally make the change and not realize its consequences). Changing this behavior/setting could deliberately be buried and difficult to implement, but for those who really want to change it they can still do so.

> This is basically what bug 236541 comment 38 says, and honestly, I'm sort of
> tired of going over this argument again and again and again....

We shouldn't be arguing about this. It's a simple matter of allowing the user to do what THEY want, not what YOU want or what some guidelines specify. It's not a law--no one is going to hunt you down, put a gun to your head, and force you to change it back. You could make this change if you wanted to. There are plenty of informed people out there who would gladly take the risk of inadvertently (or even unknowingly) downloading something harmful to avoid the *daily* hassle of this dialog box.

Regarding the frequency of this behavior, in my experience files with the content-disposition:attachment header are at least as common as those with other headers that don't (supposedly) pose a security risk per RFC 2183. Actually now that I think about it, what would prevent malicious code from being placed into a file with a header that doesn't require RFC 2183???

The bottom line is that this is about user choice & freedom. Please consider making this change.

[Gavin Sharp (gavin-sharp)]

(In reply to comment #11)
> bug 236541 comment 40 - this is about helper apps that view the content inline,
> which isn't the same as "Open in app" which launches an external application
>
> bug 236541 comment 102 - this is about files which are downloaded to a temp
> directory, used by a helper app which views the content inline, and then
> deleted
>
> bug 236541 comment 107 - OSX downloads now default to the Downloads directory,
> and seems to also be related to a common request to have PDFs viewed inline
>
> In all these cases, I'd be fine if the files served with content-disposition:
> attachment were *not* handled by helper apps (which I see as equivalent to
> "view in browser") but rather forced to be downloaded and handled by external
> apps.

The "helper apps" bz is referring to in comments 40 and 102 and what you call "external apps" are the same thing. They are distinct from plugins, which show content inline in the browser. Boris is talking about external apps that won't let you save the file while you're viewing it, which, due to the fact that we delete temp files after they've been used, means that there's no way to ensure that users are able to save the file (i.e. treat it like an attachment).

(The fact that we don't delete temp files on Mac, and save them on the Desktop by default, means that he is less concerned about allowing automatically opening the files in helper apps on Mac. This is what comment 107 is about.)

I'm not sure that I buy his argument, because I can't really think of any apps that don't let you save a copy the file once it's opened (e.g. "Save as").

[Ivan Yosifov (iyosifov)]

Since there doesn't appear to be consensus on what to do, could you at least provide an about:config option for people who really want to change this ?

[Bugzilla-tf (bugzilla-tf)]

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

[Majuki (majuki)]

Summary of the elements of the issue:

1) RFC 2183 specifies content-disposition: attachment trigger a 'Save response as...' user prompt, requiring action by the user.

2) HTTP 1.1 echos this

3) User's desire is to have a save yet seamless low click experience

4) The desire of content providers to have access to differing ways of interacting with the user and user agent.

Three of the four elements support the current implementation. So how can the UI be improved in a manner that does not detract from the spirit of RFC 2138? It only requires that the 'Save response as...' dialog box be presented to the user so they can take appropriate action. This does not require the user agent to have 'Save response as...' as the selected option, nor does it specify the other elements that can/cannot appear on the 'Save response as...' prompt.

This can allow for several UI options:
- Allow the 'remember my choice' to remember the last program that was chosen to be entered as the default helper app with browse next to it.
- Have 'open with' as the default selected option
- Integrate the list of programs into the dialog box and eliminate the 'browse' button. An example of this would be take the existing list and integrate it on the right hand side of the dialog box, showing only if 'open with' is selected

Comparing the current version to a version with all three of these options implemented:

Current - user wishes to save file
-------
1. Click link
2. Click ok, saves to default location

Current - user wishes to open with program
-------
1. Click link
2. Click 'open with' option
3. Click 'browse'
4. Double click helper app
[possible](5). Click remember choice (thinking it will save this choice for next time)
(5-6). Click ok

Proposed - user wishes to save file
--------
1. Click link
2. Click save file
3. Click ok

Proposed - user wishes to open file with program
--------
1. Click link.
[if previously 'remembered']
2. Click ok.

[if first time for this type]
1. Click link.
2. Click 'open with'.
[optional](3). Click 'remember selection'
(3-4). Double click helper app

Lets say the user chooses to save 1 file and open 2:
- Current method total clicks: 12-16
- Proposed method total clicks: 9 (both when remembering and when not)

The reverse scenario to save 2 files and open 1 (assuming first time):
- Current method total clicks: 9-10
- Proposed method total clicks: 9-10

This I believe clearly shows why many users see this as a UI issue. Those who use helper apps more often than saving are clicking 3-7 extra times where it is not needed. This can further be improved by allowing 'Remember my selection' to also save the default selected radio button as well. This allows users who save more often to select that as the default for that type and save 1 click per download there after while adding that click back to the 'open with' option.

This proposal conforms to the RFC spec and requires the user to make a selection and improves the user experience across the board.

I'll be at the Changing The World conference on the 15th, I'm eager to hear Mike Beltzner's take on UI

[Vladimir Vukicevic (vvuk)]

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

[Mbeltzner (mbeltzner)]

Carrying over vlad's blocking flag from bug 469746

[Shawn Wilsher (sdwilsh)]

(In reply to comment #20)
> Carrying over vlad's blocking flag from bug 469746
So, I don't think that this should block 1.9.1 for a number of reasons (in no particular order):
1) We've shipped with this for ever (really, for ever)
2) This would make us violate RFC 2183 (cc'ing bz for this, and bz - sorry; I know you are tired of discussing this issue)
3) We have no UX spec for this, and as submodule owner, I find it unacceptable to make this just work (for being in violation of RFC 2183). In reality, that means I find that this should be WONTFIX.

With that said, I think comment 18 has some potentially better user experiences, and we should file a bug for the right user experience.

[Bzbarsky (bzbarsky)]

(In reply to comment #15)
> I'm not sure that I buy his argument, because I can't really think of any apps
> that don't let you save a copy the file once it's opened (e.g. "Save as").

Acrobat Reader, if the right bits are set on the PDF. It'll let you edit the PDF, and read it, and print it, but not save it. Yes, it's weird. Yes, other PDF viewers have similar behavior if those bits are set. Yes, it's required by the PDF spec last I checked. Yes, plenty of PDFs out there have those bits set; about half of the job application PDFs Emma is running into as part of her job search seem to. The expectation is that you fill it out, print it, and send it in, but don't save it, apparently.

It's also possible to create Word documents that behave this way, for what it's worth. I don't know _why_ people do it, but they do. Just Google "prevent save as in Word" for all the fun you want.

I've also encountered some image viewers (admittedly, harder to find nowadays) that have no "save as" at all, because they're just viewers, not editors.

Comment 15 is correct in terms of terminology. If I meant "plug-in", I would say "plug-in". "Helper app" is what we've used for external apps all along.

(In reply to comment #14)
> Actually now that I think about it, what would prevent malicious code from
> being placed into a file with a header that doesn't require RFC 2183???

Nothing, on your own site which would then get blacklisted as soon as the problem is discovered. On the other hand, obeying RFC 2183 prevents you from uploading your malicious stuff to some other site that just wants to let people upload things. At least if said other site is a little careful.

(In reply to comment #18)
We should already be saving the helper app the user selected last. If we're not, that's a bug (and a regression from the XPFE dialog). If we're not doing that, please file. The only other thing proposed in comment 18 is that we remember the last-selected choice but don't execute it. I would be fine with that, I think, since it gives the user a chance to select the other option if the default one is giving broken behavior.

(In reply to comment #21)
(1) Yes
(2) imo, yes, if we just run a helper app without prompting. Certainly yes if
    we handle internally in any way, but I don't think anyone's suggesting that.
(3) Agreed on lack of spec.

That all said, if we in fact don't save the user-selected helper app, _that_ should be considered for blocking status, imo. Even if Firefox has shipped that way "forever".

[Majuki (majuki)]

Created attachment 353350
Comment 18 Concept Mashup

I made a (very) quick mockup of my proposal. Basically if open with is selected the options are available right away with "browse" for additional options. It has a "Select this option next time" instead of "do this" so the user knows it will not be automatically done. If "Save as" is selected it should disable but still show the right hand portion of the box.

[Vladimir Vukicevic (vvuk)]

(In reply to comment #22)
> That all said, if we in fact don't save the user-selected helper app, _that_
> should be considered for blocking status, imo. Even if Firefox has shipped
> that way "forever".

Yep, that's the core of the issue I think -- the same dialog shows up as with non-attachment downloads, except that the "Open With: [...]" bit is always blank, even if there is a helper app defined for that document type. Also, the "Always do this" checkbox is misleading in this case. I think it would be perfectly acceptable if this dialog always popped up for attachment downloads, but without the checkbox, and with the helper app pre-filled if defined.

[Gcklema (gcklema)]

(In reply to comment #22)

> (In reply to comment #14)
> > Actually now that I think about it, what would prevent malicious code from
> > being placed into a file with a header that doesn't require RFC 2183???
>
> Nothing, on your own site which would then get blacklisted as soon as the
> problem is discovered. On the other hand, obeying RFC 2183 prevents you from
> uploading your malicious stuff to some other site that just wants to let people
> upload things. At least if said other site is a little careful.

Well, then that's the point: Malicious files will be blacklisted as soon as they are discovered, so that should have no bearing on how the user wants to interact with their content. Without question, safeguards can and should be put in place, but they should not prevent a user from deliberately choosing to ignore them. There are innumerable ways in which a user could deliberately expose themselves to harm that are not barred by Firefox or any internet rules. So why is this case any different? I believe it is because the developers are misinterpreting the MIME standards.

I believe most (if not all) of this behavior occurs with application/octet-stream MIME types. According to RFC 2046 (addressing security issues in MIME types), under section 4.5.1 for application/octet-stream entities:

   "The recommended action for an implementation that receives an
   'application/octet-stream' entity is to simply offer to put the data
   in a file, with any Content-Transfer-Encoding undone, or perhaps to
   use it as input to a user-specified process.

   To reduce the danger of transmitting rogue programs, it is strongly
   recommended that implementations NOT implement a path-search
   mechanism whereby an arbitrary program named in the Content-Type
   parameter (e.g., an 'interpreter=' parameter) is found and executed
   using the message body as input."

A plain reading of this text reveals that it is RECOMMENDED to avoid automatically executing on undefined (/octet-stream) MIME types; it is not a strict rule to prevent such action by the user.

According to RFC 2183, the purpose of the MIME framework is to provide "for the interchange of message content, but leaves presentation issues solely in the hands of mail user agent (MUA) implementors". This text suggests it is up to Mozilla to define how to handle presentation issues, and thus it is within the purview of developers to determine how Firefox handles these MIME types. I agree that the default behavior should be for increased security, but the MUA (program=Firefox) should not prevent the user from selecting another less secure behavior should they so desire.

RFC 2183 does not explicitly state the MUA must disallow any potential non-secure behavior:

   "There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard."

The key text here is "A RECEIVING MUA MUST TAKE CARE THAT THE SENDER...

[Bzbarsky (bzbarsky)]

> I think it would be perfectly acceptable if this dialog always popped up for
> attachment downloads, but without the checkbox, and with the helper app
> pre-filled if defined.

That's the behavior it had in Seamonkey (then Mozilla suite) after the last time I touched it. If someone broke things since, we should fix them, of course. It might be good to have a new clean bug with just this, not the various other changes people want to make here, as the goal, and just fix it in the Firefox unknown content dialog.

I think I'm done here, since this bug is getting really spammy, just like every single other bug I've seen on this issue.

[Shawn Wilsher (sdwilsh)]

(In reply to comment #26)
> That's the behavior it had in Seamonkey (then Mozilla suite) after the last
> time I touched it. If someone broke things since, we should fix them, of
> course. It might be good to have a new clean bug with just this, not the
> various other changes people want to make here, as the goal, and just fix it in
> the Firefox unknown content dialog.
I agree, and I've filed bug 470332 to get that done. As it stands, this bug is WONTFIX.

[Gcklema (gcklema)]

(In reply to comment #26)
> I think I'm done here, since this bug is getting really spammy, just like every
> single other bug I've seen on this issue.

Spammy? I think the number of posts (and duplicates of this bug) speak to how many people want to see this FIXED (and their frustration at the developer's stonewalling). This issue isn't going to go away just because you don't want to deal with it.

Answer me this: how much effort would it require to implement the desired change? If it's really a cost-benefit (dev time/effort vs. the number of people who want it fixed) analysis, then say so. I can accept that. I just find it hard to believe the developers really want to adhere to standards (at least their interpretation of them) as the reason this UI behavior can't be changed.

If you can't answer my comment #25 with a cogent argument against it, then tell us all what the real reason is for not addressing this concern?

[Gavin Sharp (gavin-sharp)]

No one is "stonewalling" - Shawn's filed bug bug 470332 on remembering the choice of helper apps, bug 285976 exists to cover not offering to remember when we won't save the choice, and I've just filed bug 470514 to cover making it possible to remember "Save as" as a choice, per comment 5. I think those bugs together address most concerns adequately.

[Jruderman (jruderman)]

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

[Adamthelibertarian (adamthelibertarian)]

I'm just a user, so excuse the stupidity, but could someone please tel me why I have to click twice to view a photo? Firefox clearly recognizes that it is a picture, but is ignoring my request to just open the GD thing. Is it a security issue? If yes, why won't you let me be the judge of my own security? Alternately, why have the box to check? This is not a new annoyance, I've just been too lazy to do anything about it before. But I've just had to open a couple of dozen pictures from my Yahoo email by clicking TWICE AS MUCH as I should have to, and it has officially gotten to be a pain in my butt.

[Gbrow6373 (gbrow6373)]

I am in the same boat as comment #31. Very frustrating. Does the status "wontfix" mean that this will never be fixed and if so can anyone give a reason a layman can understand ?

[Mike Connor (mconnor)]

Layman explanation:

* You don't need to click on anything to get something sent with content-disposition: attachment.
* Automatically opening arbitrary content enables drive-by attacks (go to page, page sends content containing an exploit, app gets launched to open content, user gets owned).
* This behaviour is effectively "let any page on the Internet pass arbitrary content to this application"
* Explaining why the oh-so-convenient option is actually compromising your system security is rather ineffective (see the various research on the incredibly poor effectiveness of warning dialogs).

[RaduStoica (radumstoica)]

Hello,

  The problem might be on the server end, not in Firefox. Read more here: http://kb.mozillazine.org/File_types_and_download_actions#Unable_to_set_an_automatic_action .

[Rüdiger Kupper (ruediger.kupper)]

I see. So this is likely a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=453455.

[Rüdiger Kupper (ruediger.kupper)]

OT: How do I mark a bug "duplicate" in launchpad, when the relevant bug report is in bugzilla?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Edward Donovan (edward.donovan)]

Rüdiger -

I added that upstream bug by picking "Also affects project". That gave me a page where I could enter the link. Thanks.

[Andreas-fischlin (andreas-fischlin)]

@Tristan Miller: You are right, that may be a better contribution. However, I cannot afford to participate in the development of all software I am using and need to focus on the ones I am really responsible for. And I also believe that programing does not consist of only adding patches, but good design requires familiarity with a software product, and I am lacking all this in the case of Firefox. I think my decision to abstain in this case is the right one. Given all this, I am afraid, my verdict remains: Keeping a bug (and with it many related ones) open for 13 years that confuses every user of Firefox (and AFAIK also Thunderbird) repeatedly since years is IMHO not representative of good programing. P.S.: And I provided very detailed suggestions how to handle downloading, including graphical designs for alerts to the last letter, yet all this was ignored. I am sorry, this did also not invite me to continue to participate in the development. I hope you can understand that also a bit.

[Andreas-fischlin (andreas-fischlin)]

@Tristan Miller: As you seem to be a programmer of Firefox: Many, many thanks. I like otherwise Firefox and I am generally very happy about it. So, indeed many, no a thousand thanks!!!!!

[Vagmer (vagmer)]

(In reply to Tristan Miller from comment #169)
> As a programmer yourself, it can't be such a big deal for you to submit a patch that does exactly this. This would certainly be a more collegial and productive course of action than publically berating others for what you consider to be "very poor programming".

They simply laid out their view on the current state (well, continuous for years) of this matter, and were honest... There wasn't attacking of people or calling names. I'm sorry you were offended by that. You most likely concur with the sentiment that this part of the application and it remaining as it is for long are both not good... I don't think it's a reasonable expectation that people will just hide it or lie about it while discussing it.
A patch submission doesn't preclude accompanying discussion anyway, but I think it's also disingenuous to call it more productive... unfortunately we know that even if patches were offered even years ago, as previously discussed here, it doesn't mean that they would have been used or made a difference in the issue. In the first place this issue isn't one where implementation details are complex, unknown or time consuming to write. It is pretty clear that it is one of those where there just hasn't been a decision by Mozilla to fix it, or to apply the band-aid solution, and that decision is the only thing that is missing (indeed I expect it would take a programmer with experience with contributing to the project a couple of minutes to handle the implementation). Yeah, that's a kind of thing that unfortunately doesn't exactly invite people to contribute to the project in general.

[Psychonaut (psychonaut)]

(In reply to vagmer from comment #172)
> A patch submission doesn't preclude accompanying discussion anyway

_If_ someone submits a patch or other new, concrete information that will lead to a fix, _then_ let's discuss it here. Until then, please see [Comment 1](https://bugzilla.mozilla.org/show_bug.cgi?id=453455#c1) (though note that the specific venues mentioned there have recently moved).

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

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

[Gcklema (gcklema)]

(In reply to Tristan Miller from comment #173)
> (In reply to vagmer from comment #172)
> > A patch submission doesn't preclude accompanying discussion anyway
>
> _If_ someone submits a patch or other new, concrete information that will lead to a fix, _then_ let's discuss it here. Until then, please see [Comment 1](https://bugzilla.mozilla.org/show_bug.cgi?id=453455#c1) (though note that the specific venues mentioned there have recently moved).

There is still no clear explanation from any dev about either (A) why they don't think this is a bug, or (B) why they're not willing to fix it. As someone like @andreas.fischlin, I don't have time to learn the inner workings of the FF code and then program a hack workaround. And the true fix for this by Moz would take minutes, far less time than devs have spent reading this discussion. Please, fix this bug.

[Bugsgalore (bugsgalore)]

This is really annoying when you want to view several PDFs from a webpage in Firefox ,but the "choose action" pop-up gets in the way repeatedly even though it is clear I want to view the PDF files in Firefox without opening a separate application for it.

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Wls220spring (wls220spring)]

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

[Wrhenshaw99 (wrhenshaw99)]

They have not decided if this is a bug or not? It worked fine for me in TB 6x.x and TB 7x.x and now is broken in TB 91.0. Thunderbird is not honoring it's own setting. How can this not be a bug? This is a 13 year old bug. My problem just started. Something obviously changed in TB 91.0. Please fix this bug. It is very annoying.

[Bmercer (bmercer)]

The decision was made years ago. This will never be fixed, but actually SAYING it will never be fixed will generate negative comments. Better to quietly ignore it.

[Wrhenshaw99 (wrhenshaw99)]

But the problem was just introduced in TB 91.0 for me. It has worked correctly for at least 10 years.

If they have decided that this problem won't be fixed then why even offer the option "Do this automatically for files like this from now on." if it isn't going to work?

[Wrhenshaw99 (wrhenshaw99)]

Also... why is this listed as an enhancement. A setting in their existing program doesn't work. This is a BUG not an enhancement.

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Worcester12345 (worcester12345)]

(In reply to bmercer from comment #180)
> The decision was made years ago. This will never be fixed, but actually SAYING it will never be fixed will generate negative comments. Better to quietly ignore it.

If that is the case, then someone needs to just mark the bug as "WONTFIX" and be done with it.

[Nolanktx (nolanktx)]

I've been waiting for a long time for a fix on this as well, but it appears that it is not going to happen.

Sad that the problem does not seen to rise to someone's level of concern.

One can consider the new soft-fork of Thunderbird that is called Betterbird and that client works just fine with these issues fixed.

[Smayer97 (smayer97)]

What is hard to understand is the following:

- this was never a problem (for me) prior to v57 of FF, as early as v16, which is only 6 years old, so not sure why this is a 13 yr old bug. Then again, I was running it on Mac OS X 10.6.8 until then, so is this an OS dependent issue?

- what is so hard to get this fixed? Isn't it simply to save the option selected then read it when downloading? How complicated can this be? Especially since the algorithm for this already exists in older versions.... just copy the design, no?

[Pablo-muir (pablo-muir)]

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

[Bob-nelson-v (bob-nelson-v)]

This bug isn’t an enhancement and it’s never getting fixed so it should be closed as WONTFIX instead of leaving it open for 13 years.

Add this defect to list of pull requests for when FF is forked to a more community version.

[Worcester12345 (worcester12345)]

This should be changed to Priority 1, Severity High.

[Andreas-fischlin (andreas-fischlin)]

(In reply to smayer97 from comment #186)
> What is hard to understand is the following:
>
> - this was never a problem (for me) prior to v57 of FF, as early as v16, which is only 6 years old, so not sure why this is a 13 yr old bug. Then again, I was running it on Mac OS X 10.6.8 until then, so is this an OS dependent issue?
>
> - what is so hard to get this fixed? Isn't it simply to save the option selected then read it when downloading? How complicated can this be? Especially since the algorithm for this already exists in older versions.... just copy the design, no?

No, this has nothing to do with the OS. This is a problem within the application only. And sorry, I am not going to describe the reasons for that once again. I have provided all details including several solution suggestions many years ago and I am now tired of these discussions going often in circles instead of resolving the issue(s).

[Worcester12345 (worcester12345)]

(In reply to Worcester12345 from comment #189)
> This should be changed to Priority 1, Severity High.

Ahem. This was NOT "advocacy". It was instructions for someone to change the bug fields.

[Bmercer (bmercer)]

Can you please just mark it WONTFIX so we can move on?
Keeping it open is just giving people false hope that it might actually be fixed, when it's obvious that it never will.

[Nolanktx (nolanktx)]

I've been following this 'broke item' for some time and have also submitted a couple tickets related to same. Albeit was amazed when someone tied my ticket to this 13-year old item. Never would have thought that could have happened.

As many have noted the 'choose file open' item WAS working just fine until sometime last later spring/early summer. Don't see how something that WAS working and then became broke has turned into a 13-year old problem that someone/somewhere says will NOT be fixed.

Just how stupid is that?

Anyway ... in the meantime, while waiting for a repair I've become aware of a soft fork of Thunderbird that is called Betterbird. And, BTW, the File Open situation has been repaired.

As we wait for Thunderbird to act on repairs ... consider using Betterbird until then: https://www.betterbird.eu/

[Andreas-fischlin (andreas-fischlin)]

I am not sure we understand each other well. The first issue is that the download folder is not separate from the folder where FF downloads files such as PDFs to when you want to look at that file within FF. The first folder should be the download folder, which the user can set to her wishes via preference setting. The 2nd folder should be a temporary folder, where FF stores those files the user just wants to look at using the browser and that folder ought to be under any Unix system a temporary folder, e.g. in /private/tmp. As I do not want the 2nd use to clutter up my actual downloads folder, I have set as the FF download folder a temporary foler in /private/tmp. Any true download has then to be retrieved from there manually. That is the first problem with FF, never addressed really, never resolved I believe since 13 years if I am not mistaken. The 2nd problem associated with truly downloading files only is the fact that FF did not honor the checkbox "Do this automatically for files like this from now on." when downloading some file type, e.g. a PDF and chosing some application by which to open it. Checking that checkbox never had an effect and FF continued for years to ignore the users choice.

My take on this is that FF should distinguish the two folders used for only looking at a file, e.g. a PDF from within FF, or actually downloading, i.e. truly downloading a file.

The 2nd fix would be to either hide a not functioning checkbox or then implement the feature the checkbox is offering.

[Rachel-u (rachel-u)]

(In reply to NolanK from comment #193)

Just to set the record straight: The fork you mentioned did NOT fix this bug. If fixed bug 1690395 with the (hacky) fix suggested in bug 1690395 comment #13. We agree 100% with the statement from bug 1690395 comment #31.

[Bob-nelson-v (bob-nelson-v)]

(In reply to Rachel Martin from comment #195)
> (In reply to NolanK from comment #193)
>
> Just to set the record straight: The fork you mentioned did NOT fix this bug. If fixed bug 1690395 with the (hacky) fix suggested in bug 1690395 comment #13. We agree 100% with the statement from bug 1690395 comment #31.

Bug 135636 is similar to this bug where many unrelated tickets are dumped into a decades old open wontfix ticket. Have you fixed or are you planning on fixing PGP? Once these political bugs are addressed, I'm sure the OS distros will drop TB for BB.

[Mikeyy (mihovil)]

Not sure why all Thunderbird related bug reports are dumped into this Firefox bug.
Firefox and Thunderbird have wildly different use case. While "remembering with which app to open certain files" isn't much of an issue for Firefox, it's big issue in Thunderbird when handling lots of email with attachments.

Like some users before me, I suggest decoupling Thunderbird issue from Firefox and fixing it (hacky or not) on Thunderbird side, while leaving Mozilla to decide whatever think it's best for Firefox. If Mozilla fixes Firefox eventually, TB fix can be reverted.

As far as I can see, there is currently 3 TB bugs reported in last month for this exact issue, all marked as duplicate of this bug, which means users are reacting to it.

[Nolanktx (nolanktx)]

(In reply to Mihovil Stanic [:Mikeyy - L10n HR] from comment #197)
> Not sure why all Thunderbird related bug reports are dumped into this Firefox bug.
> Firefox and Thunderbird have wildly different use case. While "remembering with which app to open certain files" isn't much of an issue for Firefox, it's big issue in Thunderbird when handling lots of email with attachments.
>
> Like some users before me, I suggest decoupling Thunderbird issue from Firefox and fixing it (hacky or not) on Thunderbird side, while leaving Mozilla to decide whatever think it's best for Firefox. If Mozilla fixes Firefox eventually, TB fix can be reverted.
>
> As far as I can see, there is currently 3 TB bugs reported in last month for this exact issue, all marked as duplicate of this bug, which means users are reacting to it.

FWIW ... Until things are resolved between the Firefox/Thunderbird/Mozilla group there is a solution that works just fine.

Betterbird is a fork of Thunderbird and is working just fine. https://www.betterbird.eu/index.html

I'm just a regular guy who has use Thunderbird for years on the Beta channel and really like it, but little issues continue to add up and be a PIA for the users.

I was introduced to Betterbird and very impressed in that the Thunderbird 'bugs' are repaired in Betterbird.

I don't care if someone in the TBird group called the fix 'hacky' ... as it is fixed.

I'm not going to hold my breath for substantive changes within the Firefox/Thunderbird/Mozilla group to correct and repair.

[Andreas-fischlin (andreas-fischlin)]

(In reply to Mihovil Stanic [:Mikeyy - L10n HR] from comment #197)
> Not sure why all Thunderbird related bug reports are dumped into this Firefox bug.
> Firefox and Thunderbird have wildly different use case. While "remembering with which app to open certain files" isn't much of an issue for Firefox, it's big issue in Thunderbird when handling lots of email with attachments.
>
> Like some users before me, I suggest decoupling Thunderbird issue from Firefox and fixing it (hacky or not) on Thunderbird side, while leaving Mozilla to decide whatever think it's best for Firefox. If Mozilla fixes Firefox eventually, TB fix can be reverted.
>
> As far as I can see, there is currently 3 TB bugs reported in last month for this exact issue, all marked as duplicate of this bug, which means users are reacting to it.

As FF and TB were made similar in terms of the code that is of relevance here, I am not convinced that a separate handling of the two applications is doable. I say this also, as this decision to use common code may be entrenched into the code maintenance too much to be sensible. But this is to decide by the programmers of these applications, not me (I progam other things).

Moreover, the user experience is basically the same. There are needs to view attachments and there are true downloads in both applications and from the perspective of the user experience I argue that it makes a lot of sense to treat them in the same manner, i.e. not only common code is less to maintain, but also handling the same user experience in the same way is only beneficial to all when based on a good user model.

However, there seems to be no solid user model for how to handle files, i.e. attachments in case of TB and linked files in case of FF. The problem is that the programmers seem not to understand the issues that users of the applications are confronted with and AFAIK there was never a proper treatment of these issues done. E.g. first there is the common problem of the inability of separating the viewing of attachments (TB) or linked files (FF) from actual downloading when a user wishes to keep those files on her system. Admitted, this has little to do with this bug, yet it relates to the same irritating decisions of the programmers what the user experience ought to be when users access attachments (TB) or linked files (FF). The 2nd problem, this very bug we discuss here, is then also not handled properly since years, as user experience seems here not to matter much. I have to admit, for reasons that escape me as e.g. FF is otherwise a wonderful application in many respects. But the issues related to the user experience in terms of how attachments are handled may indeed matter more in the case of TB. I for instance no longer use TB for exactly these reasons. In this respect I agree with you.

[Worcester12345 (worcester12345)]

(In reply to andreas.fischlin from comment #199)
> (In reply to Mihovil Stanic [:Mikeyy - L10n HR] from comment #197)
> > Not sure why all Thunderbird related bug reports are dumped into this Firefox bug.
> > Firefox and Thunderbird have wildly different use case. While "remembering with which app to open certain files" isn't much of an issue for Firefox, it's big issue in Thunderbird when handling lots of email with attachments.
> >
> > Like some users before me, I suggest decoupling Thunderbird issue from Firefox and fixing it (hacky or not) on Thunderbird side, while leaving Mozilla to decide whatever think it's best for Firefox. If Mozilla fixes Firefox eventually, TB fix can be reverted.
> >
> > As far as I can see, there is currently 3 TB bugs reported in last month for this exact issue, all marked as duplicate of this bug, which means users are reacting to it.
>
> As FF and TB were made similar in terms of the code that is of relevance here, I am not convinced that a separate handling of the two applications is doable. I say this also, as this decision to use common code may be entrenched into the code maintenance too much to be sensible. But this is to decide by the programmers of these applications, not me (I progam other things).
>
> Moreover, the user experience is basically the same. There are needs to view attachments and there are true downloads in both applications and from the perspective of the user experience I argue that it makes a lot of sense to treat them in the same manner, i.e. not only common code is less to maintain, but also handling the same user experience in the same way is only beneficial to all when based on a good user model.
>
> However, there seems to be no solid user model for how to handle files, i.e. attachments in case of TB and linked files in case of FF. The problem is that the programmers seem not to understand the issues that users of the applications are confronted with and AFAIK there was never a proper treatment of these issues done. E.g. first there is the common problem of the inability of separating the viewing of attachments (TB) or linked files (FF) from actual downloading when a user wishes to keep those files on her system. Admitted, this has little to do with this bug, yet it relates to the same irritating decisions of the programmers what the user experience ought to be when users access attachments (TB) or linked files (FF). The 2nd problem, this very bug we discuss here, is then also not handled properly since years, as user experience seems here not to matter much. I have to admit, for reasons that escape me as e.g. FF is otherwise a wonderful application in many respects. But the issues related to the user experience in terms of how attachments are handled may indeed matter more in the case of TB. I for instance no longer use TB for exactly these reasons. In this respect I agree with you.

This would make a good statement for the use of the old "Seamonkey" (previously Netscape) model, with both integrated together. Maybe keeping that part of the project alive would have kept some commonality between Firefox and Thunderbird even now. Is "Seamonkey" still even a thing? If so, mayb...

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

We've hit 200 comments here and the vast majority of recent comments are arguing about exactly how dumb Firefox programmers like me are for not having fixed it yet, so I'm locking comments as there seems to be little point.

We are actively working on a fix, but as several comments here have already pointed out, it isn't trivial and will come with some side-effects to 20-odd year old ways that Firefox has done downloads. The root cause of this issue is outlined in comment #22: avoiding dataloss when applications don't provide the user with control over the resulting file, while the file is stored ephemerally (ie in the temp folder) and gets deleted later. We'll update this bug when we're confident about those changes making their way to release.

[Wls220spring (wls220spring)]

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

[Anjeyelf (anjeyelf)]

(In reply to :Gijs (he/him) from comment #201)
> We are actively working on a fix, but as several comments here have already pointed out, it isn't trivial and will come with some side-effects to 20-odd year old ways that Firefox has done downloads. The root cause of this issue is outlined in comment #22: avoiding dataloss when applications don't provide the user with control over the resulting file, while the file is stored ephemerally (ie in the temp folder) and gets deleted later. We'll update this bug when we're confident about those changes making their way to release.

You mention 'we are actively working on a fix' but to anyone following this bug and at this moment and there are going to be an increase in Thunderbird users, we notice this bug is marked as 'New' and it looks like no one has been assigned to fix it and there is nothing about when a fix is expected as a target.

This implies no developer is working on it at this moment and there is no action - whether that is true or not is not the point. That is what is perceived by the lack of documentation.
This bug is also where users get information on progress, but are seeing nothing and after 13 years you cannot blame users for wondering what is going on and why this bug still exists.

If someone is already working on this, it would be helpful to communicate this and let people know this bug did have someone assigned to work on it and what version the planned fix will be expected for release.

There have been comments suggesting no one should ask for a 'please fix' as it may stop developers working on it, but outsider users are being polite in trying to explain how important this bug is when it comes to work throughput for individuals and businesses alike.

I would be appalled if developers were actually choosing to deliberately not work on a bug just because there has been so many desperate users wondering why something as important as this bug appears to still be new and no one assigned etc.

This issue is a real problem in Thunderbird where opening of a variety of email attachments is extremely common.
Emails by their nature are a means of conveying and communicating documention in various formats.
This bug has also started to see more recent reports since TB version 91*.

This is a polite request for information and update.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to Anje from comment #203)
> there are going to be an increase in Thunderbird users

I can't comment on Thunderbird, and recommend you contact the Thunderbird devs through non-bugzilla channels (matrix or email is probably best). I believe that bug 1690395 was reopened and tracks the TB issue. I'm hopeful that the Firefox changes will help TB devs fix this, but TB is different enough that other/more work may be necessary. You should discuss that with the TB folks.

> If someone is already working on this, it would be helpful to communicate this

I did communicate this, in comment #201, which you quoted and therefore must have read. I don't know why you didn't take my word for it. If you don't trust my bugzilla comments, then no other change I could make to this bug would convince you that work is ongoing, and the issue is with the lack of trust, not with whatever work we are doing.

I did not assign someone to this bug or set a release date because the fix for this bug is part of a bigger project. Although we have hopes about which release that change will ship in, we can't promise anything right now - it depends how long it takes to stabilize the changes in question. Downloads are complex and have a lot of edgecases. We're currently testing out these fixes on the Firefox nightly channel. In barely a week, nightly users have already found 10 or so new issues with it which will need addressing.

As a result, I also did not (and still do not) want to write down a version or release here, because inevitably that information may get outdated or superseded, and then users will just be more upset.

(I have been reluctant to share the other bug links because quite frankly, 200 comments on those bugs is not something that is going to help anyone, either. I've added one now, **please** do not deluge that one with comments instead; it won't help.)

> outsider users are being polite in trying to explain how important this bug is

Being polite is necessary, but not sufficient reason for commenting on a bug. This is a bug tracker, in which developers track work, and it isn't a user complaints forum. Being asked several times a week "when is this going to be fixed", no matter how politely, only delays a release date for the actual fix. I restricted comments for exactly this reason. We're sorry this hasn't been fixed yet, we know this is important to users, and that is why we are working on it. No further comments stating how important it is or how terrible it is that this hasn't yet been fixed are necessary, nor indeed helpful, at this point.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

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

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

The fix for this as far as Firefox is concerned is riding the trains with Firefox 97. Thunderbird ended up with their own fixes that made it to TB 96 and 91.4.1. Any remaining issues with either Firefox or Thunderbird should be filed separately at this point - reopening this 14-year-old bug isn't going to be useful.

[Mathew Hodson (mhodson)]

Fixed in Firefox 97.

[Mathew Hodson (mhodson)]

This was fixed by bug 1710941 when browser.download.improvements_to_download_panel=true. That pref is enabled by default in Firefox 97 and later.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

The fix got postponed to 98 because of last-minute issues being discovered while it was on beta.