Enable console message listening from the server side for tab targets
Categories
(DevTools :: Console, enhancement)
Tracking
(Fission Milestone:M6c, firefox81 fixed)
| Tracking | Status | |
|---|---|---|
| firefox81 | --- | fixed |
People
(Reporter: ochameau, Assigned: jdescottes)
References
(Depends on 1 open bug, Blocks 2 open bugs, Regressed 1 open bug)
Details
(Whiteboard: dt-fission-m2-mvp)
Attachments
(8 files)
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
image/png
|
Details | |
|
(deleted),
image/png
|
Details |
actual.png
Bug 1620243 will land all the necessary code to listen for console messages via the ResourceWatcher API and the WatcherActor.
But this new code isn't enabled by default yet. The traits to enabled it on the WatcherActor is false.
This is to allow changing the server API/behavior without thinking about backward compat.
But we should toggle this to true by default and get rid of the old codepath eventually.
Before enabing it, we should:
- digest this new code a bit, to see if there is any esthetical change to be made,
- investigate network event and/or storage resource listening. There resources have to be listened from the parent process and may require some API changes,
- and may be also try converting one another resource, by someone else than me, to see if there is any improvement to be made to the public API of the WatcherActor.
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 1•4 years ago
|
||
Note: we should remove some code from devtools/server/actors/resources/console-message.js:onLogPoint that used to support the case where we aren't using the WatcherActor and have a logpoint.
|
||
Comment 2•4 years ago
|
||
Tracking dt-fission-m2-mvp bugs for Fission Nightly milestone (M6c).
|
|
Reporter | |
Updated•4 years ago
|
|
Assignee | |
Comment 3•4 years ago
|
||
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 4•4 years ago
|
||
Depends on D86960
|
|
Assignee | |
Comment 5•4 years ago
|
||
Depends on D86961
|
|
Assignee | |
Comment 6•4 years ago
|
||
Depends on D86962
|
|
Assignee | |
Comment 7•4 years ago
|
||
Depends on D86963
Just for reference for now, since this is incompatible with target switching.
|
|
Assignee | |
Comment 8•4 years ago
|
||
Depends on D86964
|
|
||
Updated•4 years ago
|
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a43868a44c5e Add missing Cu import in devtools/server/actors/object/utils.js r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/02b34e34605a Fix shouldHandleMessage signature in platform-message DevTools resource r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/d85ccd9b7e22 Fold clearCachedMessage from ConsoleServiceListener into WebConsoleActor r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/e51e4431b577 Do not check property order in WebConsole stub tests r=nchevobbe https://hg.mozilla.org/integration/autoland/rev/e2320c4219df Enable server side resource watching by default r=ochameau https://hg.mozilla.org/integration/autoland/rev/751c328cd945 Stop and start resource listening when switching targets r=ochameau
|
||
Comment 10•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a43868a44c5e
https://hg.mozilla.org/mozilla-central/rev/02b34e34605a
https://hg.mozilla.org/mozilla-central/rev/d85ccd9b7e22
https://hg.mozilla.org/mozilla-central/rev/e51e4431b577
https://hg.mozilla.org/mozilla-central/rev/e2320c4219df
https://hg.mozilla.org/mozilla-central/rev/751c328cd945
|
||
Comment 11•4 years ago
|
||
I noticed after this https://phabricator.services.mozilla.com/D86964 landed, I no longer see logs in the browser console while the multi processes debugger is open.
You can test it with a console.log in the debugger.
|
|
||
Comment 12•4 years ago
|
||
Trying to make this clear steps to test for what I'm hitting and how I test it:
- Using current master, and open it with the multi process debugger open, I do this via
./mach run --jsdebugger -Pthe--jsdebuggerpart is the important part, but I suspect there are other ways to open it, what's important though is the multi process debugger is open when you start the browser. - I created a new profile for testing this, but I suspect it doesn't matter.
- Once I'm in the browser, I open an about:home tab, but I suspect the page doesn't matter.
- From here I do ctrl+shift+k to open the browser console.
- Inside the console, I enter
console.log("hi");and hit enter.
Attaching expected and actual screenshots.
|
|
||
Comment 13•4 years ago
|
||
|
|
||
Comment 14•4 years ago
|
||
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
Description
•