1574348 - Workers should be nested below Processes

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[Jason Laster [:jlast]]

It would be nice if we had a sense of hierarchy in how we show targets in the Threads pane and Sources pane.

The immediate use case is nesting workers below processes, which would help clarify the UI if many tabs have debuggers. Nesting will also be helpful in more complicated sites with many remote frames.

I'm also curious about how we might go about implementing this. From a redux perspective, all I think we need is for a thread to have a parent field, which would have a parent thread's ID. Do you think this could be achieved by looking at either the target or thread front's parent field?

Comment 1

[Jason Laster [:jlast]]

Attachment: Screen Shot 2019-08-15 at 4.53.48 PM.png

Comment 2

[Yulia Startsev [:yulia]]

I think the right approach is using the targetFront field. Every front has this, so you would be able to identify which target a given front belongs to. However, this won't represent the full tree, just a flat tree from wherever you called listRemoteFrames. For example, if you have a tab, and you call listRemoteFrames on it, you would have all of the frames listed below it, even if one frame is nested in another one. You would still be able to get, for example, workers from the remote frame and list those.

To get the nested frames listed as nested, we could have something to identify the parent browsing context? I think this is getting pretty deep into ui requirements though.

Comment 3

[Alexandre Poirot [:ochameau]]

So I imagine there is probably two steps here:

• tweak redux/react to support a hiearchy of targets,
• fetch the necessary information from the target fronts.

For now, the WorkerTargetFront's targetFront attribute is null, so you won't be able to retrieve the necessary information to build a tree.
But I think that bug 1573779 contains a fix for that, so that for each WorkerTargetFront, you will be able to know what is its parent target.
In case of regular content toolbox, it will be the top level document's target front, i.e. the top level toolbox target, i.e. the typical target the debugger is using.

So. I imagine you can already prepare the UI codebase to support that, but the framework still need some tweak to provide you the right information to build the tree of targets.

Comment 4

[Chris Peterson [:cpeterson]]

Tracking Fission DevTools bugs for Fission Nightly (M6)

Comment 5

[Chris Peterson [:cpeterson]]

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

Comment 6

[Chris Peterson [:cpeterson]]

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

Comment 7

[Chris Peterson [:cpeterson]]

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