Once bug 1215117 lands, we will have basic entry into the console. However autocompletion doesn't work because we don't attempt to load webconsole utils from the worker. We should probably break the JSPropertyProvider object into it's own file that's worker-safe so it can be loaded in that context.
This is blocked by Bug 1025778 since it's touching the same test that is refactored there
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Created attachment 8678331 [details] [diff] [review] console-autocomplete-worker.patch Summary of changes: 1) Did `hg cp devtools/shared/webconsole/utils.js devtools/shared/webconsole/js-property-provider.js` and then removed all non autocompletion stuff from the new file. This makes the diff here more noisy but it should preserve VCS history. 1a) I gave a workaround in the new file for when it's loaded in a worker (it doesn't try to load Parser.jsm in that case for matching strings, array literals, etc). I think if we switch to acorn for tokenizing instead in this case (bug 1217198) we can re-add that support in workers. 2) Removed all autocompletion stuff from utils.js Note this won't apply without the patches from Bug 1025778 and Bug 1215117 applied (both of which are in review). The test changes are in a part 2 patch
Attachment #8678331 - Flags: review?(nfitzgerald)
Created attachment 8678335 [details] [diff] [review] console-autocomplete-worker-2.patch Summary of changes: 1) Add a mechanism in /shared/webconsole/test/common.js to attach a console to a worker. Since this ended up adding yet another random param to attachConsole (yuck), I pulled this out into a few functions that smooth over that (attachConsole, attachConsoleToTab, and attachConsoleToWorker) 2) Pull the autocompletion stuff out from test_jsterm.html and into a new test_jsterm_autocomplete.html 2a) Part of this required changing the setting of top.foo into a string to be evaluated by the webconsole so we could modify the global state in a worker as well for testing 2b) This new test now runs two configurations, once in a tab and once in a worker just to make sure that's working.
Attachment #8678335 - Flags: review?(nfitzgerald)
Comment on attachment 8678331 [details] [diff] [review] console-autocomplete-worker.patch Review of attachment 8678331 [details] [diff] [review]: ----------------------------------------------------------------- (In reply to Brian Grinstead [:bgrins] from comment #2) > Created attachment 8678331 [details] [diff] [review] > console-autocomplete-worker.patch > > Summary of changes: Thanks, this helped with the review a lot!
Attachment #8678331 - Flags: review?(nfitzgerald) → review+
Attachment #8678335 - Flags: review?(nfitzgerald) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox44: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
Had to back this out from aurora since it was causing a super frequent to perma fail like https://treeherder.mozilla.org/logviewer.html#?job_id=1424858&repo=mozilla-aurora
(In reply to Carsten Book [:Tomcat] from comment #8) > Had to back this out from aurora since it was causing a super frequent to > perma fail like > https://treeherder.mozilla.org/logviewer.html#?job_id=1424858&repo=mozilla- > aurora I've been looking into this, and it's a mystery why this only happens on Aurora builds. Getting around 30% failure at: https://treeherder.mozilla.org/#/jobs?repo=try&revision=998571acb4b5. Leaving ni? flag open
I have an aurora simulation on the latest m-c and with a bunch of retriggers I'm not seeing this error anymore: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5361bf67b9a2&selectedJob=14429923. So hopefully we won't see this again when the merge happens.
You need to log in before you can comment on or make changes to this bug.