With the profiler started by default during mochitests (MOZ_PROFILER_STARTUP=1),
opening the devtools performance panel reports a "recording" state, so closing
the toolbox makes ProfilerEventHandling.componentWillUnmount issue a
stopProfilerAndDiscardProfile request that races the connection teardown and
rejects. The toolbox tests don't use the profiler themselves, so they allow that
harmless rejection (see bug 2044383) and keep the profiler running. The
about:debugging profiler dialog test does drive the profiler, so it stops any
already-running profiler first via ProfilerTestUtils.assertProfilerInactive.
Differential Revision: https://phabricator.services.mozilla.com/D304133
This reverts commit b7f48700d7.
Revert "Bug 2031714 - [devtools] Implement "Local Mode" backend. r=devtools-reviewers,devtools-backward-compat-reviewers,bomsy"
This reverts commit 0f1b6c66ab.
Revert "Bug 2031714 - [devtools] Expose a flag on the TargetFront to know if the page is an error page. r=devtools-reviewers,nchevobbe"
This reverts commit 4cbb3ac689.
When any exception happens from the DevToolsProcess's JSProcessActor,
the stacktrace is lost when the exception reaches the parent process.
Manually transfer the exception payload between processes
so that RDP server can send the full stack to the client.
Using callbacks was losing async stack trace, so I moved super.sendQuery
into an inline async function to be able to use await and preserve async
stacks in case of errors.
Differential Revision: https://phabricator.services.mozilla.com/D298390
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
I found these tests which can be simplified now that there is a helper for determining whether a context menu is native.
Differential Revision: https://phabricator.services.mozilla.com/D289433
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Some tests seem to fail to open the menu with the screenshot showing a blank toolbar.
Assuming the toolbar was not rendered yet, we can try to wait for the DOM element before
interacting with it.
Differential Revision: https://phabricator.services.mozilla.com/D293439
"devtools.debugger.features.javascript-tracing" is still relevant on
other channels and fully enable the tracer (toolbox button and
keyshortcuts automatically enabled).
Otherwise the tracer is rather controlled by
"devtools.command-button-jstracer.enabled" preference, which typically
requires user's action to enable to button from the settings panel.
Differential Revision: https://phabricator.services.mozilla.com/D289229
"devtools.debugger.features.javascript-tracing" is still relevant on
other channels and fully enable the tracer (toolbox button and
keyshortcuts automatically enabled).
Otherwise the tracer is rather controlled by
"devtools.command-button-jstracer.enabled" preference, which typically
requires user's action to enable to button from the settings panel.
Differential Revision: https://phabricator.services.mozilla.com/D289229
"devtools.debugger.features.javascript-tracing" is still relevant on
other channels and fully enable the tracer (toolbox button and
keyshortcuts automatically enabled).
Otherwise the tracer is rather controlled by
"devtools.command-button-jstracer.enabled" preference, which typically
requires user's action to enable to button from the settings panel.
Differential Revision: https://phabricator.services.mozilla.com/D289229
"devtools.debugger.features.javascript-tracing" is still relevant on
other channels and fully enable the tracer (toolbox button and
keyshortcuts automatically enabled).
Otherwise the tracer is rather controlled by
"devtools.command-button-jstracer.enabled" preference, which typically
requires user's action to enable to button from the settings panel.
Differential Revision: https://phabricator.services.mozilla.com/D289229
- 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
Alexandre Poirot