This patch adds a new context for the performance-new components. It's
eventually the only place where the settings will live, but for now
the components share the settings between the popup, the devtools panel,
and the about:profiling page.
This page uses the base styling that the preferences page uses. The styles
should obey the theming for the browser, and ignore the devtools theming
colors.
Differential Revision: https://phabricator.services.mozilla.com/D55010
--HG--
extra : moz-landing-system : lando
This is probably the biggest change to the existing components, as it makes the
summary dropdowns conditional based on the page context. This keeps the old
workflow working, but allows for the new about:profiling page's design. Most
of the diff here is creating the new _renderSection method which consolidates
this logic, and also handles the summary div structure.
Differential Revision: https://phabricator.services.mozilla.com/D55009
--HG--
extra : moz-landing-system : lando
The new about:profiling page creates some more complexity around what
the page context is. It is simpler to handle the different cases with
a union, rather than booleans.
Differential Revision: https://phabricator.services.mozilla.com/D55008
--HG--
extra : moz-landing-system : lando
This commit is fairly trivial, but creates the about:profiler page to
start the new about:profiler work.
Differential Revision: https://phabricator.services.mozilla.com/D53729
--HG--
extra : moz-landing-system : lando
It looks like we left out some places in the inspector when we made it fission-compatible.
The color-picker, in particular, needs access to the selected node's computed style for its
color contrast logic.
We used to access this on the top-level target PageStyleFront. We just need to change this so
it uses the one contextual to the selected node.
Differential Revision: https://phabricator.services.mozilla.com/D55962
--HG--
extra : moz-landing-system : lando
Depends on D55204
This is just a smoke test to verify that the HAR file is created.
We should probably expand this and test the content as well, but we can handle that in follow up bugs
Differential Revision: https://phabricator.services.mozilla.com/D55271
--HG--
extra : moz-landing-system : lando
This fixes several gaps:
- event api changes
- networkEvent no longer emitted by debugger client
- shape of expected HAR items changed
- use the connector from the netmon api
This is the minimum set of changes I could do to get HAR automation to save valid HAR files again.
Differential Revision: https://phabricator.services.mozilla.com/D55204
--HG--
extra : moz-landing-system : lando
When the selectedObjectActor options is passed to the evaluateJSAsync
command in the console, we now try to retrieve the corresponding console
front to send the request to the correct target.
This makes the "Copy Object" context menu entry works in the Browser Console
on content objects.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D55258
--HG--
extra : moz-landing-system : lando
The objectFront constructor signature changed, so this patch adapt
the inspector to the new one.
Differential Revision: https://phabricator.services.mozilla.com/D54512
--HG--
extra : moz-landing-system : lando
This makes the Preview popup and the Watch Expression panel works
with ObjectFronts.
Differential Revision: https://phabricator.services.mozilla.com/D54510
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D54508
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D54506
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D54136
--HG--
extra : moz-landing-system : lando
Since the storage inspector is the last consumer of the VariablesView,
it makes sense to move the component directly in the storage inspector
folder.
Since it can't have a controller, the bits where we were checking this
are removed.
Differential Revision: https://phabricator.services.mozilla.com/D54734
--HG--
rename : devtools/client/shared/widgets/VariablesView.jsm => devtools/client/storage/VariablesView.jsm
extra : moz-landing-system : lando
