Open Bug 1529741 Opened 5 years ago Updated 2 years ago

Remove lazy actors on the backend side in favor a getFront to call an explicit RDP request to retrieve fronts on-demand

Categories

(DevTools :: Framework, enhancement, P3)

enhancement

Tracking

(Fission Milestone:Future)

Fission Milestone Future

People

(Reporter: ochameau, Unassigned)

References

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

Details

(Whiteboard: dt-fission-future)

Attachments

(2 files)

Global and target scoped actors are currently very special:

  • They are "referenced" early within RootActor.{getRoot|listTabs|getTab}
  • These methods only returns actor ID and no form
  • They are really instantiated only when the very first request for the actor ID is received

This is all designed to be able to:

  • know which global and target actors are available
  • instantiate the actor lazily, only once we interact with them

The side effects are:

  • there is a lot of complexity on both client and server in order to only manipulate actor ID until we end up instantiating a real Front and a real Actor
  • these fronts and actors are special and don't support "form"

Thanks to the recent refactorings related to fission, these actors are now all retrieved either via RootFront.getFront and Target.getFront. These two getFront methods are asynchronous and so they could be replaced by an RDP request, fetching a front like any protocol.js method.

For example, Inspector is retrieving a Walker Front via InspectorFront.getWalker:
https://searchfox.org/mozilla-central/source/devtools/shared/specs/inspector.js#364,371

The only complexity here is related to:

  • backward compatibility. This requires new request on the server and so this new code would only work with recent servers. It may be worth landing as the code on the client side may be really easy to write and would help getting rid of lots of complexity on the server side right away.
  • protocol.js types limitation. Such getFront method could return multiple types of Fronts/Actors and the current type system do not support that. It would force typing the returned value as JSON and manually instantiating the Front.
Severity: normal → enhancement
Priority: -- → P2
Priority: P2 → P3
Whiteboard: dt-fission → dt-fission-reserve

I'm attaching the WIP patches so that they aren't lost.
try is still quite orange, mostly because of the second patch.

Tracking Fission DevTools bugs for Fission Nightly (M6)

Fission Milestone: --- → M6
Depends on: 1619642

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

Fission Milestone: M6 → ---

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

Fission Milestone: --- → MVP

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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: