On macos re-showing it without using `hidden` can cause, apparently,
extra popuphidden events. Let's do the right thing and close the popup
properly using hidePopup().
This code wasn't being hit before bug 1339380 because we relied on the
parent side to hide it, which did correctly fire the events.
Differential Revision: https://phabricator.services.mozilla.com/D106431
This fixes a number of problems:
1. The check around get_rgb_colorants was inverted. This caused us to
only continue if the colorants were wrong.
2. get_rgb_colorants can just return the Matrix instead of taking
a reference to it.
3. No tests
Differential Revision: https://phabricator.services.mozilla.com/D106463
Depends on D106002
The goal is to reduce the usage of the getToolbox(target) API.
It feels like exposing toolbox on the connector should be a more straightforward way of achieving the same thing?
Differential Revision: https://phabricator.services.mozilla.com/D106032
Depends on D105999
This patch is mostly a mechanical rewrite of:
```lang=javascript
const target = await TargetFactory.forTab(tab);
const toolbox = await gDevTools.showToolbox(target, "inspector");
```
to
```lang=javascript
const toolbox = await gDevTools.showToolboxForTab(tab, { toolId: "inspector" });
```
The main changes are:
- if the target was actually used in the test, it is now retrieved from toolbox.target
- the arguments for showToolboxForTab are using an option argument, to avoid the occasional showToolbox("inspector", null, null, null, startTime, null, reason);
I suspect that any signature rewrite mistake would have been caught on try.
There a few less mechanical changes:
- devtools/client/framework/test/browser_toolbox_screenshot_tool.js the toolId "console" was omitted because this id doesn't match any tool (author probably meant "webconsole")
- a few tests were: 1/ first creating a target, 2/ looping on tool definitions to get supported tools 3/ opening the toolbox with each supported tool. To support this I extracted a helper called `getSupportedToolIds` which opens a temporary toolbox to list all supported tool ids
- all the tests under storage/ use a single helper to start the test, which can open toolboxes for both tab targets and other targets. This made it more complicated to refactor. We could also drop this part and just refactor each test when we actually modify forTab/showToolbox to only work with descriptors
All in all the goal of this stack is to pave the way to stop handling targets when using forTab/showToolbox, and behind the scenes stop replying on targets to cache open toolboxes. We don't aim to kill all the call sites, just get them to a smaller number so that the next refactors will be easier.
Differential Revision: https://phabricator.services.mozilla.com/D106000
Depends on D105740
WPT runner can target several older versions of Firefox, so only use the new showToolboxForTab when the API is available on DevToolsShim
Differential Revision: https://phabricator.services.mozilla.com/D105743
The webplatform test runner recently added an option to open devtools during their tests.
The current implementation relies on TargetFactory::forTab and gDevTools::showToolbox.
Those methods will most likely change as we move away from targets and start using descriptors.
See previous WPT PR at https://github.com/web-platform-tests/wpt/pull/27309
Differential Revision: https://phabricator.services.mozilla.com/D105740
This change add the ability to yield the output as it is produced, by
creating a thread responsible for killing the process if it takes too
long.
This way we can loop with blocking I/O on stdout in python, while the
process is running concurrently. The loop ends when the process exit
either by itself or after being killed by the timeout.
Differential Revision: https://phabricator.services.mozilla.com/D105037
This patch is developed from D104136#3396152.
This patch creates WorkerTestUtils.webidl under dom/webidl for testing workers with internal APIs. These APIs are exposed to workers only and controlled by dom.workers.testing.enabled pref.
This patch creates a Mozilla-specific web-platform test, testing/web-platform/mozilla/test/workers/worker_timer_nesting_level.html, to test the timer nesting level implementation for workers.
To simplify the test implementation, this patch does not implement the webidl under dom/chrome-webidl/ suggested by D104136#3396152.
Depends on D104136
Differential Revision: https://phabricator.services.mozilla.com/D105332
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
As part of this, we need to detect that the currently showing notification does
not match the one what we want to display. This also fixes the case where we
show a notification for tab A, then switch to tab B which is also hanging, and
end up listing the title for tab A as hanging in the notification.
Differential Revision: https://phabricator.services.mozilla.com/D106305
If we don't do this, then just moving the mouse over a window experiencing a
slow script will cause it to show the notification. We could try to
deserialize the message inside nsContentUtils::IsMessageCriticalInputEvent, but
that seems overcomplicated compared to just adding a new message which proxies
to the original message handlers.
Differential Revision: https://phabricator.services.mozilla.com/D106016
This patch removes the wait button on the slow script warning, on the suspicion
that it is confusing to the user since it's redundant with the close button. It
also changes the text of the notification to blame the hanging tab.
Differential Revision: https://phabricator.services.mozilla.com/D106015
This is an extension of the existing implementations added by Bug
1059469.
By extension, this makes `console.log` and friends log to the MOZ_LOG
system when `browser.dom.window.dump.enabled` is true.
My immediate use case is capturing cumulative logs for the new
`--backgroundtask ...` mode that will be used to invoke maintenance
tasks when Firefox itself is not running.
This will lead to duplicate messages (from both the MOZ_LOG system and
`fputs`) when the MOZ_LOG system is not redirected but there's no
particular harm in that. In the future, we could not `fputs` when the
MOZ_LOG system will log the given message, but it seems better to
actually do the work to connect the `Log.jsm` and `ConsoleAPI.jsm`
systems to MOZ_LOG rather than continue to add work arounds.
Differential Revision: https://phabricator.services.mozilla.com/D104636
