Stop "attaching" the console
Categories
(DevTools :: Console, task)
Tracking
(firefox95 fixed)
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.
Assignee | ||
Comment 1•3 years ago
|
||
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 :/
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
This has been introduced in Fx 80 via bug 1546394
and can now be considered as default backend API.
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
This code in TargetMixin was only used the Toolbox.
Let's avoid one unecessary onion layer.
Assignee | ||
Comment 4•3 years ago
|
||
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.
Assignee | ||
Comment 5•3 years ago
|
||
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.
Comment 6•3 years ago
|
||
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.
Assignee | ||
Comment 7•3 years ago
|
||
Still investigating a fix for a failure on try.
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
Comment 9•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/834cd0d8904e
https://hg.mozilla.org/mozilla-central/rev/4d5a1c14ff7f
https://hg.mozilla.org/mozilla-central/rev/23fb782c56f1
https://hg.mozilla.org/mozilla-central/rev/3a7d451c6098
Description
•