Jens Hatlak wrote:
Bill Davidsen wrote:
Jens Hatlak wrote:
OTOH the average user won't have to care about the two prefs that
caused the problem here once the bug fix is available as part of the
next release.
Do you have any idea how elitist that sounds?
Maybe you just got me wrong, please read on.
Dozens of people have filed bugs, discussed this on servers, in chat
rooms, and on other mailing lists. But they're just average users, and
because this stuff means their user agent doesn't work they do care a
great deal. And will the next time some totally undocumented option is
needed to make some common task work. The tone of your "average user"
comments shows how little you value other people's time.
My point is that the average user shouldn't have to care about these
prefs at all. At least not to work around bugs. The problem at hand is a
bug, and as such it should be fixed. It's just that *in this particular
case* dealing with these prefs helps to *work around* the bug until the
fix is available (here: with SM 2.0.1, due next week). In many other
cases there are no prefs, hidden or not, that help to work around a problem.
Because this stuff might change is exactly why about:config should dump
all available values. Or call it about:everything. People already know
they may break something, and things may change, what's new?
Prefs that do not appear in about:config unless manually set are prefs
without obvious default, i.e. their default and type (!) solely depend
on how they are used in the internal implementation. As I said, the
implementation can change any day it is developed further. How should
those be shown in about:config when they are not set by the user (in
which case they already appear in the current situation)? How would the
user know which type (string/boolean/integer) they are and what possible
values would be?
Frankly, in my opinion it should not be possible to have a variable in the table
without defining a type. I know that's dreadfully old school, but I have decades
of professional software experience to back that opinion. Just throwing things
in without any documentation leads to many "oh look at that!" moments.
OTOH, if a pref would be important enough to be useful for more than a
very small minority or seldom edge cases, the developers would only have
to define a default for it and it would appear in about:config by
default. If you find a pref that you think deserves that kind of
attention you can file a bug and request that. It'll depend on your
reasoning whether it'll be accepted or not (and the reviewers, of
course). All I'm saying is that making a pref visible by default just
because it works around a bug that should (and was!) be fixed another
way is the wrong way to go.
If you say so. I don't see that having developers tell people how to disable
compatibility check in the support group is somehow better than letting users
see it, since it does have a default value. Or the general.useragent.extra.*
values, someone might use them if they were visible. Perhaps a default empty
value for strings would be good?
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
