1566851 - Convert `target.threadFront` to `target.getFront("thread")`

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[Alexandre Poirot [:ochameau]]

ThreadFront and WebConsoleFront are the only two one left having a special codepath in TargetMixin.
These two are special as there is synchronous attributes on the target object, activeConsole and threadFront, in order to get a reference to them.
Their instantiation is also special as you have to call target.attachConsole as well as target.attachThread in order to create these attributes.
There is some discrepancies between these two and all the other one which are created on-demand on the first call to target.getFront:

• target.attachConsole is called in middle of target.attach, manually, from each target subclasses:
  https://searchfox.org/mozilla-central/search?q=this.attachConsole(&case=false&regexp=false&path=shared%2Ffronts%2Ftargets%2F

• target.attachThread is called from many various callsites:
  https://searchfox.org/mozilla-central/search?q=.attachThread(&case=false&regexp=false&path=
  But the two important callsites if we ignore tests are:

  • the toolbox open function
    https://searchfox.org/mozilla-central/rev/22b330ecb3edba1536a54887060cbdd09db21c59/devtools/client/framework/toolbox.js#638-647
  • the debugger updateWorkers
    https://searchfox.org/mozilla-central/source/devtools/client/debugger/src/client/firefox/workers.js#35-41

In any case, we should distinguish the two following operation:

• retrieving the front: target.getFront("xxx")
• "attaching it": console.startListeners([]) and thread.attach(options)

A first iteration would be to do this split and use target.getFront everywhere.
Then, we could possibly iterate in order to cleanup the various way we are "attaching" these actors.

Why is this important to switch to getFront?

• enable target.onFront to work with these two fronts. Fission is going to force us to support more than one front instance. In a near future, we are going to replace a few calls to getFront into calls to onFront. This step will be easier if we are already using getFront.
• having a unified codebase. There is no reason but historical ones to have specifics around these two fronts.

Comment 1

[Alexandre Poirot [:ochameau]]

A quick update about this bug. Comment 0 is still relevant but let's go through the still existing usages of target.threadFront and target.attachThread.

• target.threadFront is still used in a couple of places
  https://searchfox.org/mozilla-central/search?q=target.threadFront&case=false&regexp=false&path=
  Whereas we should be using target.getFront("thread"). Everywhere, also in thread so that we can remove the threadFront attribute from the TargetMixin class:
  https://searchfox.org/mozilla-central/source/devtools/shared/fronts/targets/target-mixin.js#
  TargetMixin would also use getFront or getCachedFront to query for the thread front.

• target.attachThread() is having two callsites:
  https://searchfox.org/mozilla-central/search?q=.attachThread(&case=false&regexp=false&path=
  Ideally, only the toolbox would attach the thread so breakpoint or debugger startement work even if the Debugger panel isn't opened. But I imagine such work would require a dedicated bug and some more analysis.

Comment 2

[Chris Peterson [:cpeterson]]

Tracking Fission DevTools bugs for Fission Nightly (M6)

Comment 3

[Chris Peterson [:cpeterson]]

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

Comment 4

[Chris Peterson [:cpeterson]]

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

Comment 5

[Chris Peterson [:cpeterson]]

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