1497728 - Show recent edits in about:config or keep a list of favorites

Status: NEW

(Toolkit :: Preferences, enhancement, P5)

Comment 1

[:Paolo Amadini]

There are a few common user stories that emerged with the redesign of "about:config" that may benefit from a list of "most recently used"
preferences. There is definitely some overlap in the roles who may find a use for it, but for clarity they can be simplified as follows:

1. As someone working on webcompat or QA, I would like to remember which preferences I have toggled in the profile I'm testing with.
2. As someone who provides technical support in person to friends or colleagues, I would like to remember which preferences I have toggled in the past.
3. As a developer currently working on a particular feature, I would like easy access to multiple preferences related to it.
4. As someone who provides technical support remotely, I would like to know which preferences have been reset or toggled manually from about:config.
5. As a user who has followed online instructions to change a preference, I would like to find it again even if I lost the original article.

The solution in this bug addresses these without requiring a substantial amount of new UX, and considers some additional use cases that some people may find useful, whether they provide general value or not:

6. I would like to curate my invariable list of preferences that I can easily toggle.
7. I always disable "most recently used" lists.

By storing the list of recently used preferences in a preference, it can be very easily included in "about:support" to enhance user story number 4. However, a default limit in the number of items remembered would be set, so the preference wouldn't impact preformance.

Comment 2

[:Paolo Amadini]

Attachment: Bug 1497728 - Show recent edits made in the new "about:config" page.

Comment 3

[:Paolo Amadini]

Attachment: Rough mockup

This is a rough mockup of "recent edits", which is a subset of "favorites" minus the user interface to add and remove specific items from the list. I don't have plans to work on this in the immediate future, but it can be a starting point.

There is a preference that stores the list, and another one to lock it so that it can be turned into a manually curated list of favorites. In this version, editing any other preference updates the list preference immediately, which may move the results unexpectedly. Deferring the preference update to the "unload" event may fix this issue.

Comment 4

[:Paolo Amadini]

I'm resetting the status set by automation on the bug because, while I would like to continue at some point, I may not have much time available for a while, and tests still have to be written. I can still answer questions if anyone wants to work on this in the meantime.

Comment 5

[:Paolo Amadini]

Jared, can you recommend a storage mechanism for the list of recently modified preferences? In the proof of concept patch I used a preference, however Gijs points out that it would be synchronized to other processes, impacting performance. On the other hand, if "about:config" at some point moves out of the parent process, this synchronization may be useful.

One strong limitation is that "about:config" works synchronously, and tests rely on that, so at last the retrieval would need to be synchronous.

I think we might consider making this list of preference names also visible from "about:support", which I'm mentioning here because we may need a storage system that is not keyed by the URL of the page.

One advantage of using a preference is that it would be editable, more easily supporting user stories "6" and "7" from comment 1 (together with the option to "lock" the list) by editing or resetting the preference itself. Since these user stories are secondary, I would try to avoid adding any dedicated user interface for them. This means that, if we store the data elsewhere, users who want to curate the list may have to use snippets in the Developer Console to modify or clear it.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Sorry for the delay. I think preferences are the best that we have, but the performance implications pointed out by Gijs are real and shouldn't be ignored.

I think the best path forward is adding metadata to preferences that will store when they were last updated. This metadata doesn't have to be synced to each process and could be requested through a separate API. It can also be written to asynchronously to limit performance regressions.

Comment 7

[Matthew N. [:MattN]]

Bug 1502867 seems to have a much lower cost with a similar benefit (according to use cases comment 1) so it makes more sense to me to fix that rather than add new advanced functionality to a UI users rarely use.

Comment 8

[Matthias :Kammueller]

Hi! I'm back to working on about:config after a few years :D
Is there still interest in including this feature? Would adding tests to Paolo's draft suffice or should the metadata be available via an API call?
Thanks!

Comment 9

[Ed]

Seems worth pursuing. I'm in the #s 2, 4, and 5 categories; mostly #4.

Comment 10

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jhirsch, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Is there still interest in including this feature? Would adding tests to Paolo's draft suffice or should the metadata be available via an API call?

Hey there, note that :jaws is currently inactive.

UX has been talking about wanting to improve the settings page for a while, but I don't know that there is anything planned to improve about:config itself. Seems like it would be worth taking the patch. Gijs, any thoughts?

:Kammueller, while we wait for Gijs to provide feedback, note that there is some unaddressed review feedback on the existing patch, and it will also need to be brought up to date with latest m-c. Does that unblock you for now?

Comment 12

[:Gijs (he/him)]

(In reply to Jared Hirsch [:jhirsch] (he/him) (Needinfo please) from comment #11)

UX has been talking about wanting to improve the settings page for a while, but I don't know that there is anything planned to improve about:config itself. Seems like it would be worth taking the patch. Gijs, any thoughts?

I'm not aware of anything. We'd want to file a UX request to see if there was interest in doing this. Can you file something using https://mozilla-hub.atlassian.net/jira/secure/CreateIssue.jspa?pid=10357&issuetype=10059 ? (unfortunately that's a moco intranet link. :-( )

Comment 13

[Matthias :Kammueller]

General note: I started a job where I can contribute to open source projects every fourth Friday, I'd like to spend that time working on about:config -- since I was part of the student team that redesigned it a few years ago, so I'm fairly familiar with this.
If you already file a UX ticket, I would also like to introduce the sidebar I included in the mocks back then, cf. https://kammueller.github.io/new-config/index.html I thought we created a bugzilla ticket for that back in the day, but apparently we did not..

But yeah, in general this enables me to work on this ticket :)

Comment 14

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

OK, I'll file a UX request for the feature described in this bug, and the sidebar idea too. I'll update the bug when I get a response; I would guess the UX team will be too busy to provide input, but we'll see.

I've learned there is UX interest in eventually restyling about:config to make it more uniform with the other about pages, but this is a lower priority item. And anyway, reskinning a page shouldn't block adding some potentially useful functionality to it.

:Kammueller, I've assigned the bug to you. have fun and needinfo me if you get stuck or need anything.

Comment 15

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

For reference, the internal UX jira ticket is https://mozilla-hub.atlassian.net/browse/UXREQ-209

Comment 16

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Also, it looks like what's in the mockup is pretty different from what's in the description and in the existing patch. It would be fine with me to start over with a new patch.

Comment 17

[Matthias :Kammueller]

Hi Jared,
while starting to work on this bug, :defaude and I found out that the current code is not very maintainable:

• Week separation of concerns (e.g., data fetching / observing, filtering, rendering visible preferences, ...)
• The rendered DOM is potentially too complicated/deep
• Nested complex functions make it hard to understand the data flow

We started to refactor parts of the code but wondered whether it wouldn't be more efficient to simply re-write the page with a cleaner structure. In a first step we'd try to reconstruct the current DOM, and maybe simplify it in a second step.

What is the best way to proceed? Should we file another ticket for this?

Comment 18

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Hey there,

I'm not sure rewriting and redesigning about:config is a reasonable path forward without input from UX.

I think the best next step here is to set this bug aside and wait to hear back from UX before going any further. I'll bump the internal UX ticket today and update this bug when I hear back.

In the meantime, if you'd like to contribute to other parts of the Firefox front-end, have a look at our good-first-bug list: https://codetribute.mozilla.org/projects/ff

Comment 19

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Hey again,

Your ideas got positive feedback from UX management:

These are great ideas! UX does not have any plans for about:config. I’d be happy to set up a design review checkpoint if this project moves forward. We cannot partner or staff it beyond a review checkpoint, but we support this work.

If you're still interested in improving about:config, and if you're willing to work with our existing codebase ;-), I think we should be able to take a parallel approach on two tracks: first, create a plan for an initial round of work here, and submit that through whatever design review process UX has in place (I'll need to look this up); second, while we wait for UX to review the plans, we can look through the existing about:config bugs and find you some good first bugs to help you warm up with this part of the codebase.

How does this plan sound to you?

Comment 20

[Matthias :Kammueller]

Hi Jared,
thanks for asking around! Sounds good!
I have some slack time next Friday and would start working on a road map and maybe a mock-up. (I created a dummy ages ago, maybe it's time to update that)

First step will probably to refactor the current code-base a little bit (not too much) to make editing it a bit easier.
Bug 1889914 is a bug we found along the way and might also be a good first place to start.