The "active-tab" view isn't enabled when using the devtools panels
Categories
(DevTools :: Performance Tools (Profiler/Timeline), defect, P1)
Tracking
(firefox94 fixed)
Tracking | Status | |
---|---|---|
firefox94 | --- | fixed |
People
(Reporter: julienw, Assigned: julienw)
References
Details
Attachments
(4 files)
STR:
- Open the new performance panel in the devtools toolbox
- Select the "Web developer" preset
- Start a profile and capture it.
=> The profile view should be configured with the "active tab" view. This is visible because in this case there's a "Full view" button at the top right.
This is working when using the popup (from Firefox' toolbar) but not from the devtools panel. This is also an issue in a remote debugging setup.
In the remote debugging setup we also need to take care that we use the same preset information as the one used when sampling, when deciding which view to configure.
(I don't remember if we take it from the debuggee or the debugger, that's why I'm not more assertive here).
Assignee | ||
Updated•4 years ago
|
Comment 1•3 years ago
|
||
Nazim and I also noticed oddness around this in https://phabricator.services.mozilla.com/D120158#inline-664969
The devtools panel never initializes the redux state profilerViewMode and also doesn't update it when the preset changes.
Maybe profilerViewMode shouldn't be in the state at all, and instead it should be computed from the preset when the profile is captured. That's what the popup does: https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/devtools/client/performance-new/popup/background.jsm.js#222-237
Assignee | ||
Comment 2•3 years ago
|
||
The devtools panel never initializes the redux state profilerViewMode and also doesn't update it when the preset changes.
Actually, more than this: when the user changes things in about:profiling, the devtools panel doesn't know about it.
This is something I want to fix soon.
Maybe profilerViewMode shouldn't be in the state at all, and instead it should be computed from the preset when the profile is captured.
I'll have to look at why we were doing this at first :-)
Comment 3•3 years ago
|
||
Maybe profilerViewMode shouldn't be in the state at all, and instead it should be computed from the preset when the profile is captured.
I think this would be the cleaner way to do this.
Comment 4•3 years ago
•
|
||
Hi Julien, just to make sure: this issue should only block removing the old panel and doesn't need to block enabling the new performance panel in Release (which would be Bug 1693316) ?
Assignee | ||
Comment 5•3 years ago
|
||
Yes indeed, wrong blocked bug!
Assignee | ||
Comment 7•3 years ago
|
||
Looks like I already analyzed this in duplicate bug 1716837 comment 1. Looks like I got the same conclusion than Markus too :-)
Assignee | ||
Comment 8•3 years ago
|
||
Assignee | ||
Comment 9•3 years ago
|
||
Assignee | ||
Comment 10•3 years ago
|
||
Depends on D125099
Assignee | ||
Comment 11•3 years ago
|
||
Depends on D125100
Assignee | ||
Comment 12•3 years ago
|
||
Depends on D125101
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/274612e0e043
https://hg.mozilla.org/mozilla-central/rev/28c5e05f3b1d
https://hg.mozilla.org/mozilla-central/rev/7949bfd8c19a
https://hg.mozilla.org/mozilla-central/rev/471e66a80360
Description
•