This is a hack for the experiment and likely not ideal for screen readers, but better than what we have. I'm reaching out to a11y folks to figure out the right long-term solution here. I'll make an effort to get that ready for the experiment too, but would like to get this landed as a backup.
Differential Revision: https://phabricator.services.mozilla.com/D194501
This is fairly gross, but basically it uses some directory manipulation to run the
bundling steps and karma tests for both browser/components/newtab and
browser/components/aboutwelcome.
It then also takes the lcov.info files generated by both test runs and
concatenates them together before zipping them up.
Bug 1866170 covers creating a try-runner.js script for
browser/components/aboutwelcome.
Differential Revision: https://phabricator.services.mozilla.com/D194443
This also re-runs npm install on browser/components/aboutwelcome to make sure everything in
package-lock.json is up-to-date.
Depends on D193122
Differential Revision: https://phabricator.services.mozilla.com/D193228
This feed is no longer in use by the main distribution of Firefox, and we're
not doing manual QA on it nor changing it. It's blocking our ability to migrate
to ESMs, so we're removing the test altogether. Someday soon, we can hopefully
remove TopStoriesFeed.jsm itself.
Depends on D193473
Differential Revision: https://phabricator.services.mozilla.com/D193488
This is a handwritten conversion of the TopSitesFeed.test.js tests to
xpcshell. Along the way, some of the tests have been dropped - specifically,
tests for pseudoprivate methods on TopSitesFeed that start with `_`.
The only exception is the Contile integration tests that call
._contile._fetchSites, as those seem fairly important to retain coverage for.
Depends on D192630
Differential Revision: https://phabricator.services.mozilla.com/D193473
This is the only element in the deck which has plain inlines inside.
Make them a block, which is more similar to what the about dialog does
too, anyways.
Differential Revision: https://phabricator.services.mozilla.com/D194604
The new side component `fxview-category-navigation` required tests after being implemented in [[https://bugzilla.mozilla.org/show_bug.cgi?id=1832668 | Bug 1832668]]
- added tests to verify clicking each `fxview-category-button` navigates to the correct view/page
- added tests to verify keyboard navigation to each `fxview-category-button` navigates to the correct view/page
- added tests to verify direct navigation updates the category from the hash accordibly
Differential Revision: https://phabricator.services.mozilla.com/D193579
The pref is being kept for now, to make it easy for QA to verify dynamic attribution when it is ready.
Depends on D192628
Differential Revision: https://phabricator.services.mozilla.com/D193799
While investigating why initial macOS attribution data had a lower attribution rate than expected I realized that one reason why this may be the case is because we're using the same file as a cache for it. This means that even if a user has paved over with a fresh install, we will pick up the previous attribution data (even if it was null).
While doing this, I think we should also accommodate having separate attribution data per channel, which should keep the data cleaner. Release, Beta, and ESR use `Firefox.app`, which makes the likelyhood of a paveover with a different channel reasonably high.
Differential Revision: https://phabricator.services.mozilla.com/D192628
* Add histogram to sessionrestore code to count how often and the number of
closed tabs that aren't saved on window close due to no open saveable tabs
* Add test coverage
Differential Revision: https://phabricator.services.mozilla.com/D193055
* Add a type=page to the top-level ViewPage instances
* Rename viewTabVisibleCallback and viewTabHiddenCallback to view*Callback and call each when selectedness or visiblity changes
* Ensure active view/pages are always properly initialized during page load and category switching
* Add a test to verify no mutations happen when tabs change while firefox view is inactive
* Fix tests to better account for loading and readiness sequence when activating firefox view
Differential Revision: https://phabricator.services.mozilla.com/D193744
We provide `role=button` to the image control that can be clicked (with a mouse or with an assistive technology as speech-to-text/voice control) as an alternative way of the urlbar search query submission, where other ways are accessible (and are tested here too).
Setting an environment to `focusableRule: false` allows us to flag to the AccessibilityUtils that this specific button is purposefully not made focusable and its keyboard focusability should not be tested.
The previously failing accessibility checks should now be passing, thus we are also removing the `fail-if` notations that were added by bug 1854660 before the investigation in the meta bug 1854661.
Differential Revision: https://phabricator.services.mozilla.com/D193703
