1629110 - [about:profiling] Selecting a preset clears any custom configuration

Status: NEW

(DevTools :: Performance Tools (Profiler/Timeline), defect, P2)

Description

[Julien Wajsberg [:julienw]]

STR:

1. Go to about:profiling.
2. Change some settings. => the preset radio button moves to "custom". [OK]
3. Move back the radio button to one of the predefined presets. => The settings go back to what is defined by this preset. [OK]
4. Select the option "custom". => The settings stay thesame, they don't move back to the previous custom settings. [KO]

I think that at step 4 we should move back to the settings set in step 2. Otherwise it makes it difficult to use custom settings.

I believe the problem is that we overwrite the prefs when we select a preset. (happening in [1])
[1] https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/devtools/client/performance-new/popup/background.jsm.js#459

Note: I would be OK keeping this behavior if the user could create its own presets. But I believe this is more work (?).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 2

[Greg Tatum [:gregtatum]]

Moving this to the "polish" meta bug 1566920, as this was not specified in the original work. I'm also not sure the behavior of keeping the old preset is desirable, as it's nice to reset it to a known good configuration.

Comment 3

[Julien Wajsberg [:julienw]]

We discussed this during today's UX meeting, and this is the behavior we can do without too much change in our code:

STR 1:

1. The user selects a well-known preset.
2. The user changes some settings.

=> the preset moves to "custom" using the previously selected preset as a basis.

STR 2:

1. The user selects a well-known preset.
2. The user selects the "custom" preset.

=> The preset moves to "custom" using whatever was defined in the custom preset before.
If nothing was set yet, then it uses the current preset.

STR 1 makes it easy to reset to a known configuration, while STR 2 makes it more difficult to lose a carefully done custom configuration. (even if it can still happens).

We also discussed more interesting behavior:

• Being able to change default presets to "edited" versions of these presets
• They would have "save" and "reset" buttons for these operations.

While I find this very interesting I pushed back a bit because I think this would require changing quite a lot of our existing code.