I think this test may have failed in sequence because of another test
setting the pref that the test currently takes for granted. So, enable
the alwaysOpenPanel pref before waiting for the panel to open.
Differential Revision: https://phabricator.services.mozilla.com/D145287
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
In pdf.js, files are saved thanks to a blob but the original URL is lost.
Consequently, the download panel doesn't contain any information about the
origins of a saved pdf.
The saveURL, internalSave and nsITransfer.init functions has now a parameter for this originalURL.
Differential Revision: https://phabricator.services.mozilla.com/D147651
My previous patch for bug 1755570 contained an oversight that caused
problems when deleting history downloads' target files. This patch just
adds a minimal data removal method to the history download prototype,
so the DownloadElementShell methods can execute without exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D145279
My previous patch for bug 1755570 contained an oversight that caused
problems when deleting history downloads' target files. This patch just
adds a minimal data removal method to the history download prototype,
so the DownloadElementShell methods can execute without exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D145279
My previous patch for bug 1755570 contained an oversight that caused
problems when deleting history downloads' target files. This patch just
adds a minimal data removal method to the history download prototype,
so the DownloadElementShell methods can execute without exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D145279
This patch adds a new menuitem to the toolbar context menu that
functions analogously to the downloads button auto-hide menuitem.
It's visible when the context menu is opened on the downloads button,
and hidden otherwise. It toggles browser.download.alwaysOpenPanel.
Also add some tests to make sure it's showing in the correct conditions
and having the correct effect in practice. While we're at it, make some
slight simplifications of related tests.
Differential Revision: https://phabricator.services.mozilla.com/D145284
This is a medium sized patch to legacy download construction. It takes
advantage of the new property added in Bug 1762033 to prevent the
downloads panel from being automatically shown when a download is added
after an interaction with the unknown content type dialog or the file
picker dialog. I chose to not do the same for failed transfers since I
thought it might serve some use, but that might be wrong. I don't know
if there's a way to test the dialog that appears when you download an
executable without going through the same path I adjusted with the
patch. It seems like it's covered but I could be wrong. Also add a test
to cover these changes from the bottom up. Thanks and apologies for my
sloppy C++, though I'm sure I'll learn a lot more from the review 😅
Differential Revision: https://phabricator.services.mozilla.com/D145312
This patch adds a new menuitem to the toolbar context menu that
functions analogously to the downloads button auto-hide menuitem.
It's visible when the context menu is opened on the downloads button,
and hidden otherwise. It toggles browser.download.alwaysOpenPanel.
Also add some tests to make sure it's showing in the correct conditions
and having the correct effect in practice. While we're at it, make some
slight simplifications of related tests.
Differential Revision: https://phabricator.services.mozilla.com/D145284
Add a property `openDownloadsListOnStart` to the download object
prototype. It is true by default. When passed a false value, it will
prevent the usual behavior of opening the downloads panel when the
download starts. This will allow some (forthcoming) internal code in the
WebExtensions API to prevent showing the downloads panel when a download
is created without any user input (see bug 1759231 for details).
Differential Revision: https://phabricator.services.mozilla.com/D142503
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
Without this, changing to add_setup in individual test files causes the tasks to be reordered, which causes tests to fail.
I also had to adjust an enterprise policy test that was expecting setup tests to run inbetween tasks.
Differential Revision: https://phabricator.services.mozilla.com/D142457
Add a new property to downloads such that downloaded files deleted from within
Firefox (currently just by the context menu item) are marked "File deleted"
instead of "File moved or missing" (this adds a new translation). Also refactor
downloadsCmd_deleteFile and downloadsCmd_cancel to clean up some related issues.
Add a new download history metadata property so that Firefox can persist this
"File deleted" state between sessions.
This should resolve bug 1755570 as well as bug 1755728. Bug 1755729 is a
separate issue, more like an enhancement, because missing/moved downloads have
never allowed resume/retry. They couldn't be resumed as they were stopped, not
paused. They could conceivably be retried but this would be adding a whole lot
of new core download logic, since the target and saver are in a very different
state for a stopped download with a deleted file than what they'd be if the
download was merely canceled.
So, this patch won't give the user an opportunity to resume/retry deleted
downloads. Previously we had a problem where we made it look like you could
retry a download if you used the "delete file" command while the download was in
progress. This patch will make sure that using the "delete file" command
actually finalizes the download. So it will just fix the immediate problem where
some menuitems and buttons simply don't work in edge cases. A later patch can
implement a new affordance that will allow "retrying" downloads that were
already downloaded/interrupted and deleted, whether from within Firefox or not.
Differential Revision: https://phabricator.services.mozilla.com/D139356
