WebConsole should handle ObjectFront when needed (for non-primitive Console API args + Evaluation results)
Categories
(DevTools :: Console, task, P1)
Tracking
(firefox73 fixed)
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: nchevobbe, Assigned: nchevobbe)
References
(Blocks 2 open bugs)
Details
(Whiteboard: 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.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 1•5 years ago
•
|
||
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.
Assignee | ||
Comment 2•5 years ago
|
||
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
Assignee | ||
Comment 3•5 years ago
|
||
Depends on D54136
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
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
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D54506
Assignee | ||
Comment 8•5 years ago
|
||
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
Assignee | ||
Comment 9•5 years ago
|
||
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
Assignee | ||
Comment 10•5 years ago
|
||
This makes the Preview popup and the Watch Expression panel works
with ObjectFronts.
Depends on D54509
Assignee | ||
Comment 11•5 years ago
|
||
This makes the DOM panel handle ObjectFronts.
Depends on D54510
Assignee | ||
Comment 12•5 years ago
|
||
The objectFront constructor signature changed, so this patch adapt
the inspector to the new one.
Depends on D54511
Assignee | ||
Comment 13•5 years ago
|
||
Depends on D54512
Comment 14•4 years ago
|
||
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.
Comment 15•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/89a3c8f1318a
https://hg.mozilla.org/mozilla-central/rev/6473943d62d6
https://hg.mozilla.org/mozilla-central/rev/0c1e5ee80b25
https://hg.mozilla.org/mozilla-central/rev/93d9d85eae43
https://hg.mozilla.org/mozilla-central/rev/b4354b307ea6
https://hg.mozilla.org/mozilla-central/rev/1f9e4a1243ab
https://hg.mozilla.org/mozilla-central/rev/cb7c61cf9c77
https://hg.mozilla.org/mozilla-central/rev/a1f1ebad7d9d
Updated•4 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Description
•