1709129 - Downloads panel should auto open on download (perhaps with opt-out?) when we remove the "what do you want to do with this file" dialog

Status: RESOLVED FIXED

(Firefox :: Downloads Panel, enhancement)

Description

[Amy Lee [:amylee] UX]

Attachment: Download - OPENED PANEL.mp4

Expected:
The downloads panel should automatically open on start of a download

Actual:
The downloads does not open on start of download

To follow-up with this fix:

If the download panel remains open after the download is completed, the download icon reverts to grey

If the download panel is closed prior to the download being completed, the download icon reverts to blue (to indicate that the download is completed since the panel is close).

Comment 1

[Amy Lee [:amylee] UX]

Attachment: Download - CLOSED PANEL.mp4

Comment 2

[Marco Bonardo [:mak]]

This is how the downloads panel was working years ago.
It was reverted because some users found it extremely annoying, and now it only opens for the first download as an onboarding effort, that was, imo, a sensible compromise. It is even more annoying if we also show the Save As dialog, because then you have to dismiss 2 things per each download.

Comment 3

[Marco Bonardo [:mak]]

A compromise I was discussing with Paolo was to normally open the panel, but don't open it if a download is ongoing. This would avoid annoying heavy downloaders that are starting up multiple downloads in a short timeframe.

Comment 4

[Micah [:mtigley] (she/her)]

(In reply to Marco Bonardo [:mak] from comment #3)

A compromise I was discussing with Paolo was to normally open the panel, but don't open it if a download is ongoing. This would avoid annoying heavy downloaders that are starting up multiple downloads in a short timeframe.

I like this idea. In addition, if the user doesn't want to see it at all, we can also add a way to opt-out. Perhaps by adding a checkbox in the panel itself, or maybe providing an option in about:preferences under "Downloads"? It could also provide us a way to measure that automatically opening the panel isn't a regression.

Amy, does auto-opening the download panel only if no other downloads are in progress sound fine here?

Comment 5

[Marco Bonardo [:mak]]

(In reply to Micah [:mtigley] (she/her) from comment #4)

I like this idea. In addition, if the user doesn't want to see it at all, we can also add a way to opt-out.

I'd keep that as a second possibility, I'd first try with just always opening except when a download is already ongoing, and examine the flow and feedback with that. That may also allow for a leaner QA (less options and cases to consider) for the MVP.

Comment 6

[Amy Lee [:amylee] UX]

Assigning this to @[e-mail] as she is currently UX for MR1.

Comment 7

[Ava Katushka]

Attachment: Bug 1709129 - Open downloads panel when new download starts. r?mtigley

Comment 8

[katieC]

if I recall correctly, the change to default to open the Download Panel was made for Proton based on user input that folks couldn't figure out where their downloads went / re-find them easily, plus the hope of eliminating the additional save dialog step. Is changing the interaction/flow considered an experiment to see if this improves the experience for people, if so, how are we planning on measuring this? NI'ing Romain to see if there is more info.

Additionally, at this point, and in agreement with Comment 5, we shouldn't add a dismiss checkbox or additional preferences/settings when we haven't (yet) identified if this solution solves a user problem or creates a new one.

Comment 9

[Romain Testard [:RT]]

(In reply to katieC from comment #8)

if I recall correctly, the change to default to open the Download Panel was made for Proton based on user input that folks couldn't figure out where their downloads went / re-find them easily, plus the hope of eliminating the additional save dialog step. Is changing the interaction/flow considered an experiment to see if this improves the experience for people, if so, how are we planning on measuring this? NI'ing Romain to see if there is more info.

Additionally, at this point, and in agreement with Comment 5, we shouldn't add a dismiss checkbox or additional preferences/settings when we haven't (yet) identified if this solution solves a user problem or creates a new one.

Yes there was user feedback as well as data showing that only 26% of users downloading a file open the panel after the first download: https://sql.telemetry.mozilla.org/queries/72914#182698
This share increases with the number of downloads, indicating that users likely repeat downloads to eventually find the location to retrieve downloads from. This is not currently considered an experiment but we'll be measuring the impact of the change through the (open file event) / (download file event) ratio.

Comment 10

[:Gijs (he/him)]

(In reply to Romain Testard [:RT] from comment #9)

(In reply to katieC from comment #8)

if I recall correctly, the change to default to open the Download Panel was made for Proton based on user input that folks couldn't figure out where their downloads went / re-find them easily, plus the hope of eliminating the additional save dialog step.

Right. It's worth noting that right now, if you have a workflow where you open files of a certain type in an application (e.g. word documents opening in MS Word), you just click OK in the "what do you want to do with this file" dialog. Once we get rid of the dialog, the file will download and you'd have to click the download arrow first, then click the download in question to open it. This could be perceived as being slower by users, which adds to the desire to open the panel immediately, so it continues to be a 1 click action to open the file.

Additionally, at this point, and in agreement with Comment 5, we shouldn't add a dismiss checkbox or additional preferences/settings when we haven't (yet) identified if this solution solves a user problem or creates a new one.

Yes there was user feedback as well as data showing that only 26% of users downloading a file open the panel after the first download: https://sql.telemetry.mozilla.org/queries/72914#182698

AIUI we don't know how many of these people pick "open with [application]" in the dialog, right? In which case they don't need to open the download panel to open the file - the file will open once downloaded without further user action. We should probably consider getting some more telemetry about how frequent that case is. We can't assume that the other 74% don't know where the downloads have gone.

Comment 11

[Romain Testard [:RT]]

AIUI we don't know how many of these people pick "open with [application]" in the dialog, right? In which case they don't need to open the download panel to open the file - the file will open once downloaded without further user action. We should probably consider getting some more telemetry about how frequent that case is. We can't assume that the other 74% don't know where the downloads have gone.

Fair point, I was assuming that download telemetry was only capturing users hitting the "Save File" button
I looked into share of users opening the panel per file extension, your theory seems to be right where doc, csv and xls files have a low share of users opening the panel (https://sql.telemetry.mozilla.org/queries/80725/source#200218 - this query is not 100% right since it compares users opening the panel and users downloading at least one file - obviously the more files you download the more likely you'll open the panel during a session).

Something to keep in mind though is that pdf file downloads account for more than a third of downloads, a scenario where I assume we expect users to use Firefox as a primary action:

• 37% *.pdf
• 16% *.jpg
• 5.5% *.zip
• 4.5% *.mp4
• 4% *.docx
• 3.5% *.xlsx
• 2.5% *.png
• 2.5% *.jpeg
• 2.4% *.exe
• 2.1% *.xls
• 1.4% *.doc
• 18% Other

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/052668cef0f9
Open downloads panel when new download starts. r=Gijs

Comment 13

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/052668cef0f9

Comment 14

[Shane Hughes [:aminomancer]]

I appreciate the time you guys have taken to respond to questions and complaints about this, especially @Gijs. I still think some aspects of this plan should be revisited or expanded, including the commitment to not maintaining an option to restore the unknown content type dialog. I'm sure this comment is gonna be nightmarishly long so I apologize in advance for the word vomit, but it's a complicated issue and I want to make the best possible argument for preserving the download functionality as I (and many others) currently use it.

I'm pretty sure I understand the motivations for getting rid of the tmp folder behavior, but I believe removing the UCT dialog severely restricts user options, particularly with regard to save location and choosing file handlers. It either restricts your per-download options or it requires you to choose a save folder individually for everything you download. Just consider that you may not always want to open a file of a given type in its default handler. I download SVG files and PDF files a lot. Sometimes I want to view them in firefox; sometimes I want to edit them in VS Code or Acrobat or w/e. If I set them to open in the default system app or to open in firefox, what do I have to do if I want to deviate from that behavior for a specific file?

I need to 1) close the file that just opened automatically; 2) open the downloads panel; 3) right click the download item; 4) click the menu item to open it in the system viewer. This menu item doesn't even give me the option to choose a different app, by the way. Only the default. So it's not remotely a 1:1 substitute for the unknown content type dialog in the first place. But even if it was, this is much more onerous than what I have to do currently:

Right now I have it set up (with the temporary pref browser.download.improvements_to_download_panel) so that when I download an SVG file, it doesn't immediately open in Firefox. But "open in Nightly" is the default selected radio button in the dialog. (or at least it is on sites that aren't currently broken by bug 1747194) So if I want to do the default action, I only need to hit enter or click the primary button. If I want to deviate from the default action, all I need to do is click a different radio button and so on.

Moreover, when I want to save a file without opening it, generally speaking I want to choose where it's saved. But if I just want to quickly open a file, (especially if I want to open it in firefox) then I don't want to worry about where it's saved. (Frankly, I don't even want it to be permanently saved in the first place. I'd rather just pretend it never saved in the first place, almost like I opened it in a browser tab over http rather than file protocol. I get that I can choose my download folder, but that's not a replacement for the tmp folder, since even if I configured firefox to download files to my actual tmp folder, I'm still losing the automatic garbage collection. I'm still gonna need to clean stuff up by hand)

I get that there are arguments against the tmp folder, which is why I mentioned it last. I don't feel quite as strongly about it but I feel like losing the option is still a serious loss in terms of impact on users. I think many users will find it burdensome and take this as another affront. The justifications seem a little obscure to me, too, but I'm no expert. I don't doubt that they are real issues, they just seem to me to be outweighed by the compelling interest in temporarily saving files. Anyway, more serious is the lack of control over whether a particular file (not file type or disposition but just an individual downloading file) is opened.

The design doc has a strange comment on this issue: "If you want to open a file, you can now click the download item before it has finished, and Nightly will open the file immediately once it has." — Maybe I misunderstand the point of this, but the vast majority of my downloads are finished in a matter of milliseconds. Of course, if I'm downloading something giant enough that I have time to click the downloads toolbar button and click the download item before the download finishes, then chances are it's not the kind of tiny little file you wanna temporarily save just to quickly open and review it. But I don't think it matters, since whether you click the download item before or after it finishes, this still doesn't get you out of needing to choose where it's saved. So again, you either use the same folder every time for every file type in every context... or you have to choose the folder individually every time for every file type in every context, even if you're just trying to preview a tiny little file rather than "save" it.

I don't want to worry about where a file is saved when I'm immediately opening it. That is, I have firefox set to "always ask you where to save files." Currently if I choose to open in Nightly, it doesn't open the save as dialog at all, since it automatically saves in the tmp folder. With the tmp folder removed, there's this knock-on effect of losing that ability to not "save as" a file. Like, I want to have control over where I save files, but I want to be able to abdicate that responsibility at will, if I choose to. That's what I can currently do, and I do it all the time. If I'm losing the tmp folder, then at least it would be nice to be able to press a button to use a default save folder (just for this one time) and not have to deal with the "save as" dialog. But that can't really happen in the first place because there won't be any download dialog. The very first affordance will be the "save as" dialog.

I feel like these design choices are totally oriented around the default settings and behavior — save to "Downloads" folder without any prompt, don't open the file. From that POV I think this plan and the implementation so far make a lot of sense. If I'm content with everything I download piling up and collecting dust in the Downloads folder, then the downloads panel can become a kind of convoluted substitute for the unknown content type dialog. From there, I can at least open the file and dictate future behavior. And from that perspective I can see why you guys thought it was a great idea to make the downloads panel automatically open when a download finishes, so the user can immediately choose what to do with the file... basically like what the unknown content type dialog does.

In other words, it seems like in opening the panel automatically, we're trying to fill the giant void left behind by the removal of the unknown content type dialog. But clearly some people are irritated by the panel automatically opening, since a bug was opened for that. And it doesn't let you choose where the file goes anyway. It doesn't let you cancel the download, doesn't let you delete the file either. If I want to delete the file, e.g. since firefox is no longer gonna clean things up on its own, I'm gonna have to find it in file explorer/finder/whatever and manually delete it. If we're seriously committed to this course of action we should at least have a context menu item for deleting the file from disk.

So, the best I can do to replicate my current behavior is to simply accept that my "Downloads" folder is now a giant dumping ground, and revert everything to default settings. That way I can "choose" what happens when I download a file by opening the downloads panel. But that leaves me with no option to save the file to a particular folder. If I want that level of control, then now I need to accept the burden of choosing a download folder for every download, whether it's a file I need on disk long-term or just an email attachment I want to read for 30 seconds and never deal with again. Whereas now, I only need to make that decision for files I explicitly choose to 'save as'. I hope I'm articulating this well enough, it's kind of hard to explain what bugs me about this since it's basically a large "decision tree" that seems to have been severely pruned.

I reviewed the design doc but I still don't really understand if there are plans to recreate the same level of functionality I currently have, where with a single click I can choose between opening in firefox, opening in default system handler (VS Code if the file type is unknown), or save as.

Spending time individually binding specific filetypes to specific handlers can solve some problems, but I can't anticipate every file type I'll ever download. Many files I download don't even have a file extension, and I don't always want to do the same thing with every kind of extensionless utf/ascii file. I want to choose at the time I download the file, without having to deal with the "save as" dialog if I'm only trying to preview an SVG file or something.

Downloading files is one of the most important things users do with a web browser. Having to go through all these extra steps seems like a problem. I get that there are downsides but these are marginal in comparison to the benefits. Even the issue of saving to the tmp folder is silly in my mind, and that's the one I feel least strongly about. The possibility of causing odd problems in obscure environments/configurations seems obscure compared to the difficulties created by removing the unknown content type dialog. The fact that the tmp folder is harder to find is pretty marginal, since nothing is going to save there in the first place unless the user doesn't want to save the file permanently in the first place. After all, why would a user go looking for a file that they intentionally, explicitly chose not to save?

There's usually a hostile response to polemical comments alluding to the decline in users. But even if it's melodramatic, I think when people go out of their way to make comments like these it reflects something that should be taken seriously. I think most of us Firefox users are using Firefox precisely because we aren't content with Edge, Chrome, or Safari. If we wanted the behavior of those browsers, we would use those browsers instead. That's not to say they don't do anything objectively right that Firefox should imitate. But I'm just saying consistency with other browsers is not an absolute value or an end in itself. It's not really a value at all, imo. We shouldn't do anything simply for the sake of consistency. Rather, if Chrome does something that proves beneficial to the UX, we should imitate it not for the sake of consistency but for the sake of improving the UX. That choice would be equally worthwhile if the enhancement was thought up by some random bugzilla user rather than trailblazed by Chrome developers.

I also think it's worth considering adding a third option (in about:preferences) for where to save downloads. Right now you can only choose a single folder, or choose to "save as" every time. I think 1) this setting should be per-filetype, and 2) there should be a third option that means "always ask you where to save files if the default action for the file is to save without opening; but automatically save to your default download folder if the default action is to open the file with any handler." That would go a long way toward obviating the UCT dialog. But I really don't see a total replacement for the dialog, since you still don't get to choose individually whether to save the file with location choice; or open the file after saving to default location. You're relying on handler bindings, which are usually fine but some of us download really obscure filetypes all the time.

If we can arrive at some kind of consensus on this, I would be really happy to personally maintain anything in the javascript arena that's necessary to preserve the unknown content type dialog behind an opt-in pref. I get that for the average user, the new behavior is probably preferable. But I don't think Firefox's biggest user demographic is ordinary web browser users. I think it has a disproportionately high number of "power users." So options are always more worthwhile for Firefox than for most of the other top browsers.

Comment 15

[Shane Hughes [:aminomancer]]

Also, this is a minor, ancillary issue, but I just thought I'd mention it: I and many other people use XYplorer which is basically a massively expanded file explorer substitute for windows. Unfortunately this program has a defect or limitation that really hurts the functionality of the "Show in folder" command. Irrespective of the caller, instead of opening the containing folder and selecting and scrolling to the revealed file, XYplorer just opens the containing folder and that's it. So you have to go out of your way to find the file if you want to delete it, or (now that the unknown content type dialog is gonna be removed) open it in an unusual file handler. If your Downloads folder is filling up with every file you download in Firefox, it becomes even harder.

Without the UCT dialog I'll be forced to confront that issue even more frequently. Hopefully it can be fixed by XYplorer's developer but in any case, it would be useful to have more context menu items for download items. An item whose command is equivalent to "Open with..." would be good, so you can choose the same alternative handlers you can currently choose in the UCT dialog. And an item that deletes the file would be great, even though we can't do that currently, this would make it easier to clean up the one-time opened junk that's gonna be permanently saved to the download directory. Just generally providing the same options that currently exist in the dialog would be great. Options I currently have in mind include: Open in { -brand-shorter-name }, Open in..., Open in System Viewer, Delete File, and Move File.

Comment 16

[Shane Hughes [:aminomancer]]

Also, I wonder if we can't make the Open in System Viewer label dynamic. After all, the unknown content type dialog shows the names and icons for the system handlers. Idk how slow that is, but I never used that menuitem at all until like a month or two ago when I heard about these changes. I simply didn't understand what it would do, didn't wanna click something unknown and have something unpredictable happen. The label is hard to decipher, and I can't think of any universal phrasing that would be any clearer. It would just be vastly better if that menuitem told you exactly what's gonna happen when you click it.

Comment 17

[:Gijs (he/him)]

(In reply to aminomancer from comment #14)

We appreciate the feedback but this bug is really not a good place to put it. The metabug (bug 1733587) would have been more appropriate, but even there - you would have (hopefully) realized that a lot of these things were already discussed in some of the other blockers

Just consider that you may not always want to open a file of a given type in its default handler. I download SVG files and PDF files a lot. Sometimes I want to view them in firefox; sometimes I want to edit them in VS Code or Acrobat or w/e.

You can still set those specific filetypes to show the UCT dialog using the controls in the Firefox Settings (ie set SVG or PDF files to "always ask"), and then (AFAICT) you get the behaviour your want in terms of controlling what happens on a case-by-case basis.

Moreover, when I want to save a file without opening it, generally speaking I want to choose where it's saved. But if I just want to quickly open a file, (especially if I want to open it in firefox) then I don't want to worry about where it's saved.

We just implemented this on nightly, at least for "always open with X", in bug 1738916.

For the tmp folder and deleting files that were opened, the webextensions team is considering adding an API in bug 1746880. Given that with your stated configuration (always ask me where to save files) we'll now only ask for files you're saving rather than opening, I think this mitigates the problem because opened files will end up in your preferred DL folder, and you can just clean that up periodically, whereas you would presumably save saved files in a more specific, permanent location. You could even make some subdir of /tmp your preferred dl folder yourself, and rely on the OS to clean it up.

Comment 18

[:Gijs (he/him)]

(In reply to aminomancer from comment #15)

And an item that deletes the file would be great, even though we can't do that currently

This is bug 1745624.

(In reply to aminomancer from comment #16)

Also, I wonder if we can't make the Open in System Viewer label dynamic.

Please file a new bug for this.

Comment 19

[Shane Hughes [:aminomancer]]

(In reply to :Gijs (he/him) from comment #17)
Thanks for the fast reply. If I set SVG or PDF to "always ask" (they are already set that way actually) with the improvements pref enabled, it just opens the UCT dialog. Maybe I misunderstood — isn't the UCT dialog supposed to be removed? There are so many bugs tracking these changes, I didn't see that one. The reason I posted in this one rather than any other was because the title says when we remove the "what do you want to do with this file" dialog.

The UCT dialog is the one that says "What should x do with this file?" but I could have missed something. It gives the impression that the UCT dialog is going to be removed, markup and all. So I interpreted it as signaling that, once this plan is finished, "always ask" is going to simply refer to where the file is saved, rather than what handler (if any) opens it after saving. If I'm mistaken then that definitely changes my view.

Anyway, if the UCT dialog is not being removed, then can "always ask" be set as the default behavior for unknown file types? One of my biggest concerns is that I download a huge variety of files, sometimes with no extension at all. The title for this bug should probably be changed if the UCT dialog is not being removed btw. I was aware of these changes generally and read the doc like a month or 2 ago, but didn't say much besides report a minor bug since everything else seemed good and nothing really raised my alarms until I stumbled onto this bug.

We just implemented this on nightly, at least for "always open with X", in bug 1738916.

That's great, thanks. If I have Firefox set to "always ask you where to save files" (browser.download.useDownloadDir = false) and it's not going to ask me where to save files that I choose to "always open in x," then where is it saving said files? In that bug you said "for files set up to open automatically, we should save the files to the directory pre-selected by the user (defaults to the default downloads directory, but is user-configurable)." Does that mean browser.download.dir or browser.download.lastDir? The about:preferences interface disables the download directory input, which sort of gives the impression that it's not going to be used at all. And since it's disabled, the directory can't be changed from there while useDownloadDir = false.

The sheer number of file extensions and the inability to add new file handlers via about:preferences is a problem that imo should be regarded as blocking the whole suite of changes. I didn't see any blocking bugs that address these so lmk if you think I should post these. I think there needs to be 1) an ability to arbitrarily add extensions to the table (the ability to add a comma-separated list of extensions all with the same handler would be ideal to save time), and 2) an ability to change the default behavior for unknown file types. In the other bug you said:

** There is also the case where we don't have an action set for a filetype. We deliberately don't ask for a user action anymore by default; we'll save to disk by default, and for that we need to know where you want the file to be saved (that's what "always ask you where to save files" means), so we can't realistically change that behaviour without violating people's expectations.

This troubles me because there are far more file extensions than are registered in my handlers.json file. Even if I set every known file type to "always ask," what's gonna happen when I download an unhandled file? I need it to prompt me, not immediately download the file to the default directory. Will it be possible to add entries like this?

"text/plain": { "action": 4, "ask": true, "extensions": [".*"] },
"application/octet-stream": { "action": 4, "ask": true, "extensions": [".*"] }

For the tmp folder and deleting files that were opened, the webextensions team is considering adding an API in bug 1746880. Given that with your stated configuration (always ask me where to save files) we'll now only ask for files you're saving rather than opening, I think this mitigates the problem because opened files will end up in your preferred DL folder, and you can just clean that up periodically, whereas you would presumably save saved files in a more specific, permanent location. You could even make some subdir of /tmp your preferred dl folder yourself, and rely on the OS to clean it up.

Yeah that describes my use pretty accurately. Storage sense doesn't seem to work so well on my desktop so I would probably use another directory. But do you know if there are any problems with setting Firefox's download directory to one on a different volume? Firefox is installed on the same volume as my OS, C, but I have way more room on another volume, D. Normally I'd assume this is fine, but from reading your posts in one of the other threads regarding tmp folders on other volumes, I thought it was worth asking.

Comment 20

[Shane Hughes [:aminomancer]]

(In reply to :Gijs (he/him) from comment #18)

Also, I wonder if we can't make the Open in System Viewer label dynamic.

Please file a new bug for this.

Here's bug 1747250. I can make bugs on the other issues I mentioned but I'll wait for some feedback since idk how good these ideas are outside my head

Comment 21

[:Gijs (he/him)]

(In reply to aminomancer from comment #19)

isn't the UCT dialog supposed to be removed?

Removed in the sense that users won't see it by default, because for users used to other browsers, the dialog feels like an interruption, unnecessary and confusing. We just don't want to show it by default. There are no plans to remove the dialog itself completely.

Anyway, if the UCT dialog is not being removed, then can "always ask" be set as the default behavior for unknown file types?

We don't currently have a setting for this. You could file a separate bug and we can discuss it further in such a bug. Please stop commenting on this bug though, it's really not a good place for this discussion, as I said in my previous comment.

We just implemented this on nightly, at least for "always open with X", in bug 1738916.

That's great, thanks. If I have Firefox set to "always ask you where to save files" (browser.download.useDownloadDir = false)

Please ask in the relevant bug instead of here.

The sheer number of file extensions and the inability to add new file handlers via about:preferences

For technical reasons, this can't easily be implemented there - the preferences aren't actually stored based on the file extensions, but based on mimetypes and (especially on Windows), inferring mimetypes from file extensions is not trivial, and most users will have no clue about mimetypes. I though a request to add this was already on file but I can't quickly find it - I guess you could file a new bug and mark it blocking bug 1744297. I don't think it's very important though - it makes more sense to offer the functionality in context rather than expecting users to sit down and manually add 20 different mimetypes to the preferences.

And we do support adding new filetypes in context, using the "always open with system viewer" entry. That will cause the filetype to show up in about:preferences, and you can configure it further from there.

But do you know if there are any problems with setting Firefox's download directory to one on a different volume? Firefox is installed on the same volume as my OS, C, but I have way more room on another volume, D. Normally I'd assume this is fine, but from reading your posts in one of the other threads regarding tmp folders on other volumes, I thought it was worth asking.

I wouldn't expect any issues with the improvements pref set to true, as we'll just save files to that destination immediately. It also sounds like both of these volumes are local to your machine; we've seen more issues when one of the locations was e.g. a directory on a directory server / domain controller or similar, rather than on the local machine, and they were often related to moving files from one place (your local tmp dir) to another (the remote disk), e.g. bug 1731049 - and that won't happen anymore with the improvements pref set to true, if we're not prompting you for a location to save to.