"Always do this from now on" does not work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Unknown
|
|||
One Hundred Papercuts |
Fix Released
|
Wishlist
|
Unassigned | ||
firefox (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
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+
ProcVersionSign
Uname: Linux 3.2.0-31-generic x86_64
NonfreeKernelMo
AddonCompatChec
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/
BuildID: 20120907231657
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xfe220000 irq 49'
Mixer name : 'Analog Devices AD1984'
Components : 'HDA:11d41984,
Controls : 32
Simple ctrls : 20
Card29.Amixer.info:
Card hw:29 'ThinkPadEC'
Mixer name : 'ThinkPad EC 7KHT24WW-1.08'
Components : ''
Controls : 1
Simple ctrls : 1
Card29.
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-
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=
RelatedPackageV
rhythmbox-mozilla 2.96-0ubuntu4.2
totem-mozilla 3.0.1-0ubuntu21.1
icedtea-6-plugin 1.2-2ubuntu1.2
RunningIncompat
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.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 6457BBG
dmi.product.
dmi.sys.vendor: LENOVO
In Mozilla Bugzilla #453455, Kevin Brosnan (kbrosnan) wrote : | #8 |
Bugzilla is not a place for discussion. Please use nntp://
In Mozilla Bugzilla #453455, Kevin Brosnan (kbrosnan) wrote : | #9 |
Automatically downloading attachment sent files is bug 285976.
In Mozilla Bugzilla #453455, Erik-staats (erik-staats) wrote : | #10 |
(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-
In Mozilla Bugzilla #453455, Jruderman (jruderman) wrote : | #11 |
Sounds reasonable to me. As far as I know, web sites use "content-
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-
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?
In Mozilla Bugzilla #453455, Bzbarsky (bzbarsky) wrote : | #12 |
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....
In Mozilla Bugzilla #453455, Domenic (domenic) wrote : | #13 |
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.
In Mozilla Bugzilla #453455, Shawn Wilsher (sdwilsh) wrote : | #14 |
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.
In Mozilla Bugzilla #453455, Mbeltzner (mbeltzner) wrote : | #15 |
From what I can tell reading through some of the backlog litany here, there are two issues concerning this bug:
Issue 1: "content-
Is there any other reason why servers would use "content-
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-
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-
In Mozilla Bugzilla #453455, Gavin Sharp (gavin-sharp) wrote : | #16 |
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.
In Mozilla Bugzilla #453455, Gavin Sharp (gavin-sharp) wrote : | #17 |
(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-
> attachment". Is that bug 285976?
No. That bug is about disabling the "always do this" check box for content-
In Mozilla Bugzilla #453455, Mbeltzner (mbeltzner) wrote : | #18 |
(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-
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-
- 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.
In Mozilla Bugzilla #453455, Kevin Brosnan (kbrosnan) wrote : | #19 |
(In reply to comment #8)
> Is there any other reason why servers would use "content-
> 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-
In Mozilla Bugzilla #453455, Shawn Wilsher (sdwilsh) wrote : | #20 |
(In reply to comment #12)
> Blogger uses content-
> http://
> 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.
In Mozilla Bugzilla #453455, Gcklema (gcklema) wrote : | #21 |
(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-
The bottom line is that this is about user choice & freedom. Please consider making this change.
In Mozilla Bugzilla #453455, Gavin Sharp (gavin-sharp) wrote : | #22 |
(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-
> 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").
In Mozilla Bugzilla #453455, Ivan Yosifov (iyosifov) wrote : | #23 |
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 ?
In Mozilla Bugzilla #453455, Bugzilla-tf (bugzilla-tf) wrote : | #24 |
*** Bug 463816 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Majuki (majuki) wrote : | #25 |
Summary of the elements of the issue:
1) RFC 2183 specifies content-
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
In Mozilla Bugzilla #453455, Vladimir Vukicevic (vvuk) wrote : | #26 |
*** Bug 469746 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Mbeltzner (mbeltzner) wrote : | #27 |
Carrying over vlad's blocking flag from bug 469746
In Mozilla Bugzilla #453455, Shawn Wilsher (sdwilsh) wrote : | #28 |
(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.
In Mozilla Bugzilla #453455, Bzbarsky (bzbarsky) wrote : | #29 |
(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".
In Mozilla Bugzilla #453455, Majuki (majuki) wrote : | #30 |
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.
In Mozilla Bugzilla #453455, Vladimir Vukicevic (vvuk) wrote : | #31 |
(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.
In Mozilla Bugzilla #453455, Gcklema (gcklema) wrote : | #32 |
(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/
"The recommended action for an implementation that receives an
'application
in a file, with any Content-
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...
In Mozilla Bugzilla #453455, Bzbarsky (bzbarsky) wrote : | #33 |
> 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.
In Mozilla Bugzilla #453455, Shawn Wilsher (sdwilsh) wrote : | #34 |
(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.
In Mozilla Bugzilla #453455, Gcklema (gcklema) wrote : | #35 |
(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?
In Mozilla Bugzilla #453455, Gavin Sharp (gavin-sharp) wrote : | #36 |
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.
In Mozilla Bugzilla #453455, Jruderman (jruderman) wrote : | #37 |
*** Bug 478893 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Adamthelibertarian (adamthelibertarian) wrote : | #38 |
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.
In Mozilla Bugzilla #453455, Gbrow6373 (gbrow6373) wrote : | #39 |
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 ?
In Mozilla Bugzilla #453455, Mike Connor (mconnor) wrote : | #40 |
Layman explanation:
* You don't need to click on anything to get something sent with content-
* 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).
In Mozilla Bugzilla #453455, Jruderman (jruderman) wrote : | #41 |
Mike Connor's explanation doesn't make sense in the context of this bug report. A web page could do all that stuff by just not sending the "content-
In Mozilla Bugzilla #453455, Majuki (majuki) wrote : | #42 |
Without kicking a dead can, the point is to prompt the user as to what they want to do with the file and prevent people from just "assuming" it's safe because the browser launched it right away. It also allows flexibility for developers as to how they want their files to be interpreted client side as well as keeping with the standard. If any discussion should take place on the issue it should be in context of updating the standard to be more specific.
The only thing I see that could be improved to make all sides happy is what was proposed above (see my comment #18 and related attachment). This is the only way I can see currently to adhere to the standard, prompt the user, but still allow for fewer overall clicks for the user. Allows for security, standards, and is user friendly.
In Mozilla Bugzilla #453455, Adamthelibertarian (adamthelibertarian) wrote : | #43 |
Setting aside for a second the issue of why it can't or won't be done, I haven't seen any explanation for why the option even exists for selecting "do this every time". Why can't the option be grayed out or not included?
In Mozilla Bugzilla #453455, Gbrow6373 (gbrow6373) wrote : | #44 |
I tried this in IE and note there is no 'remember my choice' box .
So at least as a dumb user I am not frustrated by thinking 'remember my choice' actually does something.
I agree with Comment #25 -
"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."
I think the point of users who want to see the JPG immediately are people are like me who want to see the image without junking up their hard drive. Seeing as how I am taking the responibilty by checking the 'remember my choice' box, I don't see why "Big Brother" wont just leave me to my fate.
I am resigned to not having it work as I want it to but could you please remove the 'remember my choice' box ? Its like waving a red flag at the bull.
In Mozilla Bugzilla #453455, Adamthelibertarian (adamthelibertarian) wrote : | #45 |
Doesn't the function in question detect the file extension _and_ give the user
the option of method to open said file?
#1) If I choose to always open file type "*.virus" with program "Destroy My
Entire Network", that's entirely MY BAD.
#2) if I decide to always open file type "*.jpg" with program "Picasa" how in
the heck could this do bad things to my computer again????
In Mozilla Bugzilla #453455, Gcklema (gcklema) wrote : | #46 |
(In reply to comment #29)
> 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.
I have not seen any argument against my analysis of the RFC standards in comment #25. This is stonewalling. Everyone who must deal with this asinine behavior will eventually switch browsers. I have.
In Mozilla Bugzilla #453455, Jruderman (jruderman) wrote : | #47 |
Firefox's current behavior forces sites to choose between security and usability. On the Web, content-
I'm reopening this because it was resolved as WONTFIX based on a misunderstanding of the security concerns and an overzealous reading of an irrelevant spec.
In Mozilla Bugzilla #453455, Chrisdab (chrisdab) wrote : | #48 |
Thank you for doing us this favor. Please also look into https:/
In Mozilla Bugzilla #453455, B5gpiyla (b5gpiyla) wrote : | #49 |
I'm a bit confused...
I'm trying to set up Firefox so that it will always open .nzb files with my newsgroup reader. No matter how many times I tell Firefox to "do this automatically", it always prompts me. The alternative to clicking this every single time seems to be to tell it to always "save as", and then double click the downloaded file. Either way, I have to click twice for each nzb (once to initiate the download, and then once to "activate" it). Is this the same issue that's being discussed in this bug report, and, if so, why are developers so hesitant to allow users to determine how they want their browser to handle file downloads?
In Mozilla Bugzilla #453455, Niche99 (niche99) wrote : | #50 |
A prime developer concern should be to GIVE users what they want. Firefox is NOT a security application. Even a security application like a HIP or firewall application give the option to 'remeber my action', so why can't firefox. It seems to me a developer has said I won't do it so it can't be done.
In Mozilla Bugzilla #453455, Bugs-h6ia (bugs-h6ia) wrote : | #51 |
I don't know if maybe this is beating a dead horse, but since this still hasn't been fixed after several years i guess i feel obligated to add my opinion:
1. I agree that the current reading of RFC 2138 is overzealous. Firstly, i think there is a very good case to be made for that spec being completely irrelevant to Web browsers (as opposed to actual mail clients). But secondly, and more importantly, i don't think that the behaviour proposed by the others here conflicts with even a strict reading of the recommendation. The purpose of the 'attachment' content-disposition is to prevent the client from opening the file in-line — allowing the user to always open it in an external application is PERFECTLY in synch with that recommendation. An external application is not in-line, even if the file is passed to it automatically, so there is no conflict at all.
2. I think the concerns of the opponents of changing the current behaviour regarding the desires of server hosts are completely valid, but i also think that the desires of the users (and anecdotally i would say it's a LOT of users) trump those concerns. The devs didn't put the wishes of server hosts ahead of those of the users when they implemented pop-up-blocking or the ability to install arbitrary extensions or anything else; what makes this specific scenario so sacred?
3. I think the concerns regarding security and RFC compliance are also valid, which is why the proposed behaviour should be very much an 'advanced' kind of thing — for example, something that would have to be enabled in about:config. Maybe even in a key that has to be explicitly added by the user first, just to add even one more layer of protection. Leaving RFC 2138's recommendation as the default behaviour — but allowing the user to change it with some effort — should please everyone, i'd think.
4. I might go even further than some of the other proponents of changing the behaviour here — i think that, in addition to being able to automatically open in an external application, there should also be the ability to automatically open it in-line, if it's set that way specifically.
For example, someone earlier mentioned how Blogspot (and they're not the only ones) use content-disposition to force normal images like JPEGs to always save to disk. This usage is not security- or usability-related or anything else, it's purely a tactical decision on the part of the host to prevent hot-linking. Some might even call it abuse. This shouldn't become my problem, any more than pop-up ads should — i just want to view the image in my browser like every other image! I should not have to open an external application, or an extra Firefox window even, to do that, if i really don't want to.
5. In summary, i think the following changes should be made to the current behaviour:
(a) The current behaviour should remain as the default, but the UI should be changed to notify users that the action can not be taken automatically when appropriate (this is a separate bug).
(b) An option should be added to enable the ability to automatically perform the selected action for 'attachment' downloads. This option should be sufficiently obscure to protect un-...
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #52 |
*** Bug 501555 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Glenn Powers (glennpowers) wrote : | #53 |
*** Bug 503708 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Bzbarsky (bzbarsky) wrote : | #54 |
> On the Web, content-
> not be considered same-origin with the site.
Unfortunately, that's not all it's used for. Some sites use it this way (for HTML and such). Other sites use it to mean "don't view inline" or "let user save" (for images and the like).
In Mozilla Bugzilla #453455, 3-14 (3-14) wrote : | #55 |
*** Bug 347843 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, 3-14 (3-14) wrote : | #56 |
Now SeaMonkey is only affected (so far only in 2.0b). So we can expect many
more duplicates (as we had for bug 236541 which is fixed, actually not fixing
what all those dupes were reported for). In the end it is just a horrible user
experience. People choose to do some action and without any warning or hint it
does not happen.
I came to search this because of my bank account. There I encounter the issue.
Certainly there are few sites I would trust more with respect to security!
My logic goes as follows: The user want to handle certain files types by
opening with a named application. He trusts that he has done everything
reasonable (like setting up relevant virus protection etc.). He can launch the
file (after pressing the button or after saving). He wants it and will do it.
The dialog doesn't stop him and hence does not increase security.
Yes, this is not a new argument, but this is what the users experience. They
don't see MIME headers (the dialog box does not display that, but suggests it
will remember a decision made by the user).
pi
In Mozilla Bugzilla #453455, Canon138545 (canon138545) wrote : | #57 |
It seems kind of arbitrary that the "do this automatically" checkbox is grayed out for "content-
<RDF:li RDF:resource=
as an entry between <RDF:Seq RDF:about=
<RDF:Description RDF:about=
<NC:handlerProp RDF:resource=
</RDF:Description>
<RDF:Description RDF:about=
</RDF:Description>
After making those edits, you can choose to always save the "application/
If you are being served a different MIME type (e.g., application/
Live HTTP Headers is useful for finding out the MIME type of the file you are being served:
https:/
More info on editing mimeTypes.rdf:
http://
In Mozilla Bugzilla #453455, Domenic (domenic) wrote : | #58 |
But that doesn't work for those of us who want to _open_ every time, I assume?
Since I'm here, I might as well mention an idea I'd had for a workaround: namely, creating an extension that just looks for the content-
It's on my "to do in my very rare spare time" list, but maybe someone else subscribed to this bug knows enough about the extension APIs to make this a one-hour project? (My problem is that I'd have to learn how to write an extension, which seems like it might take a day or two... even if it would be a good skill to have.)
In Mozilla Bugzilla #453455, Canon138545 (canon138545) wrote : | #59 |
> But that doesn't work for those of us who want to _open_ every time, I assume?
No, I don't think it does, but I'm not 100% sure - I haven't thoroughly tested that side of it.
When browsing with Firefox I have found that pages seem to have the ability to launch files without user interaction. Upon opening a malicious page you can get the "You are opening..." dialog asking what to do with, for example, an .exe or .pdf file, without ever having clicked on a link to an .exe or .pdf file. I used to have Firefox set up to automatically open PDF files using the Adobe plug-in, but I changed it to "Always ask" after I had to quickly kill a "~.exe" process that was launched by a vulnerability-
The point I'm getting to is that for "Always _open_ every time" there probably needs to be a quick OK/Cancel confirmation of some kind when files are launched without user interaction.
In Mozilla Bugzilla #453455, Mole (mole) wrote : | #60 |
Hello,
I also have been struggling with this issue, but I have managed to solve it for my own purposes.
I'm using Privoxy [a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk]. It's open source software, which im currently using as universal ad blocker.
It can modify http headers, and because my main annoyances are .nzb files i just added the following to configuration file:
{ \
+hide-content-
}
/.*\.(nzb)
And now Firefox opens these files with the program i've configured. This is of course not the solution for everybody, since it requires installing another software for the background.
I definately would like to see some sort of solution from Mozilla.
Mikko
In Mozilla Bugzilla #453455, Bugzilla-tf (bugzilla-tf) wrote : | #61 |
*** Bug 525910 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, David-balazic (david-balazic) wrote : | #62 |
(I post here instead of risking a new duplicate)
I click a link on a web page, and the dialog appears:
- telling the file is a PDF document
- with the selected (radio) option to open it with Foxit Reader
- unselected radio option "Save File"
- checkbox "Do this atumatically..." It is checked, as I checked it 1 minute before.
The checkbox is obviously not honored.
It should either be honored or not offered at all.
(FF 3.5.5 on WinXP)
In Mozilla Bugzilla #453455, Samspam (samspam) wrote : | #63 |
From reading the comments of this and related bugs, it seems to me that the only real security concern here is drive-by attacks where the user has not clicked the link. If this is what is causing developers to resist remembering the user's choice of app and automatically opening without additional interaction then I see the point. This would not be safe, and although my initial thoughts were all centred around "remember my choice when i damn well tell you to", I don't think I should be able to do this as it stands, even in about:config. PDFs provide a good example of a format that often has serious security holes, and the risk of being hit with automatically opened PDFs without clicking deters me from wanting this change. Do I understand the position correctly?
HOWEVER, I am also incredibly irritated by this lack of functionality on an hourly basis and have been for years. There has, despite legitimate concerns, been some stonewalling and stubbornness. I think this bug should focus on technical solutions to what is a clear usability issue. The usability issues exists, regardless of other concerns. Let's fix it. How can we allow users to remember their choice of app for links that they DO click on? There are elements of things like pop-up blocking that seem to have knowledge of whether or not a user made a click. Is this information available in the download code path? Could it reliably be made available? How reliable? The massive majority of cases involve clicking a link, and requiring unnecessary extra clicks when it should be seamless. This needs addressing. I have only *ever* once been targeted by a download I didn't click on. Enabling these attacks is not a good thing, but working around them is essential.
At the very least, for immediate clarity if a real solution requires significant work: the dialogue should be re-worded or better the functionality changed. I believe there is another bug for this already? The remember check-box should be unchecked and disabled if the radio button for open is selected. Even better, check-box and text should be replaced to signify why the choice cannot be remembered. None of these things would constitute this bug being fixed.
I find it hard to see how ex
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #64 |
*** Bug 538222 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, James Wilson (james-jameswilson) wrote : | #65 |
A suggested solution:
Similar to one of the popup-blocker's code, we could detect if this is an intentional action to download, by looking for explicit click/enter button actions.
If the user did click on it, then we know it is intentional, and if they have requested to bypass the dialog, then bypass the dialog.
In Mozilla Bugzilla #453455, Bugzilla-tf (bugzilla-tf) wrote : | #66 |
*** Bug 550503 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, starko (starko-chello) wrote : | #67 |
i have been struggling with this issue for many years. I have had it with mp3, torrents, nzb files and many of others.
To the developers: If you don't feel like fixing this obvious usability flaw and rather do something else, just say so. Don't hide behind any outdated half relevant specifications. Because now there is absolutely no excuse for not thinking in terms of AND/AND. There is more than one way to protect the innocent from drive-by execution of malicious content AND allow automatic execution of daily or rather hourly of not more often task. Take pride in what you are doing and rather think in terms of solutions. It's quite possible you were not in creative mood when you were presented with this problem the first time and felt like you had to keep defending your decision all this years. Wake up and be a hero :) We will thank you for this!
In Mozilla Bugzilla #453455, Ws-bugzilla (ws-bugzilla) wrote : | #68 |
If the reporter marks this as "blocks bug 565512" I feel it might have a marginally better chance of being taken care of.
I am definitely not in control when I tell the browser to "do X" and it blatantly refuses to, with no explanation whatsoever.
In Mozilla Bugzilla #453455, Stefan Hepp (mastastefant) wrote : | #69 |
Ok, here is what I would expect Firefox to do, from a user perspective:
1) If the server sends me something explicitly marked as download using the attachment header (or as possible drive-by-
Else it is quite easy to 'just click OK' in the dialog, and your downloaded file is a) somewhere lost in a temp-directory and b) gets executed anyway.
The argument that every 'Open-With' App has a 'Save As' option anyway is not valid, since media-players usually do not provide such an option (at least the ones I use, like VideoLAN player).
(However it would be helpful to have a 'Save As' option in the Download-manager for downloads to a temporary location, although since temp-files should be deleted after they are used, having a 'Save As' option in the download-manager should therefore count as usage and prevent deletion of the temp-file until the entry is removed from the downloaded-
2) If I have an 'Open With' option, which I guess selects the application based on the file-extension (since it is available even if 'Always perform this..' is greyed out), the default action (Open with/Save as/..) should be set in the same way the 'Open With' action works, i.e. based on the file extension if the mime-type is not available/
From a user perspective, I am really not that interested in mime-types and server-
3) I do not quite see how much good disabling the option does security-wise anyway, since it should be quite possible to just send a malicious PDF using a correct mime-type, which would then be opened automatically again.
4) Another helpful UI improvement (for me..) would be if 'Open','Save', .. would be buttons instead of a selectbox-list with an OK button (e.g. similar to Opera). For people (like me) who do not like the default selection (whatever it is), this saves one click and is much more 'robust' (if the buttons are always at the same position) because you do not need to hit a small radio-box (and to remember to do so!) but just a big button which always does the same thing.
However, I noticed that in the Options-dialog, some Content-Types are already based on extensions instead/in addition to 'application/
In Mozilla Bugzilla #453455, Kevin Brosnan (kbrosnan) wrote : | #70 |
*** Bug 581134 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Johanges (johanges) wrote : | #71 |
I'm not writing this as an opinion piece -- that would not belong here -- so let me state my problem as exactly as I can.
Currently checking the box is a no-op under some well defined, common, and reproducible circumstances.
Many users are surprised and annoyed by this behavior. IMNSHO the initial description of bug 331259 captured this quite well, but in search of an implementation, the bug drifted way off base. The bug this comment is attached to is apparently where the action has moved to, so this is why I'm writing it here.
----
Indicating an affordance with the UI, and then ignoring the action the user is lead to take -- without a reasonable explanation -- is a grave error in user design.
But, in trying to fix this with bug 331259, the focus shifted to a more technical interpretation and into RFC land. (I'm not trying to be disrespectful here. I have myself committed extensive specification nitpickery in various contexts for almost as good reasons as stated in bug 331259. Anybody who groks RFC 2183 has nothing by my respect and thanks.)
Unfortunately, the difference between the nitpicking of the RFC divinations and the more fundamental problem of user confusion is hard to see when you are a mere mortal.
Us mortals just experience a consistent FAIL when we try something again, and again, and again. And when the browser just keeps encouraging us to try it one more time, while still ignoring our actions, we get frustrated.
I'm not saying that the RFC interpretations are not correct, nor do I say that the RFC isn't saying this for some very very good reasons (such as "failure to follow RFC xxx causes p0wnage"), nor do I say that the people who are fighting to have the RFC's obscure dicta strictly followed are not doing the right thing, nor do I say the the fix must be that we bypass/
What I am saying is that if it doesn't fix the problem as it is seen by the user, then it isn't the fix for what the user is complaining about.
The original bug reported that a user's action was ignored and the user was left confused. The user is still left confused after bug 331259 has been "fixed", verified, and closed.
_That_ is the problem.
My hope is that this time somebody will look at the deeper problem of eliminating the user confusion before closing the bug.
I'll be happy even if it involves something as crude as a dialog explaining the problems and risks and explicitly asking "is _really_ what you want?" (and I _do_ hope there is a better way), or as sophisticated as reformulating the question such that the issue doesn't arise in the first place.
Just don't claim the bug ("confused user when xxx") is fixed when seen from a particular narrow technical viewpoint, _however correct that viewpoint is_.
BTW, the most dangerous outcome here is not that some obscure RFC clause gets ignored or misinterpreted, but that it so much easier (and way way faster) to write an add-on that completely ignores the whole shebang and opens a big security hole as it just makes a complete bypass of it all.
I don't think anybody here wants such an add-on -- or even worse -- have it become popular.
In Mozilla Bugzilla #453455, Yitzter (yitzter) wrote : | #72 |
Is this bug still open? I'm using 3.6.11 and it's extremely frustrating. I've started to use Chrome since it's much easier with opening files automatically.
Does anyone know of any Add-on that might assist with this issue. Thanks.
If this problem isn't fixed by the release of Firefox 4. I'm definitely moving on to Chrome.
In Mozilla Bugzilla #453455, Timson-robl (timson-robl) wrote : | #73 |
There is add-on solving this problem for .torrent files made by Russian developers but it also creates new problem - inability to work with downloaded .torrent files in any other way.
http://
In Mozilla Bugzilla #453455, Yitzter (yitzter) wrote : | #74 |
Thanks. However, this doesn't deal with the underlying issue. I think I'm just going to move to chrome. Much more development going on, unlike Firefox which has a major bug for several years already, and hasn't been fixed.
Thanks for the advice though.
In Mozilla Bugzilla #453455, Xraysmalevich (xraysmalevich) wrote : | #75 |
FlashGot seems to work with most files -- http://
In Mozilla Bugzilla #453455, Dr4-bugzilla-tff (dr4-bugzilla-tff) wrote : | #76 |
Back in the real world of people using their computers to download files, I get asked ALL the time why they have to click so many times to do something that appears to be so simple, and yet it's not.
These are the people who've embraced Firefox after deserting IE (on my advice) and now they get hit with this inane constant prompting.
Please either implement some kind of config setting (modified in about:config) if at all possible. I simply don't have the time to discuss the merits of various RFCs. I want my PC to be useful and assist me, not hassle me all the time. If I was to inform any of the people I deal with about dear Boris and his RFC ramblings, then I would be met with a blank look/confusion.
Multiply my frustration by a factor of all the other pro-posters here and I think you'll perhaps understand.
In Mozilla Bugzilla #453455, Ic3b3rg (ic3b3rg) wrote : | #77 |
(In reply to comment #69)
Seconded
In Mozilla Bugzilla #453455, starko (starko-chello) wrote : | #78 |
By the looks of it, Boris has left the building long time ago and is not following the discussion, just like any other mozilla developers (if there were any inthe first place). The only emails are on the CC list are probably of those who would like this issue to be solved. It also seems that there is no opposition to the changes proposed - the problem is that there is nobody ABLE AND WILLING to implement these changes. And as long as this issue is lost within this huge mozilla bugzilla swamp nothing will happen. Nobody and i mean ALMOST NOBODY knows about this little dungeon of despair. Mozilla bugzilla is very helpful to developers and sometimes users in many aspects but it is far from perfect and in this case IT DOES NOT WORK.
A call to arms :)
I suggest setting up a webpage/blog outside of confines of this environment and use it raise the awareness of this issue. And i mean a real viral action. Something that can be actually be heard by those who CAN and motivate them to DO. I believe that we can encourage someone to do something about it especially if there is a publicly visible reward in the end to the hero programmer that had actually done it. and i am not talking about money - although that could be part of the campaign. but gratitude of all the thousands that we can make to sigh up a petition of a kind or something like that could mean a lot too.
I have difficulty expressing all the possible ways to market this project but i believe it can be a lot of FUN!!!
I am talking about posting pictures of how this can be done, making Camtasia video's of current situations and how it should work and posting them on youtube. I am talking about creating a facebook page and placing those vids there and on the blog page. Getting people to "Like it" that facebook page and have this discussion in the open. We could have some fun playing with SEO and try and get this issue high in google and youtube ranking so that anyone typing "firefox problem" in google will see this issue and words like "stupidest firefox usability flaw" associated with it. We can make a lot of constructive fun of Mozzila in any way imaginable :)
I am very busy with starting my own business and all the research i have done on marketing my upcoming business served as inspiration to write all of the stuff above. I would love to organize this thing but i will have my hands and head full coming months... Yet i will definitely actively participate and collaborate with anyone willing to do it together.
I have created a blog http://
If any of you would like to have some fun instead of waiting for some lost developer to blunder unto this unglorifying bug let me know
In Mozilla Bugzilla #453455, Mbeltzner (mbeltzner) wrote : | #79 |
I don't think it will be lost. I continue to advocate for this issue. Set up your viral site and have fun, if you must, but feels like a waste of time and a presumption of intent based on facts not in evidence.
We should do this. Simple as that. We shouldn't base our browser's behaviour on an RFC intended for a mail client.
In Mozilla Bugzilla #453455, starko (starko-chello) wrote : | #80 |
(In reply to comment #72)
> I don't think it will be lost.
Hi Mike, i am not sure what you mean by this.
> I continue to advocate for this issue.
I do continue to advocate for this issue as well. Unfortunately just advocating does not seem like getting us anywhere. This bug report was created 2 years ago and there is no one who came forward and said "I'll do it!"
> Set up your viral site and have fun, if you must,
I just have: http://
> but feels like a waste of time
it's quite possible that it will be a waste of time. On the other hand it might not... and it sure beats all the animo that comes from mozilla team. I give no guarantees that i will pull this through... BUT I'll try and hopefully get some some collaborators
>and a presumption of intent based on facts not in evidence.
You lost me here - which intent did i mistakenly presume?
> We should do this. Simple as that. We shouldn't base our browser's
> behaviour on an RFC intended for a mail client.
From your mouth to mozilla gods ear :) Could not agree with you more!!! But who are those "We" you are talking about?
In Mozilla Bugzilla #453455, Robster400 (robster400) wrote : | #81 |
This drives me up the wall :(
Love Firefox, hate clicking.
In Mozilla Bugzilla #453455, Emanuel-hoogeveen (emanuel-hoogeveen) wrote : | #82 |
(In reply to comment #73)
> > We should do this. Simple as that. We shouldn't base our browser's
> > behaviour on an RFC intended for a mail client.
> From your mouth to mozilla gods ear :) Could not agree with you more!!! But who
> are those "We" you are talking about?
"Mike Beltzner is the Mise en Scène for Firefox: a product manager and director of sorts, setting direction and guidance for the delivery of Firefox to its millions of users worldwide." from https:/
I'd say he's talking to/about all the Firefox devs :)
In Mozilla Bugzilla #453455, Scott Gutman (scott-signaturecomputer) wrote : | #83 |
This drives me crazy too. so much clicking, so little reward. Please fix, patch or give us the option to hard code actions to filename extensions.
In Mozilla Bugzilla #453455, Kevin Brosnan (kbrosnan) wrote : | #84 |
*** Bug 622424 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, starko (starko-chello) wrote : | #85 |
There is a blog page that was meant to boost some awareness of this ridiculous bug and hopefully find someone willing and able to fix it. Not much has come of it yet, but a clever guy from Russia made a Firefox add-on that provides this much needed functionality:
http://
I still hope that someone within Mozilla wake up and do what should be done long ago.
In Mozilla Bugzilla #453455, Robster400 (robster400) wrote : | #86 |
(In reply to comment #78)
> There is a blog page that was meant to boost some awareness of this ridiculous
> bug and hopefully find someone willing and able to fix it. Not much has come of
> it yet, but a clever guy from Russia made a Firefox add-on that provides this
> much needed functionality:
> http://
> I still hope that someone within Mozilla wake up and do what should be done
> long ago.
A nice find, thanks.
A proper fix is long overdue though!
In Mozilla Bugzilla #453455, Shammond127 (shammond127) wrote : | #87 |
Very cool, I'll have to try it out.
Everyday, I click the sad smiley in FF4 Beta and leave a comment regarding the fact that even in the beta for the next version this STILL isn't fixed. I encourage everyone here to do the same. =)
In Mozilla Bugzilla #453455, David-balazic (david-balazic) wrote : | #88 |
Also consider voting for this bug (at the top of this web page).
(In reply to comment #78)
> it yet, but a clever guy from Russia made a Firefox add-on that provides this
> much needed functionality:
With a workaround in an add-on, the probability of a fix is even lower now. :-(
In Mozilla Bugzilla #453455, David-balazic (david-balazic) wrote : | #89 |
About the drive-by attack argument:
To circumvent this "protection", the attacker must just not use the "content-
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #90 |
Give up. This bug has been in every version of Firefox since the beginning. It's still in the latest 4x builds too. No one cares. No one is even making an attempt to fix it. It was reported years ago, and still no one cares. It isn't going to be changed.
In Mozilla Bugzilla #453455, Yitzter (yitzter) wrote : | #91 |
Firefox is dead. Just use Chrome. It's better in every single aspect. Much more development and dedication to user experience.
I must say that I started using Chrome due to this specific reason. I needed it for work, and every time it would ask me which program to use instead of doing it automatically. This single reason alone, drove me to use Chrome. I haven't looked back since.
Hope this helps anyone looking for a fix.
In Mozilla Bugzilla #453455, starko (starko-chello) wrote : | #93 |
(In reply to comment #82)
> To circumvent this "protection", the attacker must just not use the
> "content-
I think we've been through this: Firefox can and should differentiate between downloads triggered by user clicking on a link and "automated" downloads.
(In reply to comment #83)
> Give up. This bug has been in every version of Firefox since the beginning.
> It's still in the latest 4x builds too. No one cares. No one is even making an
> attempt to fix it. It was reported years ago, and still no one cares. It isn't
> going to be changed.
Because until short ago it was reported in bugzilla.mozilla only and out of millions of people who knownly or unknowingly suffer from this nonsense only a few dozens found their way into this dungeon. This is a place to help developers to funnel bugs, that's it! There is little you can do here if there is indifference or outright unwillingness to fix something.
This mailing list is a medium from a year 2000. Things like blogs and social media have arisen since than. I believe this entire thread would have more impact if it took place on the blog page i've mentioned (or a dedicated Fzcebook Community page). If all 64 current thread followers (min a couple of Mizzila devs) were to click on "Like it", at least a couple of thousands of friends would see it, with a few chain reactions. Every time one of you posted a message, again another couple of thousands. Even reactions like "Just use Chrome" would be seen by a couple of thousands every time, instead of 60 FF addicts. That might make FF people take this more seriously. A Facebook App could be made "Tired of this weird Firefox behavior? Click here to send a complaint to Firefox team!".
Of course another idea is to tell Google team to advertise their browser on Torrent sites and tell everyone why in this particular case Chrome is better.
In Mozilla Bugzilla #453455, starko (starko-chello) wrote : | #94 |
(In reply to comment #72)
> We should do this. Simple as that. We shouldn't base our browser's behaviour on
> an RFC intended for a mail client.
Mike, obviously you are on our side on this issue. And as you said, you would advocate fixing this within FF dev team. Have you tried? What were the results? Could you, as "the Mise en Scène for Firefox: a product manager and director of sorts, setting direction and guidance for the delivery of Firefox to its millions of users worldwide", give us some more insider information on why nothing has been done? Is it shortage of developers? is it because this usability flaw has low priority? is it lack of agreement that this "bug" is a bag at all? Any other reasons?
Talk to us, man!
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #95 |
You had me up until all that stuff about citizen advocacy. I agree the devs themselves (or no one) will fix this though. After nearly 3 years of complete inaction I wouldn't hold out much hope however.
Even if they didn't change it to allow user selected actions to be remembered the dialogue should at least be changed to something that makes more sense. Offering to remember an action and to repeat that action for specific filetypes 'from now on' and then not doing it, just doesn't make any sense. I know there is an argument about the security issues this presents (although this has been proved baseless above), however if other browser can handle this action without difficulty then why not FF?
I suppose this is what happens when you have 'design by committee'. Stupid bugs (and bureaucracy) emerge and become so intractable (due to so many conflicting perspectives) that it becomes almost impossible to fix them. This is why Soviet era cars were always so poorly designed too.
PS
I'm unsubscribing from this debate. I think waiting over 2 years for a fix is probably long enough.
In Mozilla Bugzilla #453455, pizza (terremotoetragedia) wrote : | #96 |
(In reply to comment #88)
> After nearly 3 years of complete inaction
My understanding is that this has been a known issue for much much longer than that, but other older bugs have been closed as a duplicate of this. See e.g. bug 331259, shamefully closed as "VERIFIED FIXED".
In Mozilla Bugzilla #453455, Johnath (johnath) wrote : | #97 |
Way back up in comment 1, kevin pointed out that bugzilla is not a discussion forum and he was right. This bug doesn't need advocacy, or calendar counting, or threats to move to other browsers, or righteously indignant demands, or consensus building, or massive grassroots whatever the hell.
It needs a patch.
That it hasn't gotten one from someone on my team yet is purely a function of them having too much other work to do. Anyone in the 89 comments above this one is, of course, welcome and invited to attach one - we'd love to fix this bug. Anyone up for it?
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #98 |
That is pretty dismissive of users opinions dude. How else are ordinary users supposed to bring glaring bugs like this to developers attention?
I agree threats to move to other browsers, or starting grass roots campaigns, or whatever else method of drum banging is used a a bit childish and pointless. But what you are dealing with here is ordinary users, so taking a typically elitist developers stand and telling ordinary users to go fix it themselves probably isn't all that helpful.
I'm sure if everyone in the world could write code, then someone would have fixed this by now - but that's why people in the world are divided into different specialities and different professions.
The only hope ordinary users have is to try to keep issues like this alive and keep brining them to developer's attention until someone decides to fix them. Otherwise what's to say someone won't just come along and randomly (as has happened in the past) mark the issue as 'fixed.'
Anyway I really am unsubscribing, just as soon as I can work out how to unsubscribe from a specific thread. Not because of some childish tantrum, but because I have simply lost interest (and hope) of the issue ever being fixed. I stayed quiet and watched this thread for well in excess of two years. I am I regret simply tired of reading about it now.
In Mozilla Bugzilla #453455, David-rossde (david-rossde) wrote : | #99 |
*** Bug 331259 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, David-rossde (david-rossde) wrote : | #100 |
Because this bug report is still open and bug #331259 was marked as Closed/Fixed, I marked bug #331259 as a duplicate of this one.
I must note that the overall problem was reported in bug #331259 on 21 March 2006, 2-1/2 years before this bug report was submitted. Everyone should realize that this problem has been known for almost five years.
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #101 |
(In reply to comment #93)
> Everyone should realize that this problem has been known for almost five years.
You were already told off for altering the other bug wrongly, but I'll point out that this was known about in bug 285976, six years ago. That's the bug that would disable the "Do this automatically" checkbox so you can't tick it in the Content-
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #102 |
(In reply to comment #94)
> I'll point out that this was known about in bug 285976, six years ago.
Correcting myself, the original report was bug 236541, seven years ago, dealing only with remembering the "download" action, this bug is for the "open with" action.
In Mozilla Bugzilla #453455, P-kern1 (p-kern1) wrote : | #103 |
I've made an extension that fix this bug:
https:/
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #104 |
It doesn't work in FF4. Besides although possibly useful, extensions don't fix bugs that should probably be fixed anyway.
In Mozilla Bugzilla #453455, Robster400 (robster400) wrote : | #105 |
(In reply to comment #97)
> It doesn't work in FF4. Besides although possibly useful, extensions don't fix
> bugs that should probably be fixed anyway.
Works great in Firefox 4,The above is incorrect.
Thanks for that!
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #106 |
Not in Beta 12.
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #107 |
Besides it really is worth remembering that this is a work around and not a fix. It may even have the effect of removing any motivation there may have been (although there doesn't appear to be much) of fixing this bug to begin with.
In Mozilla Bugzilla #453455, Robster400 (robster400) wrote : | #108 |
(In reply to comment #99)
> Not in Beta 12.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre
;)
In Mozilla Bugzilla #453455, Sgerber (sgerber) wrote : | #109 |
Sorry to add to the noise, but ...
I have read all the comments, RFC 2183, RFC 2616 (esp. 15.5 Content-Disposition Issues), etc.
RFC 2183 is for email (not HTTP).
RFC 2616 is HTTP and explicitly states that "Content-
I understand some of the security issue(s) and the philosophy that attachments require user action(s).
If the underlying behavior is WONTFIX then, in this case, the "do this automatically" checkbox should not be available and should be replaced by text indicating the issue. I will try to put this comment with the correct bugs.
For me personally, this is a king size pain esp. with streaming media whether or not I want to use a plug-in or an external program. If I right-click and "Open Link in Ext. App." then I can get my streaming audio. Again for me personally, I do not even get the dialog because I get the ZoneAlarm download dialog and must download the (entire) file, then run it.
Thanks for listening.
In Mozilla Bugzilla #453455, Worcester12345 (worcester12345) wrote : | #110 |
For the life of me, I cannot find where to change an attachment from OpenOffice to MS Word. It just automatically wants to use O.O.
In Mozilla Bugzilla #453455, Klonos (klonos) wrote : | #111 |
Voting...
In Mozilla Bugzilla #453455, raid517 (raid517-ukonline) wrote : | #112 |
(In reply to comment #103)
> For the life of me, I cannot find where to change an attachment from OpenOffice
> to MS Word. It just automatically wants to use O.O.
life of me, I cannot find where to change an attachment from OpenOffice
> to MS Word. It just automatically wants to use O.O.
This isn't anything to do with this bug. This isn't even a bug. This is down to your own lack of knowledge. The best place to resolve this is either via Google (probably quicker) or the Firefox MozillaZine forums. http://
In Mozilla Bugzilla #453455, Bugzilla-tf (bugzilla-tf) wrote : | #113 |
*** Bug 404166 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #114 |
*** Bug 660510 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Mbeltzner (mbeltzner) wrote : | #115 |
Regrouping:
The issue represented by this problem report is that when we see a file served with content-
Bug 470332 was meant to ameliorate the situation by remembering the list of helper-apps in the drop-down; I can report that although it's marked as FIXED, it doesn't always work. Presumably that's because sometimes we just can't actually remember it (as no MIME type given, I suppose?). In those cases bug 285976 was meant to not show the "always do this" UI, which would be only slightly less frustrating (in that we wouldn't be promising to do something we couldn't) but doesn't really fix the issue.
Further, in comment 4 and comment 40, Jesse argues that this header is often used as a way of providing additional security by not inheriting the origin of the referring website; our poor user experience from that choice is problematic.
I believe that Firefox should simply ignore content-
Perhaps in the fullness of time it will be easy to also add an infobar or prompt that asks users if they also wanted to just save the file, but for now, I think people will be able to find their way to right-click and "Save As..."
(NOTE: Please do *not* add advocacy comments to this already busy bug. If you agree, that's great, be quiet. If you disagree, and have an alternative proposal or factual clarifications, feel free to add a comment)
In Mozilla Bugzilla #453455, Majuki (majuki) wrote : | #116 |
[quote]by the very strictest letter of the RFCs, we're doing the right thing[/quote]
As per comment 22, the RFC in question is only meant to apply to mail programs. Firefox is adhering to an RFC that it shouldn't.
In Mozilla Bugzilla #453455, Stefan Hepp (mastastefant) wrote : | #117 |
So if I understand this correctly, the content-disposition header is only relevant if the user would normally want open the file automatically?
In that case, if the user has selected 'Save As' as default action, there is no need to show the dialog, only if the user has selected 'Open with'. The 'always do this' checkbox could be disabled only for the 'Open with' selection, if the dialog is shown for a download with a content-disposition header.
One problem is that the behaviour is not transparent to the user, because he does not know that the server sent that header / requested to save the file, hence it looks like a bug. So displaying something like a yellow infobar-like box (to draw the attention of of the user without looking like a warning/error) with a text like 'The server encourages you to save the file' instead of the disabled 'always do this' checkbox could go a long way regarding user experience, ideally including a check/select/
I would be willing to write a patch for this (provided I find the time), but I would like to make sure that it has some chance of being accepted first ..
In Mozilla Bugzilla #453455, Majuki (majuki) wrote : | #118 |
(In reply to comment #109)
Apologies, comment 109 should have stated comment 72 as it's reference not 22.
I very much like the idea behind comment 110 but would expand upon it slightly. Use a bar akin to remember password. Allow the user to save a default action and should action be anything other than "Save as..." a bar come across indicating possible actions.
If the action is anything other than save as a simple bit of text akin to comment 110:
"The server [insert domain] recommends saving this file, your default action is [insert default action].
Along with buttons: "Save as...", "Change action", "Dismiss"
Dismiss = close message continue action
Save as = open save as dialog box
Change action = open dialog for selecting a one time action with an option to make it the default action, take the new action
In doing so it should not attempt to stop or delay the execution of the default action. Akin to if you click a link the browser continues to load until given new instructions. This then has the added benefit of being able to open and save a document simultaneously.
In Mozilla Bugzilla #453455, Gingerbread-man-b (gingerbread-man-b) wrote : | #119 |
For users still annoyed by this bug, I would like to point out a workaround is available in the form of the InlineDisposition extension. It works like a charm, and much better than the old Do This Automatically extension.
In Mozilla Bugzilla #453455, David-rossde (david-rossde) wrote : | #120 |
Per addons.mozilla.org, the InlineDisposition extension is not compatible with SeaMonkey 2.2. Although I might be able to tweak its install.rdf file to make it compatible, this clearly illustrates why extensions are merely workarounds for bugs and not solutions.
In Mozilla Bugzilla #453455, PA Sicart (budoka) wrote : | #121 |
I'm writing this using Chrome. I finally switched yesterday, after years of using Firefox. This bug is the reason.
In Mozilla Bugzilla #453455, Bugzilla-tf (bugzilla-tf) wrote : | #122 |
*** Bug 541945 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Bugzilla-tf (bugzilla-tf) wrote : | #123 |
*** Bug 723697 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #124 |
*** Bug 756487 has been marked as a duplicate of this bug. ***
Rüdiger Kupper (ruediger.kupper) wrote : | #1 |
- AlsaDevices.txt Edit (494 bytes, text/plain; charset="utf-8")
- AplayDevices.txt Edit (273 bytes, text/plain; charset="utf-8")
- BootDmesg.txt Edit (69.0 KiB, text/plain; charset="utf-8")
- BrokenPermissions.txt Edit (8.4 KiB, text/plain; charset="utf-8")
- CRDA.txt Edit (257 bytes, text/plain; charset="utf-8")
- Card0.Amixer.values.txt Edit (4.0 KiB, text/plain; charset="utf-8")
- Card0.Codecs.codec.0.txt Edit (11.9 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (2.4 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (3.0 KiB, text/plain; charset="utf-8")
- Extensions.txt Edit (1.4 KiB, text/plain; charset="utf-8")
- IpAddr.txt Edit (699 bytes, text/plain; charset="utf-8")
- IwConfig.txt Edit (514 bytes, text/plain; charset="utf-8")
- Locales.txt Edit (734 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (18.7 KiB, text/plain; charset="utf-8")
- PciMultimedia.txt Edit (598 bytes, text/plain; charset="utf-8")
- PciNetwork.txt Edit (1.3 KiB, text/plain; charset="utf-8")
- Plugins.txt Edit (805 bytes, text/plain; charset="utf-8")
- Prefs.txt Edit (3.1 KiB, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (149 bytes, text/plain; charset="utf-8")
- PulseList.txt Edit (17.6 KiB, text/plain; charset="utf-8")
- RfKill.txt Edit (128 bytes, text/plain; charset="utf-8")
- SubmittedCrashIDs.txt Edit (600 bytes, text/plain; charset="utf-8")
- Themes.txt Edit (242 bytes, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (705.5 KiB, text/plain; charset="utf-8")
description: | updated |
RaduStoica (radumstoica) wrote : | #2 |
Hello,
The problem might be on the server end, not in Firefox. Read more here: http://
Rüdiger Kupper (ruediger.kupper) wrote : | #3 |
I see. So this is likely a duplicate of https:/
Rüdiger Kupper (ruediger.kupper) wrote : | #4 |
OT: How do I mark a bug "duplicate" in launchpad, when the relevant bug report is in bugzilla?
Launchpad Janitor (janitor) wrote : | #5 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in firefox (Ubuntu): | |
status: | New → Confirmed |
Edward Donovan (edward.donovan) wrote : | #6 |
Rüdiger -
I added that upstream bug by picking "Also affects project". That gave me a page where I could enter the link. Thanks.
In Mozilla Bugzilla #453455, Mardeg (mardeg) wrote : | #125 |
*** Bug 801786 has been marked as a duplicate of this bug. ***
Changed in firefox: | |
importance: | Unknown → Wishlist |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #453455, Nicolas-barbulesco (nicolas-barbulesco) wrote : | #126 |
I think that request bug 801786 is not a duplicate of request bug 453455.
Request bug 453455 is about making Firefox remember the user choice in case of an "attachment" header sent by the server.
In request bug 801786, I explain that the choice I want is missing. So this request is not about remembering the user choice, it is about offering to the user the choice which is currently missing.
In Mozilla Bugzilla #453455, bwat47 (bwat47) wrote : | #127 |
it does this with .torrent files too...
In Mozilla Bugzilla #453455, SamePaul (samepaul) wrote : | #128 |
I think that constant referencing to RFC is incorrect approach to this problem.
Yes, browser should adhere to RFC and it is good thing. That's why FF should popup "Opening" dialog by default for any file that is marked as "attachment".
But it must be up to user to be able to override this behavior. I don't understand why drag for years this argument for feature that is obviously should be given at user's decision! If I deliberately mark some file type to be opened automatically - why FireFox decides that for me? Why it assumes that it "knows better"? Aren't we all tired of Microsoft's strategy "we know better than you what you need"? Flexibility was always strength of FireFox, why become stubborn on this feature?
If user wants to shoot himself in the leg (like I do) - please let him do it.
Changed in hundredpapercuts: | |
milestone: | none → papercuts-s-firefox |
In Mozilla Bugzilla #453455, Павел Мирончик (mironchikpavel) wrote : | #129 |
I use an extension Web page fixer. It is not ideal solution. Please just fix this bug.
In Mozilla Bugzilla #453455, Kbrosnan-mozilla (kbrosnan-mozilla) wrote : | #130 |
*** Bug 914009 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Alexander-stohr-5 (alexander-stohr-5) wrote : | #131 |
text transfer from bug 57342:
i am using Waterfox 24.0 (64 bit build version of firefox) on Windows 7 x86 64 bits.
when visiting this page: http://
(might require a free account to view or download)
and downloading the windows version (*.exe) of the file set
then i can select any option for opening or saving including the "remember my decision" option.
but when going for the linux version i only get offered two options: open with an application (default here is VLC) or download but the "remember" button is grayed out.
for my impression the browser should be able to remember decisions for explicitly html/mime tagged file formats as already realized. but for for non-tagged or "wildcard"-tagged files and it shall be check for the file name extension (or absence of such an extension - this happens more often than you would think) and decide based upon that extension. so the browser needs not only a mime type default action configuration database/listing but an extension based handling if mime type is not that useable. maybe even the user can pass down certain mime types to the extension based treatment. thus the mime type layer should see a new option: "handle by file extension".
@Sergio - thats a nice proposal in that area. i can support that. its all about options.
BTW i think the dialog does not mention the mime type so i am a bit lost in diagnostics for that my faulty cases using purely the browser. the dialog should mention the mime-type he asks me about.
In Mozilla Bugzilla #453455, Alexander-stohr-5 (alexander-stohr-5) wrote : | #132 |
Created attachment 8338484
screenshot of browser file reception dialog that has a grayed out "remember" item
In Mozilla Bugzilla #453455, Adw-mozilla (adw-mozilla) wrote : | #133 |
*** Bug 526156 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Nehedix (nehedix) wrote : | #134 |
(In reply to Alexander Stohr from comment #124)
> text transfer from bug 57342:
> for my impression the browser should be able to remember decisions for
> explicitly html/mime tagged file formats as already realized. but for for
> non-tagged or "wildcard"-tagged files and it shall be check for the file
> name extension (or absence of such an extension - this happens more often
> than you would think) and decide based upon that extension. so the browser
> needs not only a mime type default action configuration database/listing but
> an extension based handling if mime type is not that useable. maybe even the
> user can pass down certain mime types to the extension based treatment. thus
> the mime type layer should see a new option: "handle by file extension".
I think this is exactly what is needed.
I'm going nuts with PDFs that FF don't want to open with my (external) PDF-Reader anytime, just because of "something" (Mimetypes) that obviously are not suitable to recognize a PDF properly, what can by done by fileextension easily; I recognize the files and have to click open every time ...
an example is here: http://
In Mozilla Bugzilla #453455, Ssprinz (ssprinz) wrote : | #135 |
11/1/2014 "Do this automatically for files like this..." NOT WORKING
I have the same problem, with Excel, Word, Adobe Acrobat and PDF files ETC.
I've been quietly waiting for a fix and after so many new versions (I'm now on 33.02) , it's still not fixed. I'm very surprised to find so few asking about this, as every indication, including the program chooser, points to nice functionality (if only it worked).
Wouldn't one think that after all this time, and with so many web sites "presenting the wrong way", that it may be time to consider Mozilla fixing this problem and not the rest of the world that should present better so that the great Foxfire functionality could work ?
I mean, the data is obviously there to launch whatever program is not launching. Someone please have pity on the rest of the world and compensate for their inexcusable ignorance. Please ?
In Mozilla Bugzilla #453455, Mar5 (mar5) wrote : | #136 |
Still waiting for an update.
In Mozilla Bugzilla #453455, Ssprinz (ssprinz) wrote : | #137 |
FROM Bug 647633 - "do this automatically for files like this from now on" is disabled most of the time
Stop for a second and consider WHY DOES Menu_OPTIONS_
In Mozilla Bugzilla #453455, Gingerbread-man-2 (gingerbread-man-2) wrote : | #138 |
*** Bug 941708 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Ssprinz (ssprinz) wrote : | #139 |
Stop for a second and consider WHY DOES Menu_OPTIONS_
In Mozilla Bugzilla #453455, David-peters (david-peters) wrote : | #140 |
This is so ridiculous.
Anyway, try this:
https:/
or possibly this:
https:/
In Mozilla Bugzilla #453455, Ssprinz (ssprinz) wrote : | #141 |
What is so Ridiculous?
That Firefox still has this glaring bug! Thank you, but both offerings define "KLUDGE". A key-press to hide the lack of underlying operability of the function. Please!
WHY DOES Menu_OPTIONS_
I really like Firefox. Can't this be escalated? -ss
In Mozilla Bugzilla #453455, Ssprinz (ssprinz) wrote : | #142 |
I think it's nice this bug (which is 7 1/2 years old) is having the many duplicate reports of it's existence consolidated, and also "re-opened". Housekeeping of 8 year old bugs is important for posterity, not to mention future historians, who may look back to draw conclusions.
My simple mind doesn't understand why this can't be fixed, but then again, Firefox developers have never bothered to explain that. I know, I know. I'm too stupid to live. -ss
In Mozilla Bugzilla #453455, Jaws (jaws) wrote : | #143 |
*** Bug 1292599 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Martin (martin22) wrote : | #144 |
Should this bug explicitly be marked as duplicate of older bug 236541? or the other way around?
In Mozilla Bugzilla #453455, Mardeg-5 (mardeg-5) wrote : | #145 |
(In reply to martin.monperrus from comment #137)
> Should this bug explicitly be marked as duplicate of older bug 236541? or
> the other way around?
Neither. Bug 236541 comment 38 restricts the patch to only the case when "save as" is the choice.
In Mozilla Bugzilla #453455, Martin (martin22) wrote : | #146 |
Hum, this subtlety isn't visible in the bug title:
"do this automatically for files like this" doesn't work when Content-
Make "do this automatically for files like this from now on" work even with "content-
According to your comment, I understand that "do this automatically for files like this" doesn't work only when "open with" is selected?
In Mozilla Bugzilla #453455, Glowka-tom (glowka-tom) wrote : | #147 |
+1
In my case this is the behavior you described: "do this automatically for files like this" doesn't work ONLY when both are true "open with" is selected and "content-
In Mozilla Bugzilla #453455, Gingerbread-man-2 (gingerbread-man-2) wrote : | #148 |
*** Bug 1487852 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gingerbread-man-2 (gingerbread-man-2) wrote : | #149 |
*** Bug 1527399 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Veron-nv (veron-nv) wrote : | #150 |
Developers, please finally solve this big problem. She is in the open state for 11 years. Google Chrome has no such problems, I really want that in Firefox there is no problem in this direction. I want a comfortable use.
In Mozilla Bugzilla #453455, ipatrol (ipatrol6010) wrote : | #151 |
I'm going to try to summarize the problem here as I see it.
Over the last few years, Mozilla has moved in the direction of focusing on security at the cost of some user control. Though to my knowledge no official statement has ever been made acknowledging this, it is apparent through their actions and the tone of some of the things they *have* said. This is not the place to debate that decision, and I do not wish to, but for our purposes it suffices to note that there *is* inherent tension between those two aims. Any power the user is given to alter the behaviour of the browser's interaction with external content, risks creating a security vulnerability. Most users do not have a strong grasp of security theory, and rely heavily on Mozilla's experts to keep them safe.
There is an inherent risk in having an external application automatically process *any* kind of file. Many common programs are not designed to handle malicious input, and some that are do a poor job at it. *Glances towards Adobe Acrobat*. It is a sane default to ask the user before proceeding any time there is an elevated risk of bad behaviour. Since it appears from a quick search that a number of server operators use `content-
It has been suggested in comment 90 that people out to do less talking and more patch submitting, but as comment 110 noted, people are reluctant to work on creating a patch when they are uncertain if it has any chance of being accepted due to design choices by the development team. I **strongly** suggest that a Mozilla staff member make an executive decision as to whether this behaviour is in fact a bug to be fixed, and state so in a comment, or else close this as `WONTFIX` and say that a decision has been made to err on the side of security and not let the end user select a default behaviour when a `content-
In Mozilla Bugzilla #453455, Ssprinz (ssprinz) wrote : | #152 |
After 11 years - more and more clarity develops on this issue.
Please consider USER INTENT as an important aspect in the early design and later - policy implementation of this "feature". Now it is known how important (forced) user security is regarding XSS-type attacks, we have BOTH SIDES of the issue exposed. Seems like, the solution involves a little more programming, not merely "turning off" security concerns.
I'm probably typical in my INTENT. I have repetitive tasks where I download CSS files from trusted sources, format them, and archive them.
On selection of "do this automatically for files like this from now on" Firefox can throw a (severe) user warning about XSS-type attacks, then offer to allow the recurrent behavior, explicitly for the chosen server, forevermore. User has been WARNED, has actively chosen to do the deed with THIS SERVER ONLY, and has exonerated Firefox while maintaining the personal freedoms we expect using personal computers. Of course, removal of the "user approval for the site" must also be programmed.
For examples of WARN but "DO if approved by user" - look no further than Windows.
In Mozilla Bugzilla #453455, Alexander Stohr (alexander-stohr) wrote : | #153 |
even a trusted site can be compromized at some point in time.
nothing against rarely requested features and nothing against support for legacy items.
thats about free software: having the ability to do so.
putting a fence in place with a clear explanation why its not recommended to use that is fine.
maybe adding a monthly security report will help people checking and re-thinking their special settings.
In Mozilla Bugzilla #453455, Mak77 (mak77) wrote : | #154 |
There's too many proposals and opinions here to be able to make a choice that will satisfy everyone.
There are 2 possible ways out, that I see, that are not exclusive:
1. hide the "Remember my choice" checkbox when it can't be respected. While this doesn't solve the problem (it hides it under the carpet), it would be less surprising and infuriating for the user. This is pretty much bug 285976, afaict. I think it'd be a safe thing to do regardless and wouldn't prevent future and better fixes.
2. Just let the user action go through, that is basically what the other browsers are doing (at least Chrome, I just tried through this test page: http://
I don't think we'd be adding a pref, a pref like this is the classical footgun, either this is a security risk or it is not, a pref doesn't solve that and can be easily under-evaluated.
I finally wonder if add-ons can work similarly to a pref for user willing this behavior, wouldn't something like https:/
I know this is not a finalized answer, but the question was whether this is a wontfix. I don't think it is, it just needs some middle steps and investigation to figure out the actual risk, and why other browsers think that risk is moot.
In Mozilla Bugzilla #453455, fireattack (fireattack) wrote : | #155 |
That addon just replaces the header of "content-
As you may already see (and mentioned by plenty of people above), this means that if a site really wants to do malicious things (by auto opening certain files), it can do already: just use "content-
So in my opinion, disallowing "do this automatically" for "content-
And of course, such addon will have side effect for file-types that can be opened both inline and or as attachment/download (like images that are supposed to be downloaded will now be opened in Firefox).
Changed in firefox: | |
importance: | Wishlist → Medium |
In Mozilla Bugzilla #453455, Bmercer (bmercer) wrote : | #156 |
Of course there's a security risk to handling attachment downloads. Simply surfing the web is a huge security risk.
Allow me to make the decision to automatically (without a prompt) decide to download or open a specific type of file, because I know what I'm doing. Don't make it the default, so Grandma doesn't get pwned, but don't limit me to Grandma's training wheels.
But regardless of whether you allow me to actually use my computer how I want to, STOP LYING TO ME.
When you tell me that checking a box will do something, and it does not do that thing, and you KNOW it doesn't do that thing, you're lying to me.
In Mozilla Bugzilla #453455, Martin (martin22) wrote : | #157 |
For the record, addon "InlineDisposition (WebExtensions)" is still a valid workaround: https:/
In Mozilla Bugzilla #453455, Gingerbread-man-2 (gingerbread-man-2) wrote : | #158 |
*** Bug 1582927 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Vagmer (vagmer) wrote : | #159 |
Just in case, adding my vote to... not leave this old bug unfixed. This behavior is clearly incorrect from any end-user perspective.
As for security "concerns" here, they really are fluff; it is not the browser's duty to silently block or ignore explicit manual user actions (setting a default program) in order to potentially defend said user from said explicit action... Further down that road lies arbitrarily silently ignoring more user settings as well as attempts to access certain "potentially dangerous" sites or resource types altogether. And the current behavior is not a feature and offers no consistent "protection" anyway, as the misbehavior doesn't occur for other content-
In Mozilla Bugzilla #453455, Kw96-m (kw96-m) wrote : | #160 |
Yes, I'm of the same opinion; it might be correct from a standards point of view, but from a user's perspective it's just a bug.
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #161 |
*** Bug 1589121 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #162 |
*** Bug 1600471 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #163 |
*** Bug 1623555 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Jonathan Watt (jwatt) wrote : | #164 |
An example of a PDF with Content-
Changed in firefox (Ubuntu): | |
importance: | Undecided → Wishlist |
Changed in hundredpapercuts: | |
status: | New → Confirmed |
importance: | Undecided → Wishlist |
In Mozilla Bugzilla #453455, Thomas-dallagnese-b (thomas-dallagnese-b) wrote : | #165 |
(In reply to monperrus from comment #150)
> For the record, addon "InlineDisposition (WebExtensions)" is still a valid workaround: https:/
InlineDispotition didn't work for me, but the more recent Display Inline one worked (https:/
In Mozilla Bugzilla #453455, Adam Stankiewicz (sheerun) wrote : | #166 |
Jesus guys, this is basic functionality and it doesn't work for 12 years... I know it isn't fun to fix, but please!
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #167 |
*** Bug 1657785 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Smayer97 (smayer97) wrote : | #168 |
I do not understand why this bug has taken this long to get resolved. At least one scenario is that FF simply opens the dialogue box giving the option to choose what software to open the attachment but the "Do this Automatically for files like this from now on" is selected. How hard is it to have FF respect this option if it is selected and NOT present the dialogue box? Seems like a simple logic to implement.
Rüdiger Kupper (ruediger.kupper) wrote : | #169 |
I gave up on Firefox. Switched to Chromium instead. I'm sorry, but you need to take action at some time (and time means: 7 years and 10 months since I reported this). I hope the Firefox community can work this out, I am not longer part of it.
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #170 |
*** Bug 1668182 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #171 |
*** Bug 1679561 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gingerbread-man-2 (gingerbread-man-2) wrote : | #172 |
*** Bug 1702084 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #173 |
Programmers of FireFox should finally do something about this. Since years during each download I am offered this checkbox "Do this automatically for files like this from now on." and never, ever is anything done in the way as my checked checkbox would indicate. If this bug, I consider this clearly as a bug, is indeed related to bug 285976, then it would indeed be time to address this. IMHO this gets close to effrontery to offer that checkbox since years and never honoring it in any way, not even with a warning that it will not be respected. Very, very poor programming. The fix suggested in the discussions of bug 285976, i.e. hiding that checkbox, would for me and all other confused users probably be an acceptable alternative to an actual implementation of the handling of the downloads as offered via this checkbox. It is time to act and hide this confusing checkbox I believe.
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #174 |
BTW, I am a programmer myself. I know this can't be a big deal to outcomment the display of this checkbox. ;-)
In Mozilla Bugzilla #453455, Smayer97 (smayer97) wrote : | #175 |
Why is it necessary to avoid fixing this rather than a band-aid solution?
This used to work just fine under at least FF 48 and slightly newer, which was not that long ago.
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #176 |
@ smayer97: Of course fixing this would be much better. But I have given up hope. As you can see this bug is with us since 13 years! The same is the case for numerous bugs related to downloading (not only Firefox also Thunderbird, causing me to totally stop using Thunderbird) . As a programmer I have provided detailed solution suggestions considering all aspects. It was never picked up. So I have given up trying to help and have given up to expect anything. Perhaps for band-aid I still dare to hope for. ;-)
In Mozilla Bugzilla #453455, Psychonaut (psychonaut) wrote : | #177 |
(In reply to andreas.fischlin from comment #166)
> BTW, I am a programmer myself. I know this can't be a big deal to outcomment the display of this checkbox. ;-)
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".
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #178 |
@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.
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #179 |
@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!!!!!
In Mozilla Bugzilla #453455, Vagmer (vagmer) wrote : | #180 |
(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.
In Mozilla Bugzilla #453455, Psychonaut (psychonaut) wrote : | #181 |
(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:/
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #182 |
*** Bug 1715025 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gcklema (gcklema) wrote : | #183 |
(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:/
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.
In Mozilla Bugzilla #453455, Bugsgalore (bugsgalore) wrote : | #184 |
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.
In Mozilla Bugzilla #453455, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #185 |
*** Bug 1725562 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Wls220spring (wls220spring) wrote : | #186 |
*** Bug 1690395 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Wrhenshaw99 (wrhenshaw99) wrote : | #187 |
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.
In Mozilla Bugzilla #453455, Bmercer (bmercer) wrote : | #188 |
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.
In Mozilla Bugzilla #453455, Wrhenshaw99 (wrhenshaw99) wrote : | #189 |
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?
In Mozilla Bugzilla #453455, Wrhenshaw99 (wrhenshaw99) wrote : | #190 |
Also... why is this listed as an enhancement. A setting in their existing program doesn't work. This is a BUG not an enhancement.
In Mozilla Bugzilla #453455, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #191 |
*** Bug 1727175 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Worcester12345 (worcester12345) wrote : | #192 |
(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.
In Mozilla Bugzilla #453455, Nolanktx (nolanktx) wrote : | #193 |
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.
In Mozilla Bugzilla #453455, Smayer97 (smayer97) wrote : | #194 |
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?
In Mozilla Bugzilla #453455, Pablo-muir (pablo-muir) wrote : | #195 |
*** Bug 1731479 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Bob-nelson-v (bob-nelson-v) wrote : | #196 |
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.
In Mozilla Bugzilla #453455, Worcester12345 (worcester12345) wrote : | #197 |
This should be changed to Priority 1, Severity High.
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #198 |
(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).
In Mozilla Bugzilla #453455, Worcester12345 (worcester12345) wrote : | #199 |
(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.
In Mozilla Bugzilla #453455, Bmercer (bmercer) wrote : | #200 |
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.
In Mozilla Bugzilla #453455, Nolanktx (nolanktx) wrote : | #201 |
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:/
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #202 |
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.
In Mozilla Bugzilla #453455, Rachel-u (rachel-u) wrote : | #203 |
(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.
In Mozilla Bugzilla #453455, Bob-nelson-v (bob-nelson-v) wrote : | #204 |
(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.
In Mozilla Bugzilla #453455, Mikeyy (mihovil) wrote : | #205 |
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.
In Mozilla Bugzilla #453455, Nolanktx (nolanktx) wrote : | #206 |
(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/
Betterbird is a fork of Thunderbird and is working just fine. https:/
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/
In Mozilla Bugzilla #453455, Andreas-fischlin (andreas-fischlin) wrote : | #207 |
(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.
In Mozilla Bugzilla #453455, Worcester12345 (worcester12345) wrote : | #208 |
(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...
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #209 |
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.
In Mozilla Bugzilla #453455, Wls220spring (wls220spring) wrote : | #210 |
*** Bug 1737586 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Anjeyelf (anjeyelf) wrote : | #211 |
(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.
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #212 |
(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.
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #213 |
*** Bug 1736804 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #215 |
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) wrote : | #214 |
Fixed in Firefox 97.
Changed in hundredpapercuts: | |
status: | Confirmed → Fix Released |
Changed in firefox (Ubuntu): | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #453455, Mathew Hodson (mhodson) wrote : | #216 |
This was fixed by bug 1710941 when browser.
Changed in firefox: | |
importance: | Medium → Unknown |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #453455, Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote : | #217 |
The fix got postponed to 98 because of last-minute issues being discovered while it was on beta.
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