After opening the omniscient browser toolbox, the threads list in the debugger pane shows all the content processes which existed when the toolbox was opened. Creating new tabs (which spawns new processes), or closing tabs (which terminates those processes) does not cause the threads list in the debugger to update. This issue affects other panels as well. For example, the console panel doesn't show messages from processes which did not exist when the toolbox was first opened.

We know about that. We are planning to have a new API to easily listen for tabs, processes, workers, ...
The existing listFoo + fooListChanged doesn't scale.
I'm planning to resume Yulia's work next week.

(In reply to Alexandre Poirot [:ochameau] from comment #1)

We know about that. We are planning to have a new API to easily listen for tabs, processes, workers, ...
The existing listFoo + fooListChanged doesn't scale.
I'm planning to resume Yulia's work next week.

*** This bug has been marked as a duplicate of bug 1548557 ***

Will you be offended if I work on this anyways? The OBT feels pretty broken without this and the lack of this functionality makes it hard to build other features that care about listening to different processes, e.g. bug 1563607. The APIs to list processes and listen to them already exist, and leveraging those to get more-correct behavior here shouldn't be hard. Bug 1548557 would then be a cleaner and more efficient replacement for the existing functionality, rather than something we have to wait on in order to make progress elsewhere.

This patch updates the the threads list in the debugger and the connection proxies used by the webconsole when the ODB is used and new content processes are created. The threads list is not updated when content processes are destroyed, due to bug 1586468 (another advantage of fixing the ODB now is that it can surface bugs like this and allow fixing them earlier).

Depends on D48245

(In reply to Brian Hackett (:bhackett) from comment #2)

Will you be offended if I work on this anyways? The OBT feels pretty broken without this and the lack of this functionality makes it hard to build other features that care about listening to different processes, e.g. bug 1563607. The APIs to list processes and listen to them already exist, and leveraging those to get more-correct behavior here shouldn't be hard. Bug 1548557 would then be a cleaner and more efficient replacement for the existing functionality, rather than something we have to wait on in order to make progress elsewhere.

I do understand your frustration of facing broken usecases in the OBT.
It is just that everyone in the team is aware of these limitations, as it is part of the plan and everyone is working according to it.

I would appreciate some effort to better work as a team. Understand what is the plan and actively collaborate to it instead of working around.
I see duplicated time spent on modifying and reviewing the exact same code twice.

You will see in bug 1548557, that I'm modifying the exact same lines.

Should we close Bug 1567834 as dupe (or repurpose it to add test maybe ?)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #8)

Should we close Bug 1567834 as dupe (or repurpose it to add test maybe ?)

I've written a test for this, which I included in bug 1444064 because it depends on the browser toolbox testing logic added there. I'll split the test off into a separate patch though and ask for your review.

https://hg.mozilla.org/mozilla-central/rev/c3215c53a2ea
https://hg.mozilla.org/mozilla-central/rev/ae88bc6b6e18