It appears that `browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_engagement_edge_cases.js` and `browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_abandonment_tips.js` tests the mouse/touch-specific behavior: the test cases are [sending a click event somewhere on the window to test that the tooltip would, in fact, disappear or not](https://searchfox.org/mozilla-central/source/browser/components/urlbar/tests/engagementTelemetry/browser/browser_glean_telemetry_abandonment_tips.js#61) (depending on the test case), while there are other ways to dismiss the tooltip that are accessible (i.e. by pressing `Esc` key, testing which is included in one of the test cases).
Similarly, `browser/components/urlbar/tests/browser/browser_view_selectionByMouse.js` sends a `mouseup` events to the `<html:body>` to dismiss the url bar with a mouse-specific tests.
These clicks are not expected or do not have to be done by a keyboard-only user and it does not have to confirm the keyboard focusability as part of the accessibility of these elements.
We adding an exception from a11y_checks for these clicks, because the clicks are testing mouse-specific behavior where keyboard accessible alternative is available and is tested, and we removing the `fail-if` notation that was added by bug 1854660 before the investigation in the meta bug 1854661.
Differential Revision: https://phabricator.services.mozilla.com/D193699
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
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
With the AccessibilityUtils tests updated in D193591 to pass a11y_checks for for keyboard focusable URL bar's `.searchbar-engine-one-off-item` buttons and `.urlbarView-row-inner` results options that are purposefully made focusable with arrow keys only (instead of a Tab that would create more tiring, cumbersome experience navigating Awesomebar for keyboard-only users), we could now remove the `fail-if` notations from a series of tests that were previously failing. Also, there are 12 tests that would also be affected, but they have other elements that are throwing warning or failing a11y_checks besides the one-off controls, thus we'd be keeping them to expect to fail until these items are resolved separately.
These tests were `fail-if`ed by bug 1854660 and bug 1854528, before the investigation in the meta bug 1854661 and bug 1854529.
Differential Revision: https://phabricator.services.mozilla.com/D193849
We had to skip-if those tests that were crashing during a11y_checks and since the bug 1849230 is resolved now these test can be re-enabled (whenever possible). Two tests have also been failing intermittently, thus they are remaining skipped, but the comment is updated to remove the mention of the crash.
Differential Revision: https://phabricator.services.mozilla.com/D193230
There are some a11y_checks that are intermittently failing on Autoland and pass on Try and vice versa. Also, a couple of tests are crashing while performing a11y_checks, thus they are to be skipped while we continue the investigation into each of them.
Related bugs:
- Fail-if tests: meta bug 1848402
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D192086
This modifies tests to use the server. There are a few important points to call
out:
This means tests are now using the real Rust component, and we need to make sure
the test RS data is valid and matches what Rust expects. For example, I had to
add `icon` properties to suggestions and set the `advertiser` to "Wikipedia" for
non-sponsored suggestions. Otherwise Rust hits an error on ingest. I also
removed some test cases because they tested behaviors that are impossible with
Rust, for example Pocket keywords that are duplicated in the high- and
low-confidence arrays.
We need to be careful to wait until Suggest is done syncing from remote settings
regardless of whether it's using the JS or Rust backend. I added a way to force
the backends to sync. That way, tests can force a sync, wait for it to finish,
and be sure that all sync activity is done.
A common pattern in tests is to call `ensureQuickSuggestInit()` and then set
Suggest-related prefs (or vice versa). This is a little problematic because both
`ensureQuickSuggestInit()` and setting prefs can cause Suggest to start a sync.
It's more problematic now that we're not mocking remote settings or Rust. So I
combined the two by adding a `prefs` param to `ensureQuickSuggestInit()`. That
way, tests can be sure that all syncing is done once that function returns.
Depends on D192037, D192124
Differential Revision: https://phabricator.services.mozilla.com/D192038
This implements a remote settings server for tests. Unfortunately there doesn't
seem to be a general-purpose implementation already in the tree.
In part 2, I'll update tests so they use it.
Differential Revision: https://phabricator.services.mozilla.com/D192037
