The test is sometimes failing because there's a pending
connection to the server while the connection is closed.
My guess is that somehow the test could have been checking
other nodes instead of the current evaluated on to wait
for a node to be fully expanded.
The fix made here is to make sure that we only have one
node displayed when testing the object inspector.
Differential Revision: https://phabricator.services.mozilla.com/D54943
--HG--
extra : moz-landing-system : lando
This only affects console api calls where one of the
argument is an empty string. Since we don't quote
string arguments for those, it was difficult to spot
an empty string there.
Jest test are added, as well as a mochitest for the
console to make sure that we don't have unwanted
side effects (for evaluation results, object with
empty string properties, ...)
Differential Revision: https://phabricator.services.mozilla.com/D54687
--HG--
extra : moz-landing-system : lando
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
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
--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
We don't need to build an array of all the serializable data we
can find in parameters. We can loop through them and exit as
soon as we match the text filter.
Differential Revision: https://phabricator.services.mozilla.com/D54134
--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
Certain tests load data: URIs, blob: URIs, or otherwise do unusual things
that mean we need to disable the restriction for them.
Differential Revision: https://phabricator.services.mozilla.com/D46501
--HG--
extra : moz-landing-system : lando
The helper function waits for an event to be dispatched,
which adds extra safety.
Differential Revision: https://phabricator.services.mozilla.com/D53927
--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
The issue was that if a user typed a legitimate letter,
then, quickly after (i.e. before the autocompletion results
are here) hit Enter or Tab, the resulting input value would
be erroneous.
This is because we retrieve the value to insert from the
autocomplete popup, which at that time, is out-of-date, for
this brief moment.
The fix consists in updating the preLabel property of the
autocomplete popup items in order to get the proper
completion if the user ever hit enter, tab or arrow right.
We also take this as an opportunity to have a mechanism
to be able to cancel a registered update.
Differential Revision: https://phabricator.services.mozilla.com/D52376
--HG--
extra : moz-landing-system : lando
As Chrome has removed support for the HPKP (HTTP Public Key Pinning) header,
continuing to support it in Firefox is a compatibility risk. This patch adds
the preference "security.cert_pinning.hpkp.enabled" and sets it to false by
default. As such, the platform will no longer process the HPKP header nor
consult any cached HPKP information for certificate pins.
Preloaded (statically-compiled) pins are still enabled in Firefox by default.
This patch also disables dynamically setting pins via our remote security
settings infrastructure, as it uses the same backend and represents similar
compatibility risk.
Differential Revision: https://phabricator.services.mozilla.com/D52773
--HG--
extra : moz-landing-system : lando
Let's set javascript.options.asyncstack in the test to
have the async stacktrace displayed.
Differential Revision: https://phabricator.services.mozilla.com/D52697
--HG--
extra : moz-landing-system : lando
The function is only used in tests, which is a bit concerning
as we should test the actual function being used (evaluateJSAsync).
Differential Revision: https://phabricator.services.mozilla.com/D52331
--HG--
extra : moz-landing-system : lando
The function is only used in tests, which is a bit concerning
as we should test the actual function being used (evaluateJSAsync).
Differential Revision: https://phabricator.services.mozilla.com/D52331
--HG--
extra : moz-landing-system : lando
It's not obvious to me what the culprit is, but it may be because
of the clearOutput call somehow.
Let's see if this fix the intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D52321
--HG--
extra : moz-landing-system : lando
The tests are rewritten so we only have one test per
stub type. The stubs can be re-generated by passing
the --setenv WEBCONSOLE_STUBS_UPDATE=true arg when running
mach test.
We take this as an opportunity to not store the Messages
directly, but we generate them programmatically, which would
still reveal a bug as most of the test import messages.
Since we're doing that, some messages aren't localized, so
we need to add them to the L10N fixtures we have (which is
revamped a bit as getStr was getting too complex).
Differential Revision: https://phabricator.services.mozilla.com/D51596
--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
The issue was in commands.js evaluateJSAsync function where
we were trying to use an undefined parameter.
The regression wasn't spotted earlier because we only have
mocha test for CSS warning, and they don't assert this
codepath.
A mochitest is added on this patch to ensure CSS Warnings
can be expanded, that they display the impacted elements
as expected, and that clicking on the icon selects the
expected element in the inspector.
Differential Revision: https://phabricator.services.mozilla.com/D51627
--HG--
extra : moz-landing-system : lando
Wait for the messages to be displayed, and requestLongerTimeout,
as test failures logs seem to indicate that slower machine take
more than 30s to run the test.
Differential Revision: https://phabricator.services.mozilla.com/D51562
--HG--
extra : moz-landing-system : lando
A new parameter is added, and it expect an array
of filter objects (which contain a pattern and
a label properties), which are going to be used
by the save file dialog.
Depends on D51070
Differential Revision: https://phabricator.services.mozilla.com/D51078
--HG--
extra : moz-landing-system : lando
Ctrl+O (Cmd+O on OSX) will load file content into the console input.
Ctrl+S (Cmd+S on OSX) will show the file dialog for the user
to save the console input content into a file.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D51070
--HG--
extra : moz-landing-system : lando
We try to lazy load all the things we know we might
not need directly when opening the console.
Differential Revision: https://phabricator.services.mozilla.com/D50800
--HG--
extra : moz-landing-system : lando