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
Both for minimized windows and if there is no anchor, we bail out from showing the panel.
However, only one of those cases currently resets the internal state flag to 'hidden'.
This patch ensures both cases do so, and for good measure ensures that if openPopup
throws (which apparently it can?) we also reset the state in that case, rather than
leaving ourselves with a permanently broken state.
Differential Revision: https://phabricator.services.mozilla.com/D136809
The delete file menuitem in the downloads context menu no longer
removes the download list item on its own, so the test needs an
explicit cleanup callback to remove the download it creates.
Differential Revision: https://phabricator.services.mozilla.com/D136577
The "Go To Download Page" menuitem in the downloads panel context menu
currently is always visible, even if the download is missing referrer
info. A download source should ideally always have referrer info,
but it's worth having a fallback so user doesn't see failures.
This patch also adds hiding for the "Copy Location" menuitem in the
unlikely event that a download is lacking a source or the source is
somehow lacking a URL. It implements a test to confirm hiding works.
I checked other downloads panel context menu tests to make sure they
aren't broken by the menuitems potentially being hidden.
This shouldn't close Bug 1723712 since we should ensure all downloads
have referrer info. This is just a stopgap in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D136457
* Having a different id for the container of download items in the download panel vs the all-downloads view (about:downloads and the library/places view) is one of the main reasons we need the %define item, to allow the same included stylesheet to apply to the different markup by virtue of the different selector produced when @item@ is expanded
* As these IDs aren't particularly descriptive, and the distinction isn't meaningful, having each list use the same id allows more direct stylesheet reuse in both places
Differential Revision: https://phabricator.services.mozilla.com/D135399
The test started to fail permanently on macOS 11 after the changes in
bug 1742530. Disable the testt until the issue can be resolved after the
holidays.
Differential Revision: https://phabricator.services.mozilla.com/D134687
Cursor up and down navigate between items and the footer, and tab navigates between the list itself, the button for the selected item, and the footer
Differential Revision: https://phabricator.services.mozilla.com/D133433
Previously, the tests were waiting for the load event, which was being emitted
for the initial about:blank. With the pref enabled, this event is no longer
propagated/fired to the content process. Instead of notifying the content
process that it needs to emit a load event for about:blank, we can instead make
the tests wait for a STATE_STOP event.
Differential Revision: https://phabricator.services.mozilla.com/D126843
As suggested by :jamie, this patch causes focus to move to the item at the top of the list whenever the download panel is shown. In the event that the download panel is opened automatically because a new download has been started, this will have the effect of always bringing the new download directly to the attention of accessibility tools (because the panel itself also receives focus).
Differential Revision: https://phabricator.services.mozilla.com/D133160
Added unit tests to verify that various file types and header configurations follow the mime preferredAction settings correctly when improvements_to_download_panel is set.
Differential Revision: https://phabricator.services.mozilla.com/D127759
Patch addresses intermittent issue with the context menu item alwaysOpenSimilarFiles for the Downloads Panel by using the content type provided by MimeService, rather than relying on download instance. Not only does this ensure that content type exists, but it happens to also have the benefit of making alwaysOpenSimilarFiles available to more file types that can be supported. browser_downloads_panel_context_menu.js was modified to register mimeInfo and add more test cases for visibility with application/octet-stream.
Differential Revision: https://phabricator.services.mozilla.com/D131881
Previously, the tests were waiting for the load event, which was being emitted
for the initial about:blank. With the pref enabled, this event is no longer
propagated/fired to the content process. Instead of notifying the content
process that it needs to emit a load event for about:blank, we can instead make
the tests wait for a STATE_STOP event.
Differential Revision: https://phabricator.services.mozilla.com/D126843
Previously, the tests were waiting for the load event, which was being emitted
for the initial about:blank. With the pref enabled, this event is no longer
propagated/fired to the content process. Instead of notifying the content
process that it needs to emit a load event for about:blank, we can instead make
the tests wait for a STATE_STOP event.
Differential Revision: https://phabricator.services.mozilla.com/D126843
