The check is not fully correct as per the comment (bug 779598 removed
the preserve-3d check).
I went through the relevant bugs and nothing misbehaves with this
afaict.
Differential Revision: https://phabricator.services.mozilla.com/D199609
In the previous patch I called InitializeMacApp earlier. This caused performance
regressions. We need to initialize it before the migration wizard in order for it
to be accessible, so I added a call just before the Migrate method.
Note: calling InitializeMacApp more than once does nothing.
Differential Revision: https://phabricator.services.mozilla.com/D199786
Since pointerlockchange events will be silently dropped on an inactive
browsingContext, it is useful to wait for the browsingContext to become
active in addFullscreenChangeContinuation. The most likely behavior of
the callback is to trigger a pointerlockchange event, so we should
guarantee that we're ready for it, and error if we know that we'll fail.
Differential Revision: https://phabricator.services.mozilla.com/D199788
Include `scrollbutton-down` and `scrollbutton-up` toolbarbuttons in the `isKeyboardFocusableBrowserToolbarButton` check to avoid failing [isKeyboardFocusable a11y_check](https://searchfox.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/AccessibilityUtils.js#450) for them. These toolbar buttons are not expected to be focusable with keyboard because the keyboard-only user would actually scroll tabs left/right in the toolbar while trying to navigate to them which would make them redundant in the focus order.
Depends on D197335
Differential Revision: https://phabricator.services.mozilla.com/D197713
`searchbar-search-button` includes two `<image>` elements, one of which is aimed to visually communicate that this `overlay` image could expand/collapse the search autosuggest list. This `<hbox>` that has an accessible name but lacks an appropriate interactive role and state, because it functions as a button (not focusable with keyboard because the alternative - `Escape` key - exists and works to collapse the autosuggest list and we do not want to create an additional tab stop for keyboard-only users). This would prevent users of speech-to-text/Voice Control from being able to send a click to it by calling its label and screen reader users and users of other assistive technology would not be able to get to this control via shortcuts like a list of controls, etc.
This issue is similar to the `Go` button on the URL bar resolved in the bug 1864962 and to the `Submit search` button tracked in bug 1871596
To activate the searchbar next to the URL Bar that includes this go button: `about:preferences` > `Search` > `Search Bar` > select `Add search bar in toolbar`.
Depends on D199504
Differential Revision: https://phabricator.services.mozilla.com/D197335
This would allow browser test like `accessible/tests/browser/tree/browser_searchbar.js` to test accessible roles in the Accessibility tree for buttons with `aria-haspopup` attributes.
Depends on D199394
Differential Revision: https://phabricator.services.mozilla.com/D199504
Since, in the bug 1875654, we have updated the `browser-toolbarKeyNav.js` to ensure the keyboard navigation handler accounts for intentionally non-focusable controls when calculating focus behavior of toolbar buttons.
We are updating the URL Bar `Go` button markup to ensure it won't be included in the keyboard focus order (since a keyboard-only user could press `Enter` to achieve the same submission of their search query), as well as associated mochitests since we do not need to separately set an environment to skip the focus check. This is because we also fine-tune the AccessibilityUtils' `isKeyboardFocusableBrowserToolbarButton()` check to ensure more through confirmation of the image button in question.
Differential Revision: https://phabricator.services.mozilla.com/D199394
This exchanges `winapi` functions/types for equivalent `windows-sys` ones. Some basic types (e.g.
`PBOOL`) don't exist in `windows-sys`, and I added `type` items for them (though those could be
removed and the types inlined; that's what `windows-sys` does itself).
The `psapi` library needed to be added for GetModuleFileNameExW; I guess previously `winapi` was
linking it?
Almost all manual definitions of types (`winapi::ENUM!` and `winapi::STRUCT!`) were no longer needed
because `windows-sys` has them. Only the version of `RTL_USER_PROCESS_PARAMETERS` with undocumented
fields was still needed.
Differential Revision: https://phabricator.services.mozilla.com/D199111
Previous patches in the stack had used asroutermodules as an alias to get
at browser/components/asrouter/modules. This patch, however, required adding
an alias to get at asrouter/content-src/components, so asroutermodules was
replaced with a top-level asrouter alias.
Differential Revision: https://phabricator.services.mozilla.com/D198881
This requires a change to aboutwelcome's karma webpack packaging so that
resources loaded at "resource:///modules/asrouter/X.sys.mjs" get remapped
to "asroutermodules/X.sys.mjs".
Differential Revision: https://phabricator.services.mozilla.com/D198878
This causes the mocha/chai tests for newtab to break because of the failure
to import the ASRouterNewTabHook module from within ASRouterParent. This will
get fixed in the next patch in the stack which moves the actors.
Differential Revision: https://phabricator.services.mozilla.com/D198871
