ui: restore every probe setting when loading a record config - #7348
Open
LalitMaganti wants to merge 1 commit into
Open
ui: restore every probe setting when loading a record config#7348LalitMaganti wants to merge 1 commit into
LalitMaganti wants to merge 1 commit into
Conversation
🎨 Perfetto UI Builds
|
LalitMaganti
force-pushed
the
dev/lalitm/record
branch
from
September 6, 2026 20:37
240ac75 to
009ff3c
Compare
Selecting a preset (or a saved config) only overwrote the settings that the config mentioned. Everything else kept whatever the user had last set, because deserializeProbes() iterated the settings present in the config rather than the settings the probes declare, and because a setting's deserialize() ignored an input it didn't like instead of going back to its default. That is how #7347 happens: the "Advanced ftrace config" probe is not part of any preset, but cpu_sched pulls it in as a dependency, so re-selecting the default config left the ftrace buffer size and the "resolve kernel symbols" toggle at the values the user had typed, and they showed up in the generated TraceConfig. The same held for every other probe outside the loaded config, whose stale values would come back as soon as the probe was re-enabled, and for clearSession(), which cleared nothing. Make deserialize() total: it must always end up setting the value, using the default when the serialized state is missing or malformed. For the sliders, toggles and textareas that is what their setValue(undefined) & co. already meant, so they just route through it. deserializeProbes() then walks the settings each probe declares and hands each one the value from the config or undefined, which restores the default. This also fixes a second instance of the same bug: the Chrome presets store their categories in the legacy list-only format, whose back-compat path used to leave the tags, the presets and the privacy toggle at the values from the previously loaded config. Adds a test that reproduces #7347 through the generated TraceConfig, plus a generic one asserting that loading a config lands on exactly the same state as loading it on a fresh record page, whatever was there before. It walks every registered probe and every setting, including those of the disabled probes that serializeProbes() cannot see, so probes added later are covered too, and it fails for any setting whose deserialize() is not total. Fixes: #7347
LalitMaganti
force-pushed
the
dev/lalitm/record
branch
from
September 6, 2026 20:39
009ff3c to
040629c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7347