When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
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
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
* 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 edit-related commands are special because they are handled by ShortcutKeyDefinitions.cpp yet we have duplicate keys because we want the menu disabled state to update properly, so we don't fire command events on those.
Differential Revision: https://phabricator.services.mozilla.com/D135157
The edit-related commands are special because they are handled by ShortcutKeyDefinitions.cpp yet we have duplicate keys because we want the menu disabled state to update properly, so we don't fire command events on those.
Differential Revision: https://phabricator.services.mozilla.com/D135157
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
