Bugzilla

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. When you finally choose "Open with x" or "Save file" you'll see it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. In the meantime you can confirm there is no part file in your ~/Downloads directory. When you finally choose "Open with x" or "Save file" you'll see it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. In the meantime you can confirm there is no part file in your ~/Downloads directory. At least for me on Windows 10, during this time there is a .part file in the Temp folder. It won't move to ~/Downloads unless I choose "Save file" from this dialog.

When you finally choose "Open with x" or "Save file" you'll see it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. In the meantime you can confirm there is no part file in your ~/Downloads directory. At least for me on Windows 10, during this time there is a .part file (0 bytes) in the Temp folder corresponding to the download stream. It won't move to ~/Downloads unless I choose "Save file" from this dialog.

When you finally choose "Open with x" or "Save file" you'll see it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. In the meantime you can confirm there is no part file in your ~/Downloads directory. At least for me on Windows 10, during this time there is a .part file in the Temp folder corresponding to the download stream. It's 0 bytes during the download and then, when it's finally finished downloading, you'll see it reach the full file size. It won't move to ~/Downloads unless I choose "Save file" from this dialog.

When you finally choose "Open with x" or "Save file" you'll see it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. In the meantime you can confirm there is no part file in your ~/Downloads directory. At least for me on Windows 10, during this time there is a .part file in the Temp folder corresponding to the download stream. It's 0 bytes during the download and then, when it's finally finished downloading, you'll see it reach the full file size. It won't move to ~/Downloads unless I choose "Save file" from this dialog.

When you finally choose "Open with x" or "Save file" you'll see it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

Edit: I just tested it with [this file](https://vimm.net/vault/7818) which is about a gigabyte. You don't need to use an old version of Firefox to test this, just disabling the pref `browser.download.improvements_to_download_panel` will enable the old code path. You can see where it's referenced in the source code I linked above. Another difference is that there's no way to avoid the unknown content type dialog in old versions.

But anyway, if the file's content type (7z archive) is set to "Always ask" then Firefox will open an unknown content type dialog as soon as the download begins. So at this moment you can check the Temp folder and see there's a .part file there, and there isn't a .part file in your ~/Downloads directory. And if you just wait around (leaving the dialog open) for a while, eventually you'll see the download finished because the .part file's size will jump from 0B to 1GB. Then you know the file has been written to the Temp directory. And you can then choose "Save file" in the dialog, and you'll see the file disappear and reappear in ~/Downloads. And now you can understand why it's a problem if ~/Downloads is on a volume with less storage capacity.

(In reply to Martin from comment #13)
> It's worked this way since I can remember.

Well you can easily set it to "Always ask" and then download a giant file and when the dialog comes up asking if you want to open or save, just do nothing for 20 minutes. In the meantime you can confirm there is no part file in your ~/Downloads directory. At least for me on Windows 10, during this time there is a .part file in the Temp folder corresponding to the download stream. It's 0 bytes during the download and then, when it's finally finished downloading, you'll see it reach the full file size. It won't move to ~/Downloads unless I choose "Save file" from this dialog.

When you finally choose "Open with x" or "Save file" you'll see in Firefox's downloads panel it immediately finishes the download, because it's been downloading the stream in the background while the dialog was open. I'm not a C++ expert so I don't know all the nuances of this background download thing, but I trust what others have told me. If you want to investigate for yourself, [this is the source code](https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp).

Edit: I just tested it with [this file](https://vimm.net/vault/7818) which is about a gigabyte. You don't need to use an old version of Firefox to test this, just disabling the pref `browser.download.improvements_to_download_panel` will enable the old code path. You can see where it's referenced in the source code I linked above. Another difference is that there's no way to avoid the unknown content type dialog in old versions.

But anyway, if the file's content type (7z archive) is set to "Always ask" then Firefox will open an unknown content type dialog as soon as the download begins. So at this moment you can check the Temp folder and see there's a .part file there, and there isn't a .part file in your ~/Downloads directory. And if you just wait around (leaving the dialog open) for a while, eventually you'll see the download finished because the .part file's size will jump from 0B to 1GB. Then you know the file has been written to the Temp directory. And you can then choose "Save file" in the dialog, and you'll see the file disappear and reappear in ~/Downloads. And now you can understand why it's a problem if ~/Downloads is on a volume with less storage capacity.