We currently don't allow to use the new performance panel from the Browser Toolbox because the overhead from the DevTools server severely impacts profiles.

So when the old performance panel is removed, we should remove the performance panel entry completely from the available panels in the Browser Toolbox.

We could also decide to:

• show a message in settings to suggest users to use the profiler button instead
• keep a static panel which would also show such a message

if we are concerned about Browser Toolbox users being confused with this.

I thought we were already hiding the performance panel in the Browser Toolbox, but Alexandre added it back so that the browser toolbox itself can be profiled (bug 1764505).

So I think this bug could be closed wontfix, what do you think Julian?

I wasn't aware of bug 1764505. As mentioned in the bug, the behavior feels confusing. Every tool from the Browser Toolbox is about debugging the original Firefox instance, but the performance panel is debugging the Browser Toolbox itself. That feature is only useful to the DevTools team so I find it a bit odd.

I won't close it immediately, let's discuss this again once everybody is back.

My understanding from looking at this with Alexandre is that the performance panel in the browser toolbox targets the same Firefox instance than other panels, as expected by users. To debug the browser toolbox itself, we need to open the browser toolbox again from the browser toolbox. That's why I was OK with this.
But it's possible we missed something.

I see, we didn't implement what is described in the bug.

As said in the summary of https://phabricator.services.mozilla.com/D143566#4710663, the performance panel of the first toolbox is irrelevant and should not be used. The reason is that if you use that to profile Firefox, you get the massive overhead of the devtools server spawned for the Browser Toolbox.

the performance panel in the browser toolbox targets the same Firefox instance than other panels, as expected by users.

Except no one should use it :) So I think this bug is still relevant, we should not encourage Firefox engineers to use the performance panel from the first BT.

I was assuming that our existing workarounds to create profiles was sufficient here (ie start a browser window from the BT application and use the button there).

And even from the point of view of profiling the BT, having to start another devtools server to have a second toolbox means more overhead for the profile?

(In reply to Julian Descottes [:jdescottes] from comment #4)

I see, we didn't implement what is described in the bug.

As said in the summary of https://phabricator.services.mozilla.com/D143566#4710663, the performance panel of the first toolbox is irrelevant and should not be used. The reason is that if you use that to profile Firefox, you get the massive overhead of the devtools server spawned for the Browser Toolbox.

yeah, that was my comment, but as Alexandre said this was in his opinion a bit complicated compared to the goal. But you should discuss this with Alexandre.

the performance panel in the browser toolbox targets the same Firefox instance than other panels, as expected by users.

Except no one should use it :) So I think this bug is still relevant, we should not encourage Firefox engineers to use the performance panel from the first BT.

yeah, we were assuming that the firefox engineers would know about the other flow better and wouldn't use it. Were we naive? Maybe :-)

I was assuming that our existing workarounds to create profiles was sufficient here (ie start a browser window from the BT application and use the button there).

I didn't know about this trick.

(In reply to Julian Descottes [:jdescottes] from comment #5)

And even from the point of view of profiling the BT, having to start another devtools server to have a second toolbox means more overhead for the profile?

Probably some overhead but not more overhead than usual, because the profile is only about the firefox instance containing the first toolbox, so it's not "another devtools server".

Discussed in the meeting, we are closing this bug.

Note about the overhead discussion: the Browser Toolbox always creates its own server, which is much heavier (to serve all the panels) than what we need only for the profiler. That's exactly why we removed the performance panel for remote debugging.

But hopefully the server for the second browser toolbox should not be too intensive.