Enable new Performance panel by default on Release
Categories
(DevTools :: Performance Tools (Profiler/Timeline), task, P3)
Tracking
(firefox98 fixed)
Tracking | Status | |
---|---|---|
firefox98 | --- | fixed |
People
(Reporter: Honza, Assigned: julienw)
References
Details
(Whiteboard: [fxp])
Attachments
(1 file)
When the new Performance panel is enabled in Nightly and beta we can wait for one cycle and enable it on the Release channel.
Honza
Reporter | ||
Comment 1•4 years ago
|
||
Might be blocked by some localization work
Comment 3•3 years ago
|
||
Let's make sure to update the logic in the devtools settings panels if we still want to allow users to revert to the old panel after enabling the new panel by default.
Assignee | ||
Comment 4•3 years ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #3)
Let's make sure to update the logic in the devtools settings panels if we still want to allow users to revert to the old panel after enabling the new panel by default.
This was done in bug 1722458, thanks Julian!
Assignee | ||
Comment 5•3 years ago
|
||
Hey Julian, do you think that we need to do something around https://searchfox.org/mozilla-central/rev/2aa97aea1085cf1363582725407c514833ad47e4/browser/components/enterprisepolicies/Policies.jsm#582-595 ? For example lock the pref that selects which performance panel we use ? Or other things ? I'm not used to this code, so I don't know really :-)
Thanks!
Comment 6•3 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #5)
Hey Julian, do you think that we need to do something around https://searchfox.org/mozilla-central/rev/2aa97aea1085cf1363582725407c514833ad47e4/browser/components/enterprisepolicies/Policies.jsm#582-595 ? For example lock the pref that selects which performance panel we use ? Or other things ? I'm not used to this code, so I don't know really :-)
Thanks!
I don't think so. We can ping mkaply for more info, but I think in general we allow a policy to disable devtools completely, but nothing finer than that.
Comment 7•3 years ago
|
||
Hi Julien, quickly reviewing the blockers here. Beyond the localization of presets, I didn't spot any issue while testing the panel. The profiler UI itself on profiler.firefox.com is not localized, but I assume we don't expect to change i
Comment 8•3 years ago
|
||
Nicolas: I just realized that with the new performance panel, console.profile()
was a no-op. As we would like to enable the panel on release, what do you think we should do when console.profile()
is used? Should we at least display a helpful message to the user?
Comment 9•3 years ago
|
||
ah, I didn't think about console.profile
.
I'd say we should try to keep it working in a similar fashion to what we have today in an ideal world. We could print the URL of the captured profile in the console.
Now, as I don't know how much time it would take, we could display a message when the pref is set to true, and print a message to the user saying that the new profiler does not support console.profile
for now, with a link to the bug for adding the support, and suggesting to turn off the pref?
It would be great if we could avoid that as this would block us from actually removing the old perf panel.
That being said:
console.profile
is not in the console spec (https://console.spec.whatwg.org/)- I don't know if it's much used
- with the old perf panel, it only works if you enabled the perf panel in the settings
- in Chrome, it does work, but the profile does not appear on their "Performance" panel, but on a JS Profile specific panel that you have to turn on from their settings
given all that, I suppose it would be okay if we don't have support for a while, but as always, people might rely on this and we would alter their workflow.
Comment 10•3 years ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #9)
ah, I didn't think about
console.profile
.
I'd say we should try to keep it working in a similar fashion to what we have today in an ideal world. We could print the URL of the captured profile in the console.Now, as I don't know how much time it would take, we could display a message when the pref is set to true, and print a message to the user saying that the new profiler does not support
console.profile
for now, with a link to the bug for adding the support, and suggesting to turn off the pref?
It would be great if we could avoid that as this would block us from actually removing the old perf panel
Thanks for the feedback! Your suggestion makes sense, let's file a bug for that.
Assignee | ||
Comment 11•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 12•3 years ago
|
||
Reporter | ||
Comment 13•3 years ago
|
||
This is great news, thank you for pushing this across this finish line, Julien!
Honza
Comment 14•3 years ago
|
||
🎉🎉🎉
Comment 15•3 years ago
|
||
bugherder |
Comment 16•2 years ago
|
||
Is the "old performance panel" available still in any way?
I have an MDN bug https://github.com/mdn/browser-compat-data/issues/19347 that asks whether FF supports console.profile
.
The evidence suggests that it isn't supported in the new performance panel added here in FF94 (and enabled by default in FF98).
IF the old performance panel is gone then presumably I can mark console.profile
as not supported in Firefox from FF98 right?
Assignee | ||
Comment 17•2 years ago
|
||
The old performance panel code has been completely removed in v102 (bug 1668219). Until then you could enable it from the devtools settings or a preference.
So maybe you could precise this in the MDN data?
Otherwise yeah it's not supported in the current versions of Firefox. Thanks for asking!
Comment 18•2 years ago
|
||
Thanks very much Julien! I have created https://github.com/mdn/browser-compat-data/pull/19387 , which just indicates removal of console.profile in FF102. I haven't tried to explain the history/preferences you might use between FF98 and FF101, because I don't think that is needed.
Updated•1 year ago
|
Description
•