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
The issue is that some calls to JSProcess Actor's would throw when trying to reach
content processes that get destroyed while DevTools are opening.
We have to reach out all the content processes as navigations may spawn
document in a process other than the currently's debugged tab's process.
We should ignore these failures. There isn't any explicit flag on DOM Process object
to identify destroyed processes, but `canSend` is a good fallback.
Differential Revision: https://phabricator.services.mozilla.com/D212118
The issue is that some calls to JSProcess Actor's would throw when trying to reach
content processes that get destroyed while DevTools are opening.
We have to reach out all the content processes as navigations may spawn
document in a process other than the currently's debugged tab's process.
We should ignore these failures. There isn't any explicit flag on DOM Process object
to identify destroyed processes, but `canSend` is a good fallback.
Differential Revision: https://phabricator.services.mozilla.com/D212118
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
This should help connect preferences to server's target configurations.
Once we get rid of thread's actor attach sequence, we may be able to also fold the getThreadOptions's preferences into this new system.
Differential Revision: https://phabricator.services.mozilla.com/D202277
Some workers running in the parent process might be initializating or destroying
and their target front won't be fully populated.
This test is brittle as it interact with any firefox parent process worker.
As we don't control them from the test they may be in arbitrary state.
Differential Revision: https://phabricator.services.mozilla.com/D197092
For some reason, the debugger has a different behavior the second time it opens
compared to its very first opening. So that distinct React elements are instantiated
and are then reported as leaks...
Differential Revision: https://phabricator.services.mozilla.com/D196191
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
Improves the logic to always insert stylesheets as link elements regardless of
whether it is into a html document or not. In order for the ordering to be
correct the insertion must occur after existing link elements in the document
have been parsed so the `theme-switching.js` script must always be loaded after
link elements. The storage client appears to be the only existing document where
that wasn't already the case.
Differential Revision: https://phabricator.services.mozilla.com/D190797
Improves the logic to always insert stylesheets as link elements regardless of
whether it is into a html document or not. In order for the ordering to be
correct the insertion must occur after existing link elements in the document
have been parsed so the `theme-switching.js` script must always be loaded after
link elements. The storage client appears to be the only existing document where
that wasn't already the case.
Differential Revision: https://phabricator.services.mozilla.com/D190797
There are two main types of crashes that are tracked separately:
1. `application crashed [@ mozilla::detail::InvalidArrayIndex_CRASH]` that is tracked in bug 1849230
2. `application crashed [@ operator==<mozilla::a11y::LocalAccessible, mozilla::a11y::LocalAccessible>]` that is tracked in bug 1849179
Skipping the tests that have crashed on Try more than once during the bug 1849021 work until the intermittent issues are resolved.
Depends on D186405
Differential Revision: https://phabricator.services.mozilla.com/D190139
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
There are two main types of crashes that are tracked separately:
1. `application crashed [@ mozilla::detail::InvalidArrayIndex_CRASH]` that is tracked in bug 1849230
2. `application crashed [@ operator==<mozilla::a11y::LocalAccessible, mozilla::a11y::LocalAccessible>]` that is tracked in bug 1849179
Skipping the tests that have crashed on Try more than once during the bug 1849021 work until the intermittent issues are resolved.
Depends on D186405
Differential Revision: https://phabricator.services.mozilla.com/D190139
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
Emilio Cobos Álvarez