Open Bug 1500000 Opened 3 years ago Updated 6 months ago

Remove DebuggerClient.release method


(DevTools :: Console, task, P3)



(Fission Milestone:Future)

Fission Milestone Future


(Reporter: ochameau, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: dt-fission-future)


(2 obsolete files)

DebuggerClient host a "release" method that is only used by the WebConsoleActor:
It seems to always be used to release a value grip actor.

While switching all client to fronts, we will no longer manipulate actor IDs and instead always call requests through their front instance.

Today this release method expects one argument, the actor ID to release.
A first step in the process of refactoring WebConsoleClient to a front could be to expose a release method on the client and ensure that all the callsites switch from:

It may not be so trivial as the callsites seem to currently pass around the actorID only and not necessarily the client.
Priority: -- → P2
Whiteboard: [boogaloo-mvp]
(I'd be happy to move this bug to another bug entry if anyone wants to celebrate here ;))
with that bug id this bug looks so... intense.
Yeah, this report should be used for a party (not for work :-)

@Alex: How much did you pay for the #?

(In reply to Jan Honza Odvarko [:Honza] from comment #3)
> @Alex: How much did you pay for the #?

11 years to create 991 bugs (
(In reply to Alexandre Poirot [:ochameau] from comment #4)
> (In reply to Jan Honza Odvarko [:Honza] from comment #3)
> > @Alex: How much did you pay for the #?
> 11 years to create 991 bugs
> (
You are awesome!

Whiteboard: [boogaloo-mvp] → dt-fission
Whiteboard: dt-fission → [boogaloo-mvp]
Whiteboard: [boogaloo-mvp]

I'm sorry if I've been misleading in the bug comment, but this change:

  • doesn't help switching to protocol JS types: we still pass around actor ID,
  • we still emit a request from the console front, in the name of of another actor.

This comment was confusing:


I actually meant to have a release method on all clients that have to be released.
And it is not clear if it is only used for ObjectActor, or if it also used from other type of actors. May be network events?
Unfortunately, doing that would most likely lead to modifying many things in the callsites (a significant one would be reps) in order to pass around the client/front instead of the actor ID. But it would be great to have a sense of how many modifications are required.

Note that protocol.js is having a special release flag on specs, which will force calling destroy method after calling the release one:

And some other fronts are using yet another pattern: one way "finalize" methods:

Finally, I should mention the RFC I opened:
It highlights that a few panels are using actor IDs instead of passing around clients/fronts. I've not been about to make progress on that topic, but we may want to ease such practice or at very least acknowledge it. The main issue is that it seems to go against protocol.js fronts and having instances of things on the client side.

Thanks for the clarification. I didn't understand the initial description correctly.

Taking another look at the codebase, we have three distinct panels that are using debuggerClient.release --> Debugger, Scratchpad, and Webconsole.


For the debugger it appears to exclusively be used from reps:


reps usage of release is limited to the objectInspector:

We set actors in two locations:,53-65

If we trace the NODE_PROPERTIES_LOADED event to where it is being set as the actor value, we come to this point:

We are operating on rdpGrips:

It is called, for example, from nodeExpand:

Which sets its actor from this function:

This is fortunately the only usage of getActor in the devtools-reps codebase.

We can just replace it with getValue

For the GETTER_INVOKED event, it is easier, we just need to pass the object client from here:

It looks like we are not even setting the actor id string there.


Within the webconsole -- ignoring reps, we have a collection of removed actors held in state:

We could modify the following to create an array of actors rather than actor strings:

Then modify this line to release the actors:

We have a releaseObject method that does not seem to be used anywhere as well:


Scratchpad seems to use it exclusively from the variablesview:


Like in other places, it appears that this collection only exists in order to release the actors.

These seem like large enough changes that each of these should have their own bug.

I think this is everything. Let me know if I missed something. I will break this into independent bugs.

Depends on: 1529916
Depends on: 1529917
Attachment #9044629 - Attachment is obsolete: true
Attachment #9044630 - Attachment is obsolete: true
Whiteboard: dt-fission
Priority: P2 → P3
Whiteboard: dt-fission → dt-fission-reserve

Renaming the bug so it makes more sense (I think).

Scratchpad is no more
the VariablesViewController will be removed as part of Bug 1591874 since it's not used anywhere (I think)
WebConsole won't be using DebuggerClient.release as part of Bug 1579090
I think the last consumer will be the inspector extension, which will be handled by Bug 1599432.

Depends on: 1599432, 1579090
Summary: Move DebuggerClient.release to WebConsoleClient → Remove DebuggerClient.release method

dt-fission-reserve bugs do not need to block Fission Nightly (M6).

Tracking dt-fission-reserve bugs for Fission MVP until we know whether they really need to block Fission or not.

Fission Milestone: --- → MVP
Type: enhancement → task

Moving old "dt-fission-reserve" bugs to "dt-fission-future" because they don't block Fission MVP.

Fission Milestone: MVP → Future
Whiteboard: dt-fission-reserve → dt-fission-future
You need to log in before you can comment on or make changes to this bug.