Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
Long ago, the menu panel in was a customizable area that users could drag things into.
That changed back around 2017 in bug 1354117 when the Photon redesign was built. The
menu panel become a static menu, but we also made it possible to permanently move things
to the overflow panel of the nav-bar.
It looks like we never updated the area type constant from referring to the old menu panel
though, so it's "TYPE_MENU_PANEL", and registering a node for it happens with
registerMenuPanel. This patch changes to constant to TYPE_PANEL and updates the registration
method to registerPanelNode.
I a check around the codebase as well as GitHub looking to see if there were any
system add-ons or experimental WebExtensions that rely on TYPE_MENU_PANEL / registerMenuPanel,
but I couldn't find any.
Differential Revision: https://phabricator.services.mozilla.com/D161078
This patch modifies DownloadSpamProtection and DownloadIntegration so
that each window will track blocked spam downloads separately. (Which
shouldn't affect permissions.) When a download is blocked, the helper
app service dispatches a notification, passing the relevant browsing
context and URL to DownloadIntegration. Then it passes the window and
URL to the singleton DownloadSpamProtection. That maps all the windows
to objects that carry the spam download objects. This allows us to only
show blocked spam downloads in the downloads panel of the window from
which they were triggered.
Differential Revision: https://phabricator.services.mozilla.com/D148092
I have fixed the underlying XPConnect issue, so these workarounds should
no longer be needed.
There are also two more in browser/base/content/browser-siteProtections.js
that I have not fixed.
Differential Revision: https://phabricator.services.mozilla.com/D158158
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
