Closed Bug 1569023 Opened 5 years ago Closed 5 years ago

Expose a helper on protocol's Front class to help retrieve the parent front

Categories

(DevTools :: Framework, enhancement, P1)

enhancement

Tracking

(firefox70 fixed)

RESOLVED FIXED
Firefox 70
Tracking Status
firefox70 --- fixed

People

(Reporter: gl, Assigned: gl)

References

(Blocks 2 open bugs)

Details

(Whiteboard: dt-fission-m1)

Attachments

(1 file)

In Bug 1539764, we added a targetFront attribute to retrieve the target front. This would allow us to do async calls to retrieve target-scoped fronts like the Inspector via await nodeFront.target.getInspector().

Since we know these child fronts of target-scoped fronts are initialized and managed by their parent target-scoped fronts, we could add an attribute targetScoped to retrieve their ancestor target-scoped fronts. Allowing us to have synchronous access to the target-scoped fronts.

As an example, nodeFront is a child front of walkerFront. nodeFront.targetScoped and walkerFront.targetScoped would both point to the inspectorFront which is the target-scoped front.

Only children of the target-scoped fronts will have a targetScoped attribute set.
This targetScoped attribute returns the ancestor target-scoped front. As an example,
nodeFront.targetScoped would return the InspectorFront.

Priority: P3 → P1
Whiteboard: dt-fission
Blocks: 1572460
Attachment #9081121 - Attachment description: Bug 1569023 - Expose a helper on protocol's Front class to help retrieve the target-scoped front. r=ochameau,yulia → Bug 1569023 - Expose a helper on protocol's Front class to help retrieve the parent front. r=ochameau,yulia
Summary: Expose a helper on protocol's Front class to help retrieve the target-scoped front → Expose a helper on protocol's Front class to help retrieve the parent front

Out of curiosity, in terms of naming was there a discussion around suffixing properties with Front? Naively, it seems like that would be assumed. i.e I would assume that a parent property of a front would be a front.

(In reply to Jason Laster [:jlast] from comment #2)

Out of curiosity, in terms of naming was there a discussion around suffixing properties with Front? Naively, it seems like that would be assumed. i.e I would assume that a parent property of a front would be a front.

This has came up before. You can imagine the problem in the inspector where we have a InspectorFront and call it inspector on the client. We end up calling something like inspector.inspector instead of inspector.inspectorFront. So, we added the Front suffix to be explicit about what we are calling. You can also see in the phabricator comments why we couldn't use parent as the name because we have conflict with the NodeFront already using _parent.

Pushed by gluong@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/59052299b371 Expose a helper on protocol's Front class to help retrieve the parent front. r=ochameau,yulia
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Whiteboard: dt-fission → dt-fission dt-fission-m1
Whiteboard: dt-fission dt-fission-m1 → dt-fission-m1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: