* 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
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
* 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
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to fail-if the failing tests altogether and then handle each one of them individually.
This task is to add `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific bug 1854529
- Explore capturing click events for a11y_checks: bug 1692110
Depends on D188922
Differential Revision: https://phabricator.services.mozilla.com/D188923
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific bug 1854529
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188923
This is for bugbot needinfo'ing the triage owner, no other purpose really. The triage meeting is where I expect most of triage will happen, and this is essentially a fallback. The dates are mostly arbitrary, e.g. they will often be in the middle of a week, and some periods may be 6 or 8 days as I didn't accound for differences in how long months are. None of this is set in stone and can be changed if we wish so. I'm also open to re-joining the rotation once my other modules' triage backlog are in a better shape.
Differential Revision: https://phabricator.services.mozilla.com/D190205
* Change the signature for SessionStore.getClosedTabCount to accept either a window or options object
* Extend tests for the recently-closed-tabs menu(s)
* Add a test manifest to run the session/recently-closed tabs related extension tests with the
legacy (false) values for the all-windows and closed tabs from closed windows prefs
Differential Revision: https://phabricator.services.mozilla.com/D186400
* Move closeTab and openAndCloseTab to the helpers module and replace a couple of uses
* Move waitForBrowserState/promiseBrowserState and replace a couple of uses
Differential Revision: https://phabricator.services.mozilla.com/D187636
* Add a browser.sessionstore.closedTabsFromClosedWindows pref and consult it when building recently-closed tab lists in firefoxview-next
* Add a _resolveClosedDataSource to SessionStore which allows us to find the window state and _closedTabs given a DOMWindow, a window closedId, or a window session store Id.
* Carry window closedId and source window Id into tab items when building recently-closed tab lists in firefoxview-next. This gives us the necessary context when we need to undoClose or forget a tab item in the list.
* Add a getClosed TabCount and TabData for Closed Windows method to SessionStore
* Modify undoCloseTab and forgetClosedTab to accept source params we can resolve to window state data using _resolveClosedDataSource
Differential Revision: https://phabricator.services.mozilla.com/D185108
* We already make use of the closedId in RecentlyClosedTabsInView to re-open the tab via SS.undoCloseById so it made sense to do the same for forgetting a closed tab
* In the test setup, one of tabs is opened and closed in a different window. This gives us coverage both for the closed tab list rendering, as well as re-opening and forgeting tabs with different source windows
* Both the forget-by-closed-id methods match undoClosedById's behavior and throw if the closedId doesnt match a closed window or tab
Differential Revision: https://phabricator.services.mozilla.com/D184192
