1630525 - BrowsingContext actors returns different traits objects in `form()` and `attach()`

Status: RESOLVED FIXED

(DevTools :: General, task, P3)

Description

[Julian Descottes [:jdescottes]]

The BrowsingContextTargetActor defines a this.traits property at : https://searchfox.org/mozilla-central/rev/97cb0a90bd053de87cd1ab7646d5565809166bb1/devtools/server/actors/targets/browsing-context.js#267-276

    this.traits = {
      reconfigure: true,
      // Supports frame listing via `listFrames` request and `frameUpdate` events
      // as well as frame switching via `switchToFrame` request
      frames: true,
      // Supports the logInPage request.
      logInPage: true,
      // Supports watchpoints in the server for Fx71+
      watchpoints: true,
    };

This this.traits is returned as part of the response for the attach request at https://searchfox.org/mozilla-central/rev/97cb0a90bd053de87cd1ab7646d5565809166bb1/devtools/server/actors/targets/browsing-context.js#1004

And the front seems to handle it appropriately: https://searchfox.org/mozilla-central/rev/97cb0a90bd053de87cd1ab7646d5565809166bb1/devtools/client/fronts/targets/browsing-context.js#95

However, there is another traits object, this time returned by the form() call: https://searchfox.org/mozilla-central/rev/97cb0a90bd053de87cd1ab7646d5565809166bb1/devtools/server/actors/targets/browsing-context.js#492-496

    const response = {
      actor: this.actorID,
      browsingContextID: this.docShell.browsingContext.id,
      traits: {
        // FF64+ exposes a new trait to help identify BrowsingContextActor's inherited
        // actorss from the client side.
        isBrowsingContext: true,
      },
    };

The BrowsingContext front doesn't handle this, but (!) we have the getTrait feature on target-mixin (base class for the BrowsingContextTargetFront) which reads this.targetForm.traits, and since targetForm is a reference to the form() response, it will be able to get the isBrowsingContext trait.

It's confusing to have traits split like this. We should move all traits to the form response, so that they can be checked via getTrait.

Comment 1

[Chris Peterson [:cpeterson]]

M6

Comment 2

[Chris Peterson [:cpeterson]]

Adding dt-fission whiteboard tag to DevTools bugs that mention Fission or block Fission meta bugs but don't already have a dt-fission whiteboard tag.

Comment 3

[Chris Peterson [:cpeterson]]

Moving these DevTools Fission bugs from Fission's old M6 Nightly milestone to M7 Beta. I am assuming these bugs would have the dt-fission-m2-mvp whiteboard tag if they were Fission Nightly blockers.

Comment 4

[Neha Kochar [:neha]]

Bulk change of all bugs with whiteboard tag of dt-fission to Fission MVP milestone.

Comment 5

[Julian Descottes [:jdescottes]]

Removing the fission tags and milestones from this bug, it's a generic devtools task not specific to fission.

Comment 6

[Chris Peterson [:cpeterson]]

(In reply to Julian Descottes [:jdescottes] from comment #5)

Removing the fission tags and milestones from this bug, it's a generic devtools task not specific to fission.

In that case, adding [fission-] whiteboard tag (so this bug doesn't show up in Fission bug triage simply because the bug summary contains the substring "BrowsingContext").

Comment 7

[Chris Peterson [:cpeterson]]

Not a Fission bug

Comment 8

[Hubert Boma Manilla (:bomsy)]

This has been the source of intermittents as the traits set from attach are sometimes late, Bug 1726220 one such.

Comment 9

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1630525 - [devtools] Merge all the BrowsingContext traits to the form() r=ochameau

The traits set on attach have been a source of intermittent failures.
See Bug 1726220

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a27fd13df1ed
[devtools] Merge all the BrowsingContext traits to the form() r=ochameau

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/a27fd13df1ed