The analyzeInputString function tried to handle escape characters in strings,
by having a dedicated ESCAPE state.
Unfortunately, when in ESCAPE state, the code will always re-assign the NORMAL state.
So if at some point the string was terminated, the code would assume we were entering
a string state again.
In the end, this would cause the autocomplete to fail, because the JSPropertyProvider
would think that it was passed an unterminated string literal.
This is fixed by introducing quote-specific escape state, so we know which state to get
back in once the escape character is consumed.
A few test cases are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D98754
This patch is a mixed bag of fixes:
- don't log an error when the string couldn't be analyzed, as it can occur
frequently when the console input isn't valid, and it clutters the browser
console
- never return a `null` matchProp. Default to empty string, so consumer code
can always assume it's a string
- don't call trim on a property if it's not a string (it can be an integer at
this point).
Differential Revision: https://phabricator.services.mozilla.com/D84779
The JsPropertyProvider parser is modified to accept optional chaining
syntax.
Differential Revision: https://phabricator.services.mozilla.com/D60654
--HG--
extra : moz-landing-system : lando
Variables are retrieved from CodeMirror state and sent to the
webconsole actor, where the filtering is done.
Differential Revision: https://phabricator.services.mozilla.com/D57427
--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
Move analyzeInputString function below JSPropertyProvider, so
the exported function appears first in the file.
Differential Revision: https://phabricator.services.mozilla.com/D49107
--HG--
extra : moz-landing-system : lando
Depends on D39335
Looking in details at get(), the implementation can also be simplified
Differential Revision: https://phabricator.services.mozilla.com/D39338
--HG--
rename : devtools/shared/webconsole/parser.js => devtools/shared/webconsole/parser-helper.js
extra : moz-landing-system : lando
We weren't handling comments at all, which means that having
any in the console would probably make the autocomplete not
working.
This patch handles both inline and multiline javascript comments,
and adds test cases to ensure we don't regress.
Depends on D36573
Differential Revision: https://phabricator.services.mozilla.com/D37196
--HG--
extra : moz-landing-system : lando
We were using Array.from to get an array of all the characters, and
be able to slice parts of the strings to run some checks.
This had the disadvantage of being quite slow on very large strings,
at a point where we introduced a bail out mechanism into the function
to not block the content page.
This patch switches to `String.prototype[Symbol.iterator]` to loop
over all the character, and removes lots of array and string manipulations.
On the same, super-large, string, the function cost went from 6700ms to
less than 200ms.
Differential Revision: https://phabricator.services.mozilla.com/D36572
--HG--
extra : moz-landing-system : lando
It can happen that the string we receive is quite large
and as a result takes a long time to analyze, freezing
the process.
This patch simply tracks for how long the for loop is running,
and bail out if it's greater than a given time (set to 2500 ms
for now).
This is mostly a safeguard, a future patch should try to improve
the performance of the function itself.
Differential Revision: https://phabricator.services.mozilla.com/D33791
--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
There are 2 changes in this patch.
In js-property-provider, we iterate over a Set
and delete item we don't want into instead of
turning the Set into an array, filter on it, and
convert it back to a new Set.
In the autocomplete function, we don't use regexp
anymore in the sort callback as we already have
a way to tell if we're performing an element access.
Differential Revision: https://phabricator.services.mozilla.com/D19471
--HG--
extra : moz-landing-system : lando
While trying to implement the invoke getter from
autocomplete popup, it became clear to me that the
initial implementation in js-property-provider wasn't
good enough, as we need to keep track of all the
authorizations the user gave when working on a given
expression.
In order to handle this, JsPropertyProvider now
returns an array of strings representing the path
to the unsafe getter when no matching authorizations
are provided.
If authorizations are provided, we can check for each
properties that the user authorized the execution.
This way, we can handle deep object access after a getter
(e.g. `x.myGetter.foo.bar.baz.entries`) without asking
the user if they want to invoke `myGetter` on each
step of the completion.
This makes handling intermediary getters (e.g.
`x.myGetter.foo.myOtherGetter.bar`) way easier as well.
In the UI, the user will be prompted to invoke the getter one
after the other (if for example they try to complete a pasted
expression which contains multiple getters, they will have
prompts for `myGetter`, and then for `myOtherGetter`).
We wire-up the webconsole client and the webconsole actor for
the autocomplete function, to make them ready for frontend
use.
The existing JsPropertyProvider getters test are updated to
match the change of parameter (invokeGetter -> authorizedEvaluations),
and some tests are added to make sure everything work as intended.
Differential Revision: https://phabricator.services.mozilla.com/D12940
--HG--
extra : moz-landing-system : lando
When provided a string, number or array literals, we use to
simply return the properties from String.prototype, Number.prototype
and Array.prototype.
This is working fine unless the content prototypes are modified.
In order to make it work properly, we retrieve the actual content
prototype.
The js-property-provider unit test is modified to ensure this is
working as expected.
Differential Revision: https://phabricator.services.mozilla.com/D15843
--HG--
extra : moz-landing-system : lando
In Bug 1462394, we moved the autocomplete data handling
out of the JsTerm to the Redux store. In the process, we
regress some cases like `await n`, which should display
`navigator`, but isn't anymore when the user types the
whole sequence. Ctrl+Space would still show the popup,
which indicates that the issue is not on the server-side.
This issue is caused because our new code decides that
we should hit the cache when typing the `n`, and there's
nothing in the cache.
Previously, we were clearing the cache as soon as the input
last string wasn't alphanumeric, which we don't anymore.
To fix that, instead of relying on the last string of the
input (which could be wrong in cases like `x.["hello `), we
clear the cache when the autocomplete service returns a null
`matches` property.
In the JsPropertyProvider, we use to return null whenever
there isn't any search done (incorrect input, empty match prop, …).
So it seems like a good idea to bust the cache when the
server returns null.
This requires some changes to the autocomplete service, as well
as some in jsPropertyProvider (e.g. to handle `await `).
Tests are added both on the client and the frontend to make sure
we don't regress this (those tests fail without the actual fix).
Differential Revision: https://phabricator.services.mozilla.com/D13231
--HG--
extra : moz-landing-system : lando
In JsPropertyProvider, if doing a property access (with a dot),
check that the results are suited for a dot notation (e.g. `data`
is, while `data-test` is not).
In case, of an element access, we can return everything.
This implies making some changes to some tests which were using
invalid dot notation access in some case, which revealed a
bug with bracket autocomplete and spaces.
So the bracket autocomplete with spaces is now also fixed, and
a test case was added for that as well.
Differential Revision: https://phabricator.services.mozilla.com/D12726
--HG--
extra : moz-landing-system : lando
To make $0 autocompletion work, we need to pass the current
selectedNode actor from the frontend, so we can retrieve the
object reference later.
For $_, we need the webconsole actor reference to be able
to retrieve the last input result.
Since the list of parameters of JsPropertyProviders was
getting a bit long, we transform them in an object so it's
more legible on the consumer side.
Mochitests are added for both helpers to ensure this work
as expected.
Differential Revision: https://phabricator.services.mozilla.com/D11866
--HG--
extra : moz-landing-system : lando
When provided a number literal, JsPropertyProvider would
not return anything.
This patch solves this issue by adding an if case for those
objects.
Numerous test cases are added in test_js_property_provider to
make sure we handle this as expected and that we don't have
false positives.
Differential Revision: https://phabricator.services.mozilla.com/D11483
--HG--
extra : moz-landing-system : lando
This patch adds two things to JsPropertyProvider:
- when provided an input which try to access an unsafe
getter properties, the function will indicate that an
unsafe getter should be invoked, with its name.
- a new boolean argument that when set to true would
invoke any unsafe getter that might be in the expression
to be completed.
For simplicity sake, the function only warns the user
of the presence of an unsafe getter when it's the last
property of the expression:
`object.myGetter.` will return that `myGetter` should be invoked
`object.myGetter.a.b.` will not (because then, a and b could
also be getters, and it's getting complex to handle both in
the function itself as in the UI).
Tests are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D11170
--HG--
extra : moz-landing-system : lando
This patches solves 2 issues:
- it doesn't return any result when the user is trying to
perform a variable, function or class declaration (e.g.
var d).
- js-property-provider used to compute the last statement
by only looking for space or ; chars. But there are a lot
of cases (basically each time using an operator), where we
should return results and we weren't.
Test cases are added to cover those fixes.
Differential Revision: https://phabricator.services.mozilla.com/D8968
--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
Add a new template literal state to findCompletionBeginning so we can
better handle the autocompletion for them.
Differential Revision: https://phabricator.services.mozilla.com/D4853
--HG--
extra : moz-landing-system : lando
This patch adds a smarter heuristic for autocompletion results:
if the input first letter is lowercased, then we'll filter
matching properties case insensitively. But if the user starts
with an uppercase, we assume they know the property they want
and thus respect the casing.
For example: `win` will return both `window` and `Window`, but
`Win` will return `Window` only.
Due to this behavior, we change the order of the autocomplete
results so lowercased property are displayed before the uppercased
one.
If we take are example again, it's likely that if a user type `win`,
they want `window`, but the alphabetical order would return `Window`
first which would annoy user.
Now, since we return results that does not match exactly the user
input, we need to modify the frontend.
Usually, we only show the autocompletion popup if there are
at least 2 matching items, since 1 matching item will still
be displayed using the autocompletion text. But now, since the
input might not match, we want to still display the popup if
there is one matching item, but starts differentely than what
the user entered.
For example, the user typed `window.addeve`, which matches
`addEventListener`. The completion text will make it looks like
it will be completed to `window.addeventListener`, which would
be undefined. So showing the popup with the actual matching
property might avoid some confusion for the user.
A test was added to make sure the frontend works as expected.
Some test cases were added in the server test to make sure
the actor returns expected results. Other tests needed some
adjustement because of the insensitive case matches and the
new order of results.
Differential Revision: https://phabricator.services.mozilla.com/D4061
--HG--
extra : moz-landing-system : lando
Expressions like `window . addEventListener` are perfectly valid in JS,
but our autocompletion provider wasn't working well in such case.
We modify the JSPropertyProvider to make sure to handle this kind of
syntax and add test cases to make sure it works as intended.`
Differential Revision: https://phabricator.services.mozilla.com/D2988
--HG--
extra : moz-landing-system : lando
ESLint 4 will turn on all rules after an eslint-enable with no arguments. Therefore be more specific about which rules are being disabled.
MozReview-Commit-ID: IoPBG72zySm
--HG--
extra : rebase_source : f0095f7a9bc3020c1a36387cd033d1b1238a61cf
