[Affected versions]:

Nightly 68.0a1 (as client-profile) <-> Nighlty 68.0a1 (as server-profile)

[Affected platforms]:

Ubuntu 16.04
Windows 10
Mac 10.14

[Steps to reproduce]:

1. Open a Nighlty as a client profile then using the Terminal commands to open as well a Nightly server profile.
2. On Server profile, go to Inspect Elements -> Settings-> scroll down until the "Advanced settings" section -> check the last two boxes(specially the last one - "Enable new performance recorder...").
3. Go to client profile -> about:debugging page and make a localhost connection.
4. Then form Tabs or Extensions click on any INSPECT button.

Expected results: In the about:devtools-toolbox page, among the others tabs should be the PERFORMANCE one.

Actual results: The PERFORMANCE tab doesn't appear on about:devtools-toolbox page. - see attached video link: https://streamable.com/3d6h9

• In case that we have enabled on both side (CLIENT & SERVER)->the new-performance checkbox, the issue will occur.

Note:

1. It is a quite confusing situation because if the checkbox, the one explained at step 2, will not be enabled => the issue won't occur.

@Julien, Due the scenario from the description, which is the correct/intended behavior? => To have on the CLIENT & SERVER side the checkbox with "new performance recorder" unchecked? Which will be the scenarios for testing - to have checked this box on Client or on Server?

(the screencast is just showing a desktop?)

This setting only affects the client, changing DevTools settings on the server instance has no impact. The display of the performance tab is only impacted by the settings on the client firefox (the one where you start about:debugging).

If you have "Enable new performance recorder" checked on the client Firefox, then the performance tab is not displayed for remote debugging. But you need to close and reopen about:devtools-toolbox to see the change ("then re-open DevTools").

which is the correct/intended behavior? => To have on the CLIENT & SERVER side the checkbox with "new performance recorder" unchecked? Which will be the scenarios for testing - to have checked this box on Client or on Server?

This checkbox is only displayed on Nightly (and is not riding the trains), so for remote debugging testing you should always test with the checkbox unchecked, it's what users will experience on Beta/DevEdition/Release.

I guess we could always force the old performance panel when doing remote debugging, but again this issue is Nightly channel only, so low priority in my opinion.

Hi @Julien, what I'm trying to say is that, no matter the place (CLIENT or SERVER) where I do the change (checking the option "new performance recorder") the effect/impact is the same => the issue can be reproduced.

(In reply to Liviu Seplecan from comment #3)

Hi @Julien, what I'm trying to say is that, no matter the place (CLIENT or SERVER) where I do the change (checking the option "new performance recorder") the effect/impact is the same => the issue can be reproduced.

Happy to go through this on vidyo, please ping me on slack.

Ok discussed a bit with Hani, and the scenario I have to reproduce your issue is:

• open SERVER firefox
• in SERVER open a tab TAB1
• in TAB1 open devtools settings
• in TAB1 enable new performance recorder
• close TAB1
• in SERVER open a tab TAB2
• open client firefox
• in CLIENT open about:debugging
• connect to TAB2

Then the performance panel will be disabled.

I think the reason for this particular issue is that we are not starting the performance actor on the server side the new performance panel is enabled:

https://searchfox.org/mozilla-central/rev/ee3905439acbf81e9c829ece0b46d09d2fa26c5c/devtools/server/actors/utils/actor-registry.js#197

    if ("nsIProfiler" in Ci &&
        !Services.prefs.getBoolPref("devtools.performance.new-panel-enabled", false)) {
      this.registerModule("devtools/server/actors/performance", {
        prefix: "performance",
        constructor: "PerformanceActor",
        type: { target: true },
      });
    }

Julien: In theory devtools.performance.new-panel-enabled is a client-side preference (and it's not available on Android for instance), so I don't think it should drive registering the performance actor on the server. If the client is not using the performance actor because it only uses the new panel, there shouldn't be any overhead in having the actor registered and ready to go? Is there another reason why we absolutely want to avoid registering the actor here?

I filed bug 1507459 some months ago, so I completely agree with you :-)

Ah thanks, will submit a patch for the other bug then. Can't think of a good way to test this for now though.

After Bug 1507459 landed, the display of the performance tab should no longer be influenced by the value of the preference on the server side. Should we close this bug?

Hi @Julian Descottes, I've tried to re-test the scenarios from comment 5 attempting to verify if the Performance tab appears. Doing that, I cannot saw the connection message approval("OK" or "Cancel"). I will attach two screenshots to see how it looks.

You wrote "locvalhost" instead of "localhost" :)

Sorry for previously attachments

I will check some scenario and return with the details

Hmmm, local network debugging still work I have used it on latest central.Did you check the port was the good one?

I can help you debug your issue, but Bugzilla's not the place to do that, please contact me on slack?

Finally, I could re-test the scenario - on my end the Performance tab appears properly by enabling the new performance recorder option from devtools inspector.

The priority flag is not set for this bug.
:jdescottes, could you have a look please?

For more information, please visit auto_nag documentation.