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
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
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
