This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.ChromeUtils.)/d" $(git grep -l 'require("ChromeUtils")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .ChromeUtils./d" $(git grep -l 'loader.lazyRequireGetter(this, "ChromeUtils"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js + manual eslint fixes
Differential Revision: https://phabricator.services.mozilla.com/D156402
The Front.watchFronts API is sparsly used whereas we always instantiate
two EventEmitter and emit two events for all the Fronts.
We can avoid doing that unless we start using this API only on a couple of fronts.
Differential Revision: https://phabricator.services.mozilla.com/D153957
Inspector fronts initialization is still pending while we navigate away to another top target.
Leading to various possible exception in protocol.js.
I'm adding a set of new explicit exception in order to help debugging all these cases.
Differential Revision: https://phabricator.services.mozilla.com/D123441
Previous `purgeRequestForDestroy` method was only rejecting all pending requests.
The new `syncFrontDestroy` allows to fully destroy the front, including
unregistering it/unmanage it. So that if we receive a packet from a brand new
actor, with the same prefix and actor ID, DevToolsClient.getFront doesn't return
the old destroyed front.
This issue was making pending requests that were never resolved.
Differential Revision: https://phabricator.services.mozilla.com/D94718
Depends on D93029
Emitting "forwardingCancelled" will result in purging requests on the target front, which almost equates to destroying the front.
We should emit the "tabDetached" event before that to avoid emitting events on already destroyed fronts.
Differential Revision: https://phabricator.services.mozilla.com/D93030
Emitting "forwardingCancelled" will result in purging requests on the target front, which almost equates to destroying the front.
We should emit the "tabDetached" event before that to avoid emitting events on already destroyed fronts.
Differential Revision: https://phabricator.services.mozilla.com/D93029
In fronts there's a parentFront property that maintain the link
between a front and its parent.
But Pool isn't using it, and retrieve the parent through poolFor,
which can be a bit slow depending the number of pools and their size.
This patch makes Fronts override the Pool#parent method to retrive the
parent from the parentFront property.
Differential Revision: https://phabricator.services.mozilla.com/D64921
Depends on D62893
The issue here is that we are trying to destroy the workers-listener after the target was destroyed,
and calling unwatchFront on a destroyed Front throws.
Most of the fronts monitored in workers-listener are handled by the watchFront API, so properly adding
onDestroyed handlers fixes some issues. However the rootFront cannot be handled with a similar pattern
at the moment.
In general, I think making watchFront/unwatchFront safer to call makes sense, but I could also check
if the rootFront is already destroyed in workers-listener's destroy
Differential Revision: https://phabricator.services.mozilla.com/D62894
You can listen for fronts creation via `parentFront.onFront(typeName, callback)`.
For now, we were calling `callback` before we pass the `form` to Front.
This leads to empty attributes as the Front doesn't have access to any data.
Differential Revision: https://phabricator.services.mozilla.com/D49261
We weren't using the shared defer function because
at some point it was still using Promise.jsm,
which is slow.
But since Bug 1388054, it's not using Promise.jsm anymore,
so we can use the shared function.
We take this as an opportunity to clean up
the shared defer file comments.
Differential Revision: https://phabricator.services.mozilla.com/D47739
Dave Townsend