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 "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
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
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
This addresses a few things:
- it doesn't really make sense to have 2 different badge implementations
for the library and the panel. Just use the panel one for the library.
- remove the old badge itself
- remove a bunch of old CSS to do with the old badge
- rename the 'new' badge now it isn't new anymore
- share the badge styling between the 'all downloads' view (about:downloads
and the library) and the downloads panel
- use the downloadMainArea for hover styling of the non-button bit, and
update the JS to set the downloadHoveringButton class appropriately for
this new reality.
- tighten up hover styles so we don't get a weird double hover for the
blocked download case
- tighten up margins of the button, badge and progress meter (see also
https://bugzilla.mozilla.org/show_bug.cgi?id=1725837). This is also
helped by the fact that the renaming means we now properly hide the
badge image when the download isn't blocked; the CSS at
https://searchfox.org/mozilla-central/rev/a1ab92e0b16631465a946b300493e75be0eacc37/browser/components/downloads/content/downloads.css#44-47
didn't apply to this badge pre-patch.
Differential Revision: https://phabricator.services.mozilla.com/D123169
As a bonus, this is net code removal.
I spent a long time on a test, but ultimately it seems that in an automated test the
conditions in real use don't appear (ie the mouseout event doesn't happen) unless
manually fired from the test, which seems like it isn't worth it.
Differential Revision: https://phabricator.services.mozilla.com/D113431
Show save dialogue
***
Automaticly show Panel On Block
***
Keep Open/Save Dialogue with open panel
***
Keep User choise in downloadsView
***
Add Unblock option to Unblock panel
***
lint
***
add test
Differential Revision: https://phabricator.services.mozilla.com/D96448
Show save dialogue
***
Automaticly show Panel On Block
***
Keep Open/Save Dialogue with open panel
***
Keep User choise in downloadsView
***
Add Unblock option to Unblock panel
***
lint
***
add test
Differential Revision: https://phabricator.services.mozilla.com/D96448
