Adding `global: shared` to a ChromeUtils.importESModule call in the capture-screenshot.js server util.
Also adding a basic test for screenshots from the Browser Toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D303912
Update the implementation of `waitForDOM` to use `waitFor` instead of mutations.
Remove `waitForDOMIfNeeded` in netmonitor, which becomes the standard behavior for `waitForDOM` now.
Add meaningful logs when starting to wait and when resolving or rejecting.
Differential Revision: https://phabricator.services.mozilla.com/D294427
Update the implementation of `waitForDOM` to use `waitFor` instead of mutations.
Remove `waitForDOMIfNeeded` in netmonitor, which becomes the standard behavior for `waitForDOM` now.
Add meaningful logs when starting to wait and when resolving or rejecting.
Differential Revision: https://phabricator.services.mozilla.com/D294427
- primary / nodefaultsrc / allowscriptstoclose / forcemessagemanager
are already used as true or not present, so no behavior change.
- remote can be a regular XUL attr, but needs some consumers to change.
While at it remove the unused mozframetype attr, just use type for both
XUL and privileged iframes.
Differential Revision: https://phabricator.services.mozilla.com/D286522
- primary / nodefaultsrc / allowscriptstoclose / forcemessagemanager
are already used as true or not present, so no behavior change.
- remote can be a regular XUL attr, but needs some consumers to change.
While at it remove the unused mozframetype attr, just use type for both
XUL and privileged iframes.
Differential Revision: https://phabricator.services.mozilla.com/D286522
Since we're now avoiding unnecessary work, we were missing events in the
openInspectorSidebarTab test helper.
To fix this, we make ToolSidebar#select return a Promise that resolves once
the select is done (or directly if the panel was already selected).
Callsites of ToolSidebar#select are updated accordingly.
We also add initialized promises to both the BoxModel and LayoutView so we
can wait on those instead of waiting for specific events.
We stop emitting the `grid-panel-updated` event as it's not listened for anymore.
Differential Revision: https://phabricator.services.mozilla.com/D278942
This reverts commit d96e9bd92c.
Revert "Bug 1993543 - Change XPCOMUtils.defineLazyServiceGetter(s) calls to pass an nsIID rather than a string. r=firefox-desktop-core-reviewers ,mtigley,joschmidt,perftest-reviewers,home-newtab-reviewers,nbarrett,Gijs,sparky"
This reverts commit 024c584172.
`--test-process-updates` currently basically does two totally different things: 1) It facilitates testing applying updates via the application startup process by preventing the application from actually starting if the update isn't applied or when it is re-launched as the callback application, and 2) If `ShouldNotProcessUpdates` finds a reason not to process updates, it does nearly the opposite: it sets the env variable to represent the reason we didn't process updates and lets the application continue to launch in order for a background task to consume that value.
This did not previously cause problems because we never did any testing that resulted in finding a reason not to process updates at startup that didn't involve also involve starting a background task. But the test later in this stack needs to do exactly that, motivating this change.
So this patch will split out functionality (2) into `--test-should-not-process-updates` so that the `--test-process-updates` behavior can consistently be: only process updates, do not launch the browser.
Differential Revision: https://phabricator.services.mozilla.com/D230013
`--test-process-updates` currently basically does two totally different things: 1) It facilitates testing applying updates via the application startup process by preventing the application from actually starting if the update isn't applied or when it is re-launched as the callback application, and 2) If `ShouldNotProcessUpdates` finds a reason not to process updates, it does nearly the opposite: it sets the env variable to represent the reason we didn't process updates and lets the application continue to launch in order for a background task to consume that value.
This did not previously cause problems because we never did any testing that resulted in finding a reason not to process updates at startup that didn't involve also involve starting a background task. But the test later in this stack needs to do exactly that, motivating this change.
So this patch will split out functionality (2) into `--test-should-not-process-updates` so that the `--test-process-updates` behavior can consistently be: only process updates, do not launch the browser.
Differential Revision: https://phabricator.services.mozilla.com/D230013
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
We used to force the preferences for the new performance panel to true for the Browser Toolbox to avoid showing the old performance panel, regardless of the preferences set by the user for their regular devtools.
However, now that the old performance panel is gone, it should be fine to let users decide if they want the panel or not via the devtools Settings panel.
Also the performance panel is on by default, so it shouldn't make it more complicated to profile on clean profiles.
Differential Revision: https://phabricator.services.mozilla.com/D210148
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
Julian Descottes