This should be ready to review. However, I will include a big caveat that I
tried to do things the Reacty way, and it felt really awkward. Notably, I used
a React functional component, because they seem to be recommended as the
Right Way to do things, but because of all the state we need to keep track of,
as well as just the props that we don't want to lexically access because then
they can be stale, it felt really wrong. Guidance is welcome.
However, the core logic should be ready for review, so focus on that, and let
me know if I need to move anything around to make it more palatable.
Depends on D138030
Differential Revision: https://phabricator.services.mozilla.com/D138031
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.
Differential Revision: https://phabricator.services.mozilla.com/D54509
Increasing the number of columnns highlighted some issues:
- Some element could be off-screen, the grid-template-columns
needed to be adjusted
- headers could be cut-off, we add a title on the element to
have the full content in a tooltip
- properties that are not defined were displayed as "undefined",
which is not really true, and take a lot of space. We render
them as an empty cell in such case now.
A test is added to check the max-column limit.
Differential Revision: https://phabricator.services.mozilla.com/D54260
This allows us to not have to reach for the server
again from the client to get all the data we need
to render the table.
We still need to keep the old function to handle
connections to older servers. We'll use Bug 1597955
in Firefox 74 to clean the bits we don't need anymore.
A test is added to ensure the bug is fixed and we don't
regress; stubs are updated.
Differential Revision: https://phabricator.services.mozilla.com/D53962
In order to render a table, we first check that console.table is
called with data that can be displayed in a table. Until now, we
were missing all the typed arrays.
This revealed some smaller issues:
- BigInt64Array were not marked as typed arrays on the server.
- Generating the repeatId for a message containing BigInts would
throw because BigInts can't be serialized.
We add test cases for all the typed array, and we take this opportunity
to add a test case to ensure object insides table cells can be expanded.
Differential Revision: https://phabricator.services.mozilla.com/D53155
We also add a few console API calls, as well as pass a second
object parameter for the methods that support it, so we can
check that the content object are well displayed in the
Browser Console.
As we add a new check for console.table, I realized that
hiding and showing a consoleTable component would trigger a
new request to the server, even if we already have the table
data at hand.
I fixed this by only trying to get data from the server if
we don't have them already.
Differential Revision: https://phabricator.services.mozilla.com/D44159
A test is added to ensure this is fixed properly.
We also fix the Array previewer to properly return
undefined for unknown array properties, rather than null.
Differential Revision: https://phabricator.services.mozilla.com/D38467
Alexandre Poirot