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
This simplifies a bit the tabbrowser/tab switcher code, and makes it
work in all windows.
The WPT failures are due to bug 1780212.
Differential Revision: https://phabricator.services.mozilla.com/D151822
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
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
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
