PerformanceEntry values are put in the `getterValue` property in
the descriptor, so whenever we want to display a table we need
to check if the value could be in there.
This highlighted an issue in the console layout when there is a
large number of cells, which we fix in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D54261
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This will allow us to not have 2 object inspectors
with the same name, which was causing an issue
when putting an object in the sidebar (the object
in the sidebar and the one in the output would share
the same key in the objectInspector key, meaning that
expanding/collapsing nodes on one of them would also
do it on the other one).
A test needed to be modified where we were relying on
this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D53666
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Using next-line is less error prone for refactorings than wrapping methods with enable/disable blocks.
Differential Revision: https://phabricator.services.mozilla.com/D51782
--HG--
extra : moz-landing-system : lando
Fix 2 proptype errors: one in App.js, and the
other one in the renderStacktrace function,
that is called by Error rep.
Differential Revision: https://phabricator.services.mozilla.com/D44467
--HG--
extra : moz-landing-system : lando
With top-level await, we can now have multiple
evaluation results next to each others. Which
means that if they had the same repeatId, we
would only print the first result.
We fix that by not allowing evaluation results to
be repeated.
A mochitest is added to ensure the patch properly
fixes the issue.
Differential Revision: https://phabricator.services.mozilla.com/D43253
--HG--
extra : moz-landing-system : lando
I pass `frame.origin` in `viewSourceInDebugger`. When `reason` is logpoint, run `openConditionalPanel`.
Differential Revision: https://phabricator.services.mozilla.com/D35624
--HG--
extra : moz-landing-system : lando
When opening the Browser Console, if the browser toolbox fission pref
is enabled, we create a WebConsoleConnectionProxy for each process.
This allow us to not start the ContentProcessMessages listener (that
uses ContentProcessMessagesForward), but directly connect to the content
process, to get fully inspectable console message, from the Browser Console.
We keep the this.proxy reference in WebConsoleUI to represent the "main" target
proxy, and we add an `additionalProxies` property that represent proxies
for other targets we connect to (e.g. content process targets).
We then have a function to list all the proxies we're handling, in order to
be able to do tasks on all of them (e.g. clearing cache, network message, ...)
We also take this as an opportunity to add a `evaluateJSAsync` at the
WebConsoleUI level so callsites don't retrieve the proxy.webConsoleClient
themselves.
Differential Revision: https://phabricator.services.mozilla.com/D40786
--HG--
extra : moz-landing-system : lando
The goal is to not directly use the panel.hud.ui.proxy reference
directly from the JsTerm, so we're in better shape when Fission
comes.
It's also a nice refactor to make the JSTerm component more
React-like.
As a nice benefit, we can handle telemetry and history persistence
from their middleware.
As the `requestEvaluation` method is removed from the JSTerm, some
callsites needed to be updated to still work.
Differential Revision: https://phabricator.services.mozilla.com/D39022
--HG--
extra : moz-landing-system : lando
The goal is to not directly use the panel.hud.ui.proxy reference
directly from the JsTerm, so we're in better shape when Fission
comes.
It's also a nice refactor to make the JSTerm component more
React-like.
As a nice benefit, we can handle telemetry and history persistence
from their middleware.
As the `requestEvaluation` method is removed from the JSTerm, some
callsites needed to be updated to still work.
Differential Revision: https://phabricator.services.mozilla.com/D39022
--HG--
extra : moz-landing-system : lando
The function is only called from the context-menu,
where we already have all the references we need.
So we can move the function code directly in the
menu item callback.
Differential Revision: https://phabricator.services.mozilla.com/D38613
--HG--
extra : moz-landing-system : lando
We add a GridElementWidthResizer to handle the editor width.
The width is then persisted in a pref.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D37687
--HG--
extra : moz-landing-system : lando
Add a context menu entry to export the console output to a file.
We group the 2 export entries into a submenu.
Differential Revision: https://phabricator.services.mozilla.com/D22158
--HG--
extra : moz-landing-system : lando
If logpoint throws, set `level` to "error".
Add tests to ensure the correct level is set.
Demo function: https://luxuriant-system.glitch.me/
Add some logpoints. The first two statements are invalid. The third one is valid.
{F1311386}
In console:
{F1311387}
Differential Revision: https://phabricator.services.mozilla.com/D31157
--HG--
extra : moz-landing-system : lando
This allows to have more meaningful warning group messages, i.e.
"Content Blocking" is turned into something like "The resource at
'<URL>' was blocked because content blocking is enabled".
This is done by parsing the message of the first warning to put
in the group, and replacing the URL with a generic placeholder.
We take this as an opportunity to decouple content blocked messages
and storage access blocked ones, as they have slightly different
meanings and consequences.
Tests are updated to match the new labels, and a new test is
added to make sure that we can have multiple warning group in a
single "page navigation" session.
Differential Revision: https://phabricator.services.mozilla.com/D34339
--HG--
extra : moz-landing-system : lando
We want to go back to ESLint's default complexity level so that newly introduced code is checked for complexity.
At the same time, to make that work, we're excluding all of the more complex functions for now.
We should fix them: make them less complex, and remove the eslint-disable comment.
See bug 1553449 for more information about this.
Differential Revision: https://phabricator.services.mozilla.com/D32139
--HG--
extra : moz-landing-system : lando
We want to go back to ESLint's default complexity level so that newly introduced code is checked for complexity.
At the same time, to make that work, we're excluding all of the more complex functions for now.
We should fix them: make them less complex, and remove the eslint-disable comment.
See bug 1553449 for more information about this.
Differential Revision: https://phabricator.services.mozilla.com/D32139
--HG--
extra : moz-landing-system : lando
This patch builds on [Bug 1537876](https://bugzilla.mozilla.org/show_bug.cgi?id=1537876) which associates CSS selectors with error messages where applicable.
This patch introduces a new React component, `CSSWarning`, for messages of type CSS. It forks the`PageError` component which was shared for `LOG` messages of type `JAVASCRIPT` and type `CSS`.
The `CSSWarning` component is expandable when the message has an associated CSS selector. When expanded, it runs a `document.querySelectorAll()` command to list all elements matching the selector. Clicking on any of the elements in the result jumps to the Inspector and select the corresponding node in the markup view.
Not all errors have associated CSS selectors. Not all selectors match elements. The errors/warnings are a result of the CSS Parser; there is no guarantee that the CSS rule is used anywhere on the document. The query may return an empty `NodeList`.
Differential Revision: https://phabricator.services.mozilla.com/D28457
--HG--
extra : moz-landing-system : lando
This property was already in console api message packet,
and this patch also adds it to pageError packets (retrieving
it from nsIScriptError.isFromChromeContext).
Stubs are updated to include the new property.
Differential Revision: https://phabricator.services.mozilla.com/D26336
--HG--
extra : moz-landing-system : lando
This property was already in console api message packet,
and this patch also adds it to pageError packets (retrieving
it from nsIScriptError.isFromChromeContext).
Stubs are updated to include the new property.
Differential Revision: https://phabricator.services.mozilla.com/D26336
--HG--
extra : moz-landing-system : lando
If there's at least 2 content blocking messages displayed
for a given page navigation, we display a warning group
containing the messages, collapsed by default.
This means we need to move or insert those warning messages
at the right position in visibleMessages, either when they're
added, or when we expand a group.
Two mochitest are added to make sure this works as expected,
one for generic warningGroup features (expanding, group per
navigation session, …), and another one specifically for
content blocking warning group, where we check that every
type of content blocking message can be grouped.
The grouping won't occur unless the groupWarnings preferences
is on.
Differential Revision: https://phabricator.services.mozilla.com/D23552
--HG--
extra : moz-landing-system : lando
This component will be used to render warning groups messages.
We also add a `inWarningGroup` prop to the `Message` component
so warnings that will be displayed in such warningGroup can
be styled differently (no warning icon, a different color for
the indent).
Add some utils functions and constants to check if a message
should be a warning group.
Differential Revision: https://phabricator.services.mozilla.com/D23551
--HG--
extra : moz-landing-system : lando
If there's at least 2 content blocking messages displayed
for a given page navigation, we display a warning group
containing the messages, collapsed by default.
This means we need to move or insert those warning messages
at the right position in visibleMessages, either when they're
added, or when we expand a group.
Two mochitest are added to make sure this works as expected,
one for generic warningGroup features (expanding, group per
navigation session, …), and another one specifically for
content blocking warning group, where we check that every
type of content blocking message can be grouped.
The grouping won't occur unless the groupWarnings preferences
is on.
Differential Revision: https://phabricator.services.mozilla.com/D23552
--HG--
extra : moz-landing-system : lando
Nicolas Chevobbe
Raymond Liu
Jason Laster
Julian Descottes
Mihai Alexandru Michis
David Walsh
wartmanm
Oana Pop Rus
Emilio Cobos Álvarez
Gabriel Luong
Gijs Kruitbosch
chujun
Ciure Andrei
yulia
Victor Porof
Jefry Lagrange
Patrick Brosset
Christoph Walcher
Brian Hackett
Razvan Caliman
Razvan Maries
Daniel Varga