Important Modified Preferences - by whom? Topic is solved

[back2themoon]

A thought about the Troubleshooting Information page and "Important Modified Preferences" section.

Always found it strange -and annoying- that there are many "important modifications" even at the browser default, untouched state. I know there is a valid reason here, even though the wording can confuse some users. That page is also meant for users too, I believe, not being a mere "send this all to support" technical log.

It'd be nice, less confusing -and actually help more with troubleshooting- to clearly separate what the user has modified, from all the rest. Just saying.

[Michaell]

Also (IMO) same applies to "user set" in about.config.

[moonbat]

Extensions may modify preferences as well, I use FoxyProxy for example, and it forcibly disables the DNS caching option.

[Gemmaugr]

That would be nice. I think I remember asking about having Addon changes be represented similarly, but apparently they at least don't work like that. Correct me if I'm wrong here.

[back2themoon]

Extension settings/additions are not listed there anyway (a good thing IMO). They can easily be filtered in about:config.

Extensions may modify preferences as well, I use FoxyProxy for example, and it forcibly disables the DNS caching option.

That is fairly rare I believe i.e. an extension touching the browser settings. This certainly falls under the "user changes" category, not the "in-built modifications" one.

[Moonchild]

The preferences system does not track or store how preferences were changed. In addition, because browser extensions are powerful, there is no real way for the browser to do so unless it would strictly limit interaction of extensions with preferences (which will be hard to do because of the power of XUL extensions) and become a nanny explicitly recording when it was a user's UI input action that resulted in a preference change and when it was some other reason, which would exactly be the kind of over-the-shoulder monitoring of users of a browser we do not want. A user's UI input actions are actually really hard to determine when preferences are often set through scripting (even in the preferences window).

So, if you see "user-set" it means it's "non-default", regardless of whether the user did so directly, whether an extension did it, or whether a browser-internal component did it. Since we already know the defaults for all preferences in our source, it only makes sense to report non-default preference settings. The "importance" of this is importance for troubleshooting purposes and should exclude some trivial preferences that would just clutter the report.

[back2themoon]

Quick example from a clean Pale Moon Portable (sse2 build). As a user, I have only modified one setting (green arrow):

Important Modified Preferences.png

[Moonchild]

Not sure why you think this is a problem. These preferences are used to store some information specific to your installation and running environment (that is important to report for troubleshooting). I.e. it will store some configuration specific to the portable environment (that is not running fully default because of that) as well as things detected and stored for future runs.

[back2themoon]

Not a problem per se, but it can be confusing for the user, especially with longer lists. The one attached here is the "clean", bare minimum. It can get much worse.

"What have I changed in here?"

Since we already know the defaults for all preferences in our source, it only makes sense to report non-default preference settings.

And this is what I am suggesting. Since all those defaults are already known (including the moving parts, like platform/OS/driver-dependent etc. - the ones you describe as "specific to your installation and running environment") then they could be moved away (not disappear) so the user-changed settings are isolated and clearly visible. In a separate paragraph/section or something.

You, the expert, can easily tell which they are. The user cannot.

[Moonchild]

Once again, reporting the changed preferences even if not manually done so by the user is important to know. The troubleshooting information is primarily for people knowledgeable in the browser, anyway.
I get the wish to know by the user what a user might have changed manually, but as explained that's not possible without massive changes to the preferences system, and having it become a nanny or at the very least a lot more intrusive storing a bunch of extra information and making every call to preference storage pass a flag from where it was changed.

[back2themoon]

Understood, but perhaps we got a bit confused.

I thought your "nanny" comment was about drastically changing the prefs system to also deal with extension changes. I never suggested that, so let's forget about extensions.

"...reporting the changed preferences even if not manually done so by the user is important to know." - Never suggested to hide them.

I'll approximately visualize what I mean, so this is entirely clear:

Important Modified Preferences

accessibility.typeaheadfind.flashBar 0
browser.cache.disk.capacity 358400
browser.cache.disk.enable false
(etc.)

Important User-Modified Preferences

gfx.direct2d.disabled true
(etc.)

This is it. If you are saying that this would still require "massive changes to the preferences system" then it's perfectly fine as it is. I just thought that since you already know that "gfx.direct2d.disabled" does NOT belong in your known "specific to your installation and running environment" entries and its default status has been changed, then it could be moved away to a separate paragraph/section as a visual improvement and easier troubleshooting.

[Moonchild]

This is it.

Yes I already understood that that is what you envisioned, but...

If you are saying that this would still require "massive changes to the preferences system" then it's perfectly fine as it is.

It would, because it would somehow need to detect when a pref change is user-initiated (the "nanny" bit), and it would need to store that bit of information (also making prefs files incompatible with previous versions, etc.)... or needing to be stored entirely separately... And then Sync needs to understand that as well...
So I really don't see it as an option for the convenience it would bring to troubleshooting info.

[back2themoon]

Ok understood (mostly), thanks.

Please help me unclear this though: "it would somehow need to detect when a pref change is user-initiated"

Isn't detecting the non-default status enough, as the system currently does? Non-default=bold, default=non-bold

But I think you are saying that the problem is with implementing this additional logic:

1) Installation and running environment setting = List 1
2) User-changeable advanced setting = List 2

Even if the entries in those lists are already known, they'd still have to be compared somehow and that's what makes it complicated. It's not a simple "If setting=x then move text there" operation.

[Moonchild]

Please help me unclear this though: "it would somehow need to detect when a pref change is user-initiated"

Isn't detecting the non-default status enough, as the system currently does? Non-default=bold, default=non-bold

No, because as I already explained, preferences are also changed by other things like extensions, scripted events and browser components. All preferences are user-changeable (unless explicitly locked with the methods available through AutoConfig and the likes), including those that may have previously determined to be a certain value by e.g. the initial browser state check on startup or extension initialization. These preferences will not be "default" because they deviate from the initial "out of the box" (i.e. uninitialized profile) values, but are also not necessarily user-set (but they can be!).
The distinction you want to make would have to determine whether it's in either list (e.g. by hard-coding the selection...?) and even then, initialized values may be changed by the user later on, making it have to be in the "other list" somehow. Theoretically it's possible to hard-code a list of "common" environment-determined changed preferences but it's likely to become incorrect even for common values like cache sizes or download options and it really wouldn't help anyone to divide into incorrect lists in that case, so to have an accurate record it would need to store the originator of the non-default state in the preferences themselves somehow. And that's a level of complexity with a hell of a lot of pitfalls.

[Gemmaugr]

This might be too simple.. But would adding a date (YYY/MM/DD - HH:MM:SS) to when the changes were implemented also be a big deal, since most install/update changes would have a shared date, unlike user-implemented changes?

[Moonchild]

This might be too simple.. But would adding a date (YYY/MM/DD - HH:MM:SS) to when the changes were implemented also be a big deal, since most install/update changes would have a shared date, unlike user-implemented changes?

Once again that would need to be stored somewhere, so it's not that simple.