gNotificationBox doesn't go there anymore (it goes inside the toolbox),
so we have really no use for that.
Simplify how the devtools theme is set on the browser, so that it is set
on the root.
Differential Revision: https://phabricator.services.mozilla.com/D220769
We used to reset the dpr, user agent and touch simulation when resizing the viewport,
which could be annoying if you selected a given device to "load" a given profile
(e.g. a specific UA + touch simulation), but want a bit more room to work.
We don't do anything yet so all those would be persisted when the user resizes.
Tests are updated accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D216171
ResponsiveUI was instantiated a promise which wasn't awaited by any code,
and especially the test codepath which explicitely ignore rejections.
Differential Revision: https://phabricator.services.mozilla.com/D210902
In particular:
* Always handle meta viewport in RDM. This fixes bug 1625999 too by
making touch simulation enabled and disabled consistent.
* Restore the resolution to 1 when toggling RDM. This is just simpler,
and we're not keeping around the visual viewport offsets anyways
so...
* Deal with the change more easily, at the same point we switch
scrollbars etc.
Differential Revision: https://phabricator.services.mozilla.com/D206266
Unmounting the top level React component will help avoid trigerring React updates
when async thunk actions keep dispatching new actions after the tool is closed.
This was leading to various exceptions in many React components.
Also avoid a race condition where `responsiveFront` could be undefined when closing
RDM while it is still initializing.
Finally, ensure registering the `ResponsiveUI` immediately in `activeTabs` to prevent
race condition in openIfNeeded.
Adding some test coverage for such race condition, but can't enable this on verify.
In chaos mode, there is too many exceptions at the test teardown.
Ideally, RDM should:
* only close the RDP client and let the server restore the default value on its own.
i.e. we shouldn't do any request on closing.
* RDM close requests should wait for previous initialization request to be done.
This would avoid zillion of possible exceptions because initialization is very async
and each step may throw because of things are already being destroyed.
But this wouldn't address race condition when the tab is closed.
So RDM should probably try to have a more resilient initialization sequence as well.
Differential Revision: https://phabricator.services.mozilla.com/D197581
This patch updates the `NotificationMessage` element in `notificationbox.js` so that it extends our newer `moz-message-bar` component instead of the deprecated `message-bar` component. Many of the changes are just dealing with the implications of making things async (so that we can ensure `moz-message-bar.mjs` gets imported). I tried to break out places where I modified related code and tests into separate patches to mitigate some of the review pain here.
This patch solves a longstanding issue where we were loading `in-content/common-shared.css` in the chrome since it gets used by the `message-bar` element. It also makes some small visual changes to our infobars (slight outline, icon colors, adds a bit of spacing).
Differential Revision: https://phabricator.services.mozilla.com/D189872
This patch updates the `NotificationMessage` element in `notificationbox.js` so that it extends our newer `moz-message-bar` component instead of the deprecated `message-bar` component. Many of the changes are just dealing with the implications of making things async (so that we can ensure `moz-message-bar.mjs` gets imported). I tried to break out places where I modified related code and tests into separate patches to mitigate some of the review pain here.
This patch solves a longstanding issue where we were loading `in-content/common-shared.css` in the chrome since it gets used by the `message-bar` element. It also makes some small visual changes to our infobars (slight outline, icon colors, adds a bit of spacing).
Differential Revision: https://phabricator.services.mozilla.com/D189872
When the D195198 would be ready to land, there are a few tests that are going to be passing all or most of a11y-checks since the AccessibilityUtils would be able to automatically check focusable tabs in tablists (that were previously failing these tests), thus we need to update the manifest to remove `fail-if` notations when appropriate and update the comments in the remaining tests.
Depends on D197025
Differential Revision: https://phabricator.services.mozilla.com/D197090
The popup manager is in the parent process and the parent process may store
the last mouse cursor position which is set by a preceding test, but the
test synthesizes mouse events only in the content process. Therefore, the
parent may have unexpected state.
For solving these issues, this patch makes the test synthesize the events via
the parent process with enabling the async event dispatcher.
Then, new issue appeared. When I run this test in the verify mode, it
high-frequently failed with no mouse event logs. Therefore, this patch makes
the content process waits first `mousemove` outside the target before starting
the test.
Differential Revision: https://phabricator.services.mozilla.com/D195637
`mouseover` should be fired by `EventStateManager` when it gets `mousemove`
events at that time, `PresShell` and `EventStateManager` update their member
to dispatch `mouseout` etc later correctly. So, the test should synthesize
`mousemove` instead.
Additionally, for making it easier to debug, this patch adds event logger
too. Number of logging events are just a few so that it's not problem from
the log size point of view.
Finally, this adds a clean up code to hide the tooltip which was shown by
this test. That may help to make it stable when continuously run the test.
Differential Revision: https://phabricator.services.mozilla.com/D195636
The new focus indicator is bigger and has a better contrast, making it more accessible
than the thin dotted line we had previously.
It also includes a white box-shadow so even on our blue "active/selected" backgrounds,
the indicator is still visible (e.g. in the markup view, for a selected node, with
focus on badges / text inputs).
Finally, I tried to go over the elements of the shared components and most used
panels to adjust the outline offset when it was not visible/clipped, or when
it could be conflated with the focused element border/background.
Differential Revision: https://phabricator.services.mozilla.com/D192185
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
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/D191259
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/D190890
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 expect to be failing these tests altogether and then handle each one of them individually.
This task is to expect failing of these tests 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:
- Fail-if tests: meta bug 1848402
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D190524
Some Tier 2 accessibility checks for click events fired on controls that should be keyboard accessible were failing for this component. They were captured by testing/mochitest/tests/SimpleTest/AccessibilityUtils.js via bug 1692110. These failing tests were temporarily fail-if'ed in the directory's browser.ini file. After the ongoing accessibility improvements work is completed, we'll need to re-run a11y-checks, investigate new failures, and for confirmed bugs individual defects should be filed.
When the individual test failures are resolved and the individual bugs are closed, remove the fail-if condition for a11y_checks from the appropriate files/sections to ensure better test coverage and to avoid regressions in a11y of these components.
Depends on D189007
Differential Revision: https://phabricator.services.mozilla.com/D186405
Some Tier 2 accessibility checks for click events fired on controls that should be keyboard accessible were failing for this component. They were captured by testing/mochitest/tests/SimpleTest/AccessibilityUtils.js via bug 1692110. These failing tests were temporarily skipped in the directory's browser.ini file. After the ongoing accessibility improvements work is completed, we'll need to re-run a11y-checks, investigate new failures, and for confirmed bugs individual defects should be filed.
When the individual test failures are resolved and the individual bugs are closed, remove the fail-if condition for a11y_checks from the appropriate files/sections to ensure better test coverage and to avoid regressions in a11y of these components.
Differential Revision: https://phabricator.services.mozilla.com/D186405
This data is transient and only specific to the Editor's index react component.
There is no need to share nor persist this data in Redux,
this would avoid unecessary complexity/layers and avoid a few state updates.
Note that the target.match(:hover) was probably a poorly documented way to prevent
rending preview for token that are no longer hovered (the comment about whitespace sounds weird).
Also tweak waitForSelectedSource to also wait for CodeMirror to be updated.
Otherwise, we might try to hover tokens while CodeMirror is still udpating...
While doing that, use the L10N string instead of the final localized string.
Differential Revision: https://phabricator.services.mozilla.com/D180992
Emilio Cobos Álvarez