Can't disable remote profiler after devtools.performance.new-panel-enabled setting was removed

[ianknowles]

I have no interest in using a web app in my workflow, it doesn't even run under the strict security profile.

Previously it was simple to disable with the devtools.performance.new-panel-enabled setting. Need a way to disable it again.

[mstange]

How do you enable the strict security profile?

You can disable the performance panel in the devtools preferences:

[ianknowles]

about:preferences#privacy strict, but thats off topic.

No I don't want to disable the profiler I want to disable the web app and use the local one.

[mstange]

For what it's worth, the other devtools are also web apps. They just don't look like web apps because they don't run in a tab. They run in a more privileged environment. So banishing the profiler into a tab really makes it run in a more secure / less privileged context than before.

The local profiler has been removed.

[ianknowles]

I'm well aware they are web apps, but they don't fetch insecure resources across the network to run and require me to be online constantly, given they are bundled with the browser. I should have referred to it as "remote profiler".

[ianknowles]

So banishing the profiler into a tab really makes it run in a more secure / less privileged context than before.

If thats really a justification for moving it out of dev tools, which I'm not convinced of at all, then why can't it be bundled and run at about:profiler? The only workaround seems to be deploying it myself on localhost, which is maybe worth doing to avoid having to switch to chrome, but its more setup than i'd like to do just to get at the profiler.

[mstange]

but they don't fetch insecure resources across the network to run

That is true.

and require me to be online constantly,

We try to mitigate this with a service worker. If you visit profiler.firefox.com once, it will be cached locally and will work even if you are offline.

If thats really a justification for moving it out of dev tools,

It's not the reason why we did it, no; the reason we did it is because it allows for a faster update cadence that's independent of the release cadence of Firefox.

why can't it be bundled and run at about:profiler?

In theory it could be. But it would mean that it would take a long time for profiler improvements to hit the release audience. It might also require a less ergonomic workflow for us as the developers of the profiler, but that's not really relevant to you.

[ianknowles]

Those are good reasons for the default to be remote, which was the situation up to now, but some of my projects require a secure testing enivonrment in case of data leakage, and sometimes I'm just offline. I personally need a local option, and I think it makes sense for the project as a whole to have a local fallback option available, even if it means having to install a plugin to get it.

[mstange]

That makes sense. @julienw @canova What are your opinions on shipping a snapshot of profiler.firefox.com with Firefox on about:profiler and making that the default "profiler base URL"?

[ianknowles]

I'm ok with having to change the base URL over myself and I think you have good reasons for the default being set to remote, but having a snapshot version available would be great.

[julienw]

That makes sense. @julienw @canova What are your opinions on shipping a snapshot of profiler.firefox.com with Firefox on about:profiler and making that the default "profiler base URL"?

For quite some time I was wondering about shipping Firefox with a prepopulated service worker with whatever version is currently deployed at build time, but I'm not sure if this is practical with our current build system.

Shipping a snapshot in about:profiler could be a good workaround, except this means another (quite different) environment to test with, and that we'll need to update it regularly in-tree. That's a lot of work. I would not make it the default, unless we'd have an UI to switch the default to the deployed version easily.

Another option, as @ianknowles mentioned, would be to run it locally. Maybe we could ship a docker image of the profiler so that running it locally (or anywhere actually) would be easier for the folks that really need it?

The current situation is less than ideal when the first run is offline: I believe we only get a network error without any more information about it. It could be at least a good idea to explain the situation better in that case...

[canova]

Yeah, I agree that we should do a better job at handling the offline users.

I think it makes sense to add the snapshot of Firefox Profiler to Firefox. But like Julien said, it's a bit tricky to sync the github repos with mozilla-central. IIRC, there were some bots to do this syncing between servo/webrender repos with mozilla-central. I think it may be possible to reuse some of these things. But I'm pretty sure we'll need some approval to add this type of syncing.

Maybe we could ship a docker image of the profiler so that running it locally (or anywhere actually) would be easier for the folks that really need it?

I like the idea of having a docker image. I think it's pretty useful to have one, but I don't think docker image and in-tree syncing need to be mutually exclusive. We can have both. Possibly the docker would be sooner since it's less work.