Closed Bug 1579090 Opened 10 months ago Closed 7 months ago

WebConsole should handle ObjectFront when needed (for non-primitive Console API args + Evaluation results)

Categories

(DevTools :: Console, task, P1)

task

Tracking

(firefox73 fixed)

RESOLVED FIXED
Firefox 73
Tracking Status
firefox73 --- fixed

People

(Reporter: nchevobbe, Assigned: nchevobbe)

References

(Blocks 3 open bugs)

Details

(Whiteboard: dt-fission dt-fission-m1)

Attachments

(8 files, 2 obsolete files)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review

To ease Fission's work, we should really be dealing with object fronts, and not object clients.
We should first start creating an ObjectFront that can be used in some part of the code, so we don't have to migrate all the comsumers of ObjectClients at once.

Whiteboard: dt-fission
Assignee: nobody → nchevobbe
Status: NEW → ASSIGNED
Priority: P2 → P1
No longer blocks: 1577783
Summary: Have an ObjectFront in parallel to ObjectClient → WebConsole should handle ObjectFront when needed (for non-primitive Console API args + Evaluation results)
Depends on: 1588997
Component: Shared Components → Console
Blocks: 1577211
Depends on: 1591330

We mentioned this bug when discussing about the _longStrings internal map stored by the webconsole Front.
Thread at https://phabricator.services.mozilla.com/D50579#inline-306790
The question was whether we should look into removing this _longStrings map and directly rely on the Pool's get method.
Apparently this bug should make this question irrelevant, so no need to do anything for now.

Blocks: 1572438
Blocks: 1567849
Depends on: 1595012
Depends on: 1326182
Depends on: 1597905

We export it as a named property to match other fronts, and
also because we plan to add a helper function in the file
that will need to be exported as well.

Depends on D53962

Attachment #9110545 - Attachment is obsolete: true
Duplicate of this bug: 1572438
Duplicate of this bug: 1577211

This is the first part of a bigger patch to make WebConsoleFront methods
consumers handle fronts instead of plain grips.
The main challenge with most of console methods is that the server
can return either a primitive, an object that represent a primitive
(undefined, null, Infinity, ...), a longString grip or an object grip.

Since this would be complex to map as a protocol.js type, this patch
either override the methods where we want to return fronts, or intercept
events with the before method on them.

The response is then handled to a function that will iteratore of the
result object in a recursive manner, and create fronts when needed.

Depends on D54136

This patch make it so ObjectInspector can handle both simple grips and fronts.
The main idea is that we can now pass a front property to ObjectInspector nodes,
that will then be used to retrieve properties on the object.

Depends on D54507

Since we may now have ObjectFronts in console messages as
well as in evaluation results, we need to make the webconsole
consume those fronts.

And because we have ObjectFronts, we can now avoid using the
DebuggerClient to release the actors, and simply call front.release.
This simplifies how we track created object, since we only need
to release "root" objects, which will also cause all the sub-fronts
to be released as well. Sadly, this was causing some test failures
in mochitests because some objects were released while the connection
was closed, so we now emit an event when all the actors are released,
which we track in tests to wait until everything is over.

As a side effect, we need to change how we handle stubs for
our tests, since fronts have cycical references and can't
be serialized directly. In order to handle that, we serialize
all front as a plain object with a _grip property, containing
the object grip. In the stub file, we don't expose the grips
directly, but Maps that contain those stubs "rehydrated": when
a _grip object is encountered, it's turned back into a front.

Depends on D54508

This makes the Preview popup and the Watch Expression panel works
with ObjectFronts.

Depends on D54509

This makes the DOM panel handle ObjectFronts.

Depends on D54510

The objectFront constructor signature changed, so this patch adapt
the inspector to the new one.

Depends on D54511

Depends on D54512

Blocks: 1599425
Blocks: 1599432
Blocks: 1500000
Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/89a3c8f1318a
Change how ObjectFront is exported. r=rcaliman.
https://hg.mozilla.org/integration/autoland/rev/6473943d62d6
Make WebConsoleFront, PropertyIteratorFront, SymbolIteratorFront and ObjectFront return adhoc fronts (or primitive) when needed. r=jlast.
https://hg.mozilla.org/integration/autoland/rev/0c1e5ee80b25
Fix server and shared tests that were failing because of the webConsoleFront changes. r=ochameau.
https://hg.mozilla.org/integration/autoland/rev/93d9d85eae43
Make ObjectInspector and Reps work with object fronts. r=Honza,jlast.
https://hg.mozilla.org/integration/autoland/rev/b4354b307ea6
Support ObjectFronts in WebConsole. r=Honza.
https://hg.mozilla.org/integration/autoland/rev/1f9e4a1243ab
Fix debugger after changes made to WebConsoleFront methods. r=jlast.
https://hg.mozilla.org/integration/autoland/rev/cb7c61cf9c77
Fix DOM panel after WebConsoleFronts changes. r=Honza.
https://hg.mozilla.org/integration/autoland/rev/a1f1ebad7d9d
Fix how ObjectFronts are created in the inspector. r=rcaliman.
Regressions: 1601244
Attachment #9111232 - Attachment is obsolete: true
Whiteboard: dt-fission → dt-fission dt-fission-m1
Regressions: 1617210
Regressions: 1620782
You need to log in before you can comment on or make changes to this bug.