Show source-mapped variables in console autocomplete
Categories
(DevTools :: Console, enhancement)
Tracking
(firefox95 fixed)
| Tracking | Status | |
|---|---|---|
| firefox95 | --- | fixed |
People
(Reporter: wartmanm, Assigned: wartmanm)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
https://wartmanm.gitlab.io/debugger-examples/minified-trivial/
Open the console, run test(), enter val
Actual results:
valueOf, values, ValidityState appear in the autocomplete popup, and function valueOf() appears in the eager-evaluation preview.
Expected results:
It would be nice if value showed up as well. I feel that it would help make source-mapped files more transparent.
I'd be happy to work on this. However, while autocompleting variable names and properties seems straightforward, eager-eval-driven property autocomplete seems much more challenging and I'm not sure how to approach it.
I'm still interested in working on this, please. I think it would be helpful even without eager eval mapping.
|
||
Comment 4•3 years ago
|
||
oh sure, sorry mattheww for the delay.
The patch on phabricator is a draft, is it ready for review or are you blocked on something? How can I help?
No worries! I didn't want the patch to show up in anyone's review queue before the feature request was accepted, and I wasn't sure whether to even attempt eager eval mapping. I rebased it and fixed the eslint errors, and it should be ready now.
|
|
||
Comment 6•3 years ago
|
||
(In reply to mattheww from comment #5)
No worries! I didn't want the patch to show up in anyone's review queue before the feature request was accepted, and I wasn't sure whether to even attempt eager eval mapping. I rebased it and fixed the eslint errors, and it should be ready now.
I think this would be a nice thing to have, especially since we already map variables at execution time
Sounds good, but I think I will need some advice on how to proceed.
Right now, expression mapping is only available on the client, and only works if there are no syntax errors, but the analyzeInputString method to turn console input into valid javascript expressions is only available on the server. Both of them are big enough that I don't really want to try and replicate them on the other side.
I could avoid this problem and instead count on bracket matching to provide a valid string most of the time. But, without knowing what expression was evaluated, I can't convert an unsafe getter path back to an original expression. (Multiple original variables can map to one generated variable, or to a path containing unsafe getters.)
I could add a method to ask the server to get the expression to evaluate, but I don't know how much latency it could add. Should it be a last resort after finding an unsafe getter, or done before mapping?
Please disregard all of that, I saw that js-property-provider.js was exclusively used on the server, but overlooked that it's in the shared folder. I've updated the review to handle eager evaluation and unsafe getters. I'm still not entirely comfortable calling something that makes use of a timeout twice, but it works!
|
||
Updated•3 years ago
|
Pushed by nchevobbe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6149555d9efa Autocomplete source-mapped variable names r=nchevobbe
|
||
Comment 10•3 years ago
|
||
| bugherder | ||
Description
•