We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Depends on D6925
Differential Revision: https://phabricator.services.mozilla.com/D6926
--HG--
extra : moz-landing-system : lando
1. Allow passing a selector to waitForMessage helper function:
This will allow to wait for specific message (warning, error, result, …).
This patch also fixes 2 tests that were already passing an erroneous selector
to waitForMessage.
2. Add an executeAndWaitForMessage function:
This will make a lot of our tests much easier to read. The function takes
an input, an expected output and an optional selector, execute the input
and resolves when a message matching the provided text (and selector
if passed) is displayed in the output.
Depends on D6903
Differential Revision: https://phabricator.services.mozilla.com/D6925
--HG--
extra : moz-landing-system : lando
This patch turns the current top-level handling, which relies on
the console API to print the result of the await expression, into
something natively handled by the server.
First, we don't add a .then handler to the generated async iife by
the mapper. We also removes the case we added in the JsTerm to *not*
print the result for top-level await expression.
In order to make the server capable of handling generated async iife
caused by the mapper, we send to evaluateJsAsync the `mapped` object
that `mapExpression` returns. This way, the server can check if an
expression was originally a top-level await.
If it is the case, we get the promise from the async iife and wait for
it to settle. If it resolves, we simply return the result, as a grip,
to the client. If it rejects, we return a special packet indicating to
not print anything to the client. The error will be reported by the
engine as `uncaught exception: …`.
We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Differential Revision: https://phabricator.services.mozilla.com/D6903
--HG--
extra : moz-landing-system : lando
Added trace extra parameters to be printed alongside console.trace() output.
Differential Revision: https://phabricator.services.mozilla.com/D7051
--HG--
extra : moz-landing-system : lando
- Various telemetry methods now need an object to be passed in in order to keep them seperate e.g. if the inspector is opened in tab 1 a timer is started. If an inspector is opened in tab 2 the same timer is restarted. Closing tab 2 would then erase the timing event invalidating the timer in tab 1.
- We no longer need to preface telemetry calls with category "devtools.main" because this is the only category we will be using.
- There are some changes to `devtools/client/debugger/new/dist/vendors.js` and `devtools/client/debugger/new/src/utils/telemetry.js` that need to be ported to the debugger at the same time as landing this.
Differential Revision: https://phabricator.services.mozilla.com/D6137
--HG--
extra : moz-landing-system : lando
TabTarget.attach is being called from the toolbox, before opening the tools,
so we do not have to call it from panel's open functions, nor code that is opening
a toolbox right after.
MozReview-Commit-ID: 77TZFbvOaFt
Differential Revision: https://phabricator.services.mozilla.com/D6668
--HG--
extra : moz-landing-system : lando
This patch will remove setContest(), and change the following things instead of this:
* Use HTMLTooltip.panel.appendChild() instead of HTMLTooltip.setContent().
* Add HTMLTooltip.setContetnSize() to specify the panel size if need this.
Differential Revision: https://phabricator.services.mozilla.com/D7044
--HG--
extra : moz-landing-system : lando
SwatchBaseEditorTooltip specify the "topcentor bototmleft" to second parameter
of HTMLTooltip.show(). However, this parameter will ignore since show() function
require the second parameter as the object, not the string.
Bug 1307481 comment 42 has pointed out this parameter.
Differential Revision: https://phabricator.services.mozilla.com/D7043
--HG--
extra : moz-landing-system : lando
This patch adds the ability to open the autocomplete popup when
typing an opening bracket (i.e. `[`]) in the console input.
This impacts a significant amount of function where we assumed
that the only way to get a completion was to use a dot.
We uses the rename `anylyzeInputString` function to get the
completion part from an input, as well as if the user is performing
an element access (i.e., using the bracket).
We then send that information to the webconsole actor, which send
it to the client.
This allows us to rely on a single parse of the input and gives us
access to this information everywhere we need to, be it on the client
or on the server.
We allow the user to type property name without quotes, and we add
them when the user accept an autocompletion.
We also automatically add a closing bracket (i.e. `]`), when it's needed.
Some test are added. On the server side to make sure the actor's autocomplete
function returns what's expected.
We take that as an opportunity to add test for commands.
On the client side, tests are added to ensure the different behavior works
as expected (check the completion text and the input after accepting
the completion when the user entered some letters, or not, with or without
quotes, with different quotes, hitting the autocomplete cache, …).
A test which accesses the autocomplete cache was modified since the shape
of the cache changed to include the last matchProp as well as the
isElementAccess boolean.
Differential Revision: https://phabricator.services.mozilla.com/D6128
--HG--
extra : moz-landing-system : lando
