Bugzilla

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous. Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to change that string or something so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and it's much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to change that string or something so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and it's much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand that string that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and it's much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and it's much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and its implementation would be much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and its implementation would be much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

Edit: Oh, I almost forgot. All other things being equal, it would be worse for the user to expect a file to be saved and have Firefox actually delete it than for the user to expect a file to not to be saved and have Firefox actually save it. We want to err on the side of caution when the stakes are as high as unexpected data loss. So, files being unexpectedly saved might be the kind of thing we'd want to resolve, but that's minor enough to be on the level of an enhancement. On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and its implementation would be much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

Edit: Oh, I almost forgot. All other things being equal, it would be worse for the user to expect a file to be saved and have Firefox actually delete it than for the user to expect a file not to be saved and have Firefox actually save it. We want to err on the side of caution when the stakes are as high as unexpected data loss. So, files being unexpectedly saved might be the kind of thing we'd want to resolve, but that's minor enough to be on the level of an enhancement. On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Edit: Instead of adding "Save temporarily and" to all of those strings, we could split the dropdown menulist into sections and add menucaptions that make it clear what the following menuitems do. So for the temp options, the menucaption above them would say `Save file temporarily and...` and then the options would just say "Save file" or "Open with..." as they currently do. And the menucaption above the non-temp options would say `Save permanently and...` as you'd expect. So the menupopup would be separated into little semantic groupings to allow the strings to remain pretty short. That way we're not stretching it out beyond the normal width of the menulist column.

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and its implementation would be much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

Edit: Oh, I almost forgot. All other things being equal, it would be worse for the user to expect a file to be saved and have Firefox actually delete it than for the user to expect a file not to be saved and have Firefox actually save it. We want to err on the side of caution when the stakes are as high as unexpected data loss. So, files being unexpectedly saved might be the kind of thing we'd want to resolve, but that's minor enough to be on the level of an enhancement. On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.

(In reply to Martin Z from comment #85)
> I think your post summarizes the many facets of this problem very well. I immediately had to think of these options (in the main settings):
> 
>     [ ] Keep all downloaded files
>     [x] Store files that are downloaded only for viewing in [directory selector] and delete them after [integer selector] days.
> 
> The selected directory and number of days could be set to sane defaults. Ignoring the exact wording, but wouldn't this be much more concrete about what happens to downloaded files while giving power users back what they are missing?

Yeah I have struggled a lot with any conceivable strings that could concisely explain the complexity of the proposed features. I'm afraid "downloaded only for viewing" is too ambiguous (the rest of the string is excellent though). Again, these kinds of things seem obvious to people in this conversation who know precisely what we're talking about, but the huge majority of users have no idea how Firefox would know that they intended to download a file only for viewing.

As I see it, the main hurdle to exposing this kind of preference is the fact that it's changing the behavior of an action that only says "Open." We would need to expand the "Open" string in the handler and the UCT dialog so that it contains a unique keyword that we could reference in the pref affordance in about:preferences. The difficulty is that there isn't really a better string for ordinary users. "Save temporarily and open" would adequately explain what happens if the opt-in pref is enabled, but obviously it would be false when the opt-in pref is disabled.

Here's a possibility I've been considering. I have another proposal (bug 1747343) that looks like it will move forward. This involves extending the file handler configuration interface in about:preferences such that it allows the user to configure the default action for all unknown/unconfigured content types. This doesn't solve this problem, but it would leave an opening to solve this problem in a clearer, more user-friendly way.

For some background, right now, the actions you can choose for a given content type are `Open in Firefox`, `Always ask` (open a dialog that exposes the same action choices), `Save file` (opens a "Save as" dialog if the user has enabled that in the radio group above), `Use OS default application`, and `Use other...`

Those options are available per-content type in about:preferences. This proposal would add an extra item in the list that would be used for any content types not already in the list (see the images in my comments in bug 1747343). This special item could not be configured to `Open` in any handler, but could be configured to `Always ask`. That would cause a dialog prompt to appear when downloading a file of unconfigured content type, and that prompt would ask how you want to proceed.

So, here's the possibility I'm considering. Instead of adding a pref that changes what the "Open" actions do, we just add new actions (like `Open in Firefox`) that save the file temporarily and open it. So that would add `Save temporarily and open in Firefox`, and `Save temporarily and open in [OS default application]`, and `Save temporarily and open in...`. These would appear in the dropdown list when you choose the action for a handler in about:preferences. And they would also appear in the dialog prompt that appears when the handler is configured to `Always ask` (that way, for unconfigured content types, you can still choose to save them temporarily from the dialog).

Edit: Instead of adding "Save temporarily and" to all of those strings, we could split the dropdown menulist into sections and add menucaptions that make it clear what the following menuitems do. So for the temp options, the menucaption above them would say `Save file temporarily and...` and then the options would just say "Save file" or "Open with..." as they currently do. And the menucaption above the non-temp options would say `Save permanently and...` as you'd expect. So the menupopup would be separated into little semantic groupings to allow the strings to remain pretty short. That way we're not stretching it out beyond the normal width of the menulist column.

And as for the unknown content type dialog (prompted by choosing "Always ask" in about:preferences), a checkbox could be added to the dialog. The checkbox would either say `Save file temporarily` or `Save file permanently`, not sure which is clearer. That checkbox could either 1) feed back into the handler for the content type in question, so that user selection is saved per-content type; 2) record the user selection for the UCT dialog generally, such that it applies to all content types that are configured as "Always ask"; or 3) not save user selection at all.

Obviously this isn't super concise either, but it's pretty clear what it's doing, and it doesn't require multiple sentences to explain a single checkbox. It's much more powerful because it gives the user choices per-content type. So if you generally want to save PDF files temporarily and open them in Firefox, but you want to save other office documents permanently but still open them in your default app, you can do both. This solution would not just restore the old quirk for power users but actually expand it into an actual feature, and without negatively impacting average users.

I'm not 100% convinced on that, and its implementation would be much more technical than the options discussed already. But it's the only option proposed so far that I think could actually be shipped to the release channel and exposed in a Firefox UI. All the other proposals we've considered are just too hard to explain clearly and concisely or are just too janky and unusual.

(In reply to Csaba Bencze from comment #86)
> While I understand this and even agree with it in some aspect, there are a lot of assumptions about new or less technical users. Non-technical users might not even treat opened files as downloads (temoprary or not is irrelevant in this case) because they had to choose to open OR save. Why would they assume that opening is also saved when they didn't choose to save. They think they open it "from the Internet" and not open a saved file from their computer. If they want to open a saved file they do it from the download panel or from other application.

That's an interesting idea that might be worth investigating. For my part, I suspect users will understand that opening is saving because every other stage of the process is the same as any other download procedure. Nothing different happens except that the file is opened. First of all, the downloads panel opens automatically. It shows the download the user chose to "Open" in the same list as all the other downloads. Provided the download is finished, it shows a button with a folder icon directly to the right of the download. That button opens the folder in which the download is located. And since it has a folder icon and its tooltip says "Show in folder," it's abundantly clear that it's in a folder just like all the other downloads.

It's possible someone could miss this detail at first, but such a confusion would be less likely and much less persistent than a confusion surrounding files going to the Temp folder or being deleted when Firefox closes. In that case, there's _literally_ no indication that the file is going to be sent to the Temp folder (which many users won't even know exists), let alone deleted. _We_ know that it would only happen when the user chooses "Open..." as the handler's default action or chooses "Open" from the unknown content type ("Always ask") dialog. But it doesn't happen when the user "Opens" the file by other means, such as from the downloads panel.

That's obviously a recipe for confusion unless the affordances that actually delete the file say something to that effect. It wouldn't be impossible to add that clarification, but that's only one of the numerous problems with the Temp folder and scheduled deletion. And of course, that one cuts both ways. Even if it's currently unclear for highly non-technical users that choosing "Open" will save the file _and_ open it, that's only a presentation issue. It could be clarified pretty quickly by just changing the relevant strings from "Open" to "Save and open" or "Open when finished saving" or something along those lines.

Edit: Oh, I almost forgot. All other things being equal, it would be worse for the user to expect a file to be saved and have Firefox actually delete it than for the user to expect a file not to be saved and have Firefox actually save it. We want to err on the side of caution when the stakes are as high as unexpected data loss. So, files being unexpectedly saved might be the kind of thing we'd want to resolve, but that's minor enough to be on the level of an enhancement. On the other hand, if Firefox deletes files that the user intentionally downloaded with the expectation of permanence, that's a more urgent and serious defect.