Closed Bug 1717724 Opened 5 months ago Closed 1 month ago

Stop "attaching" the console

Categories

(DevTools :: Console, task)

task

Tracking

(firefox95 fixed)

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

We are still having an async initialization of the console front which prevent notifying about new targets right away, as soon as we receive them from the backend:
https://searchfox.org/mozilla-central/rev/f351e19360729b351bfc7c1386d6e4ca4ea676e2/devtools/client/fronts/targets/target-mixin.js#455-472
This cause various sort of race condition and complexify the implementation of TargetCommand.
Now that the target are created by the server, any "attach" sequence should be done automatically by the server.

We still do call startListeners for populating console front traits, but that's not important enough to justify an async sequence for target-available.

I don't know how this bug ended up being flaged as security issue, but I did not meant that. It is just a code cleanup...
And it looks like I'm not able to make it become a regular non-security bug :/

Group: firefox-core-security

This has been introduced in Fx 80 via bug 1546394
and can now be considered as default backend API.

Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED

This code in TargetMixin was only used the Toolbox.
Let's avoid one unecessary onion layer.

This depends on calling startListening, which forces target to be attached asynchronously.
Also, we would like to stop calling startListening as it has been replaced by watchResources APIs.

If we ever need a trait, we should rather use RootActor one,
as it is easy to read by any code. Or we should come up with something
more robut and more generic that this startListening setup.

This is one step forward removing target attach sequence on the client side.
So that we can notify about target front immediately from TargetCommand.

I had to tweak TargetMixin destroy to avoid failures in browser_dbg_listtabs-01.js
a call to targetFront.reconfigure was never resolving, because the target destroy
was stuck on this call to detach().
We were trying to call detach() while the descriptor was destroyed (from a server side notification).
The target being a child of descriptor it ends up destroy itself, but the request is meant to fail.

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:ochameau, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(poirot.alex)
Flags: needinfo?(nchevobbe)

Still investigating a fix for a failure on try.

Flags: needinfo?(poirot.alex)
Flags: needinfo?(nchevobbe)
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/834cd0d8904e
[devtools] Remove blockedUrls traits. r=nchevobbe,devtools-backward-compat-reviewers
https://hg.mozilla.org/integration/autoland/rev/4d5a1c14ff7f
[devtools] Listen to inspectObject console actor event directly from the toolbox. r=nchevobbe
https://hg.mozilla.org/integration/autoland/rev/23fb782c56f1
[devtools] Remove web console actor traits. r=nchevobbe,devtools-backward-compat-reviewers
https://hg.mozilla.org/integration/autoland/rev/3a7d451c6098
[devtools] Remove attachConsole sequence. r=nchevobbe
Regressions: 1736824
You need to log in before you can comment on or make changes to this bug.