193332 - about:config doesn't remove deleted prefs with no default

Status: NEW

(Core :: Preferences: Backend, defect, P5)

Description

[Mark]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

I like the new editability ofthe about:config screen, and tried to use it to add
browser.history.url.datacapture.mode but made a mistake in the name. I then
found that there was no "delete" operation in the interface for editing this
page.  This feature doesnt seem complete without a delete function.  (Preferably
at least a single level of undo also in case I accidently delete, but perhaps
thats a separate bug...)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Alfonso Martinez]

Why did you filed this bug as major?
The ability to change items in config:about wasn't possible, now it is and you
say that this is a major bug just before it's missing something?

A more proper severity would be minor or even Enhancement to reflect the real
state of the situation.

Comment 2

[Boris Zbarsky [:bzbarsky]]

There's a "reset" option in the context menu.... Does that work?

Comment 3

[Michael Lefevre]

if you add a non-existant pref, and then do reset, it still shows, but with a
blank default. the pref is not then saved, so when you restart, it disappears.
would probably make sense to remove such prefs from the list when they are
"reset". I'm using 1.3b on win2k.

reducing to minor - this doesn't affect functionality, but it's obviously a
little confusing in some circumstances. confirming, reassigning (hopefully
correctly).

Comment 4

[[e-mail]]

Well someone will have to change the pref backend so that the pref no longer
enumerates first. This will also fix an issue with switching profiles which
doesn't delete prefs without default values, it only clears them. Code that
expects enumerated prefs to have a value (such as app startup) fails :-(

Comment 5

[Mark]

If I had a text editor where I could add new lines, and edit them, but could not
delete them, I would call that a "major" problem with the functionality.  :-)

I did try reset on the entry I added, result as described above.  But since
"reset" typically means something like "return to a previous value/state" of
some kind, since there was no previous value, becoming blank seemed reasonable
as the previous state was non-existant.  If reset is supposed to mean delete, I
suggest renaming it "delete" in addition to making it go disappear.

Comment 6

[Michael Lefevre]

if it was a text editor, it would be a major problem. but it isn't, so it isn't. :)

AIUI, there's no way of deleting whatever broken prefs you add, because the
prefs backend carries on enumerating them when it doesn't need to. so this isn't
likely to get fixed in a hurry.

Neil - is there a bug for the backend thing that this could depend on? should
one be filed?

Comment 7

[timeless]

.

Comment 8

[[e-mail]]

File a bug on the enumeration issue if you like, just don't forget to make it
block this one :-)

Comment 9

[Myke Cuthbert]

Just to add, the problem is not just if you make a typo and create a
non-existent preference name.  If you create a preference with the wrong type
(e.g., general.smoothScroll as a string) then you cannot change the type to the
correct one.  

Comment 10

[Charles Fenwick]

*** Bug 211509 has been marked as a duplicate of this bug. ***

Comment 11

[Robert Zaichkowski]

With the preferences, I tried to right-clock the specific preference I wanted to
remove and reset it to default values.  What happened was that once I rebooted
Mozilla, the preference was deleted successfully.  So I was able to re-do the
general.SmoothScroll preference correctly by identifying it as a Boolean.  This
was tested with Mozilla 1.4 Final in Windows XP Professional with SP1.

So in other words, the bug only has to refer to user-friendliness, yet this
feature is supposed to be intended for advanced users only.  So I wouldn't be
too fussy about this bug if I were you.

Comment 12

[Met - Martin Hassman]

Probably this bug depends on bug #216895

ad comment 3: "if you add a non-existant pref, and then do reset, it still
shows, but with a blank default"

Now you must restart Mozilla to completely clear preferences value - the value
is cleared, but the type is still rememberd until Mozila restart (see the #216895)

Comment 13

[Emmanuel Bourg]

*** Bug 221785 has been marked as a duplicate of this bug. ***

Comment 14

[Vaclav Dvorak]

*** Bug 206790 has been marked as a duplicate of this bug. ***

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 257324 has been marked as a duplicate of this bug. ***

Comment 16

[Matthias Versen [:Matti]]

*** Bug 286562 has been marked as a duplicate of this bug. ***

Comment 17

[Tuukka Tolvanen (sp3000)]

*** Bug 264907 has been marked as a duplicate of this bug. ***

Comment 18

[Dave Townsend [:mossop]]

*** Bug 304606 has been marked as a duplicate of this bug. ***

Comment 19

[Magnus Melin [:mkmelin]]

*** Bug 329243 has been marked as a duplicate of this bug. ***

Comment 20

[Magnus Melin [:mkmelin]]

*** Bug 329244 has been marked as a duplicate of this bug. ***

Comment 21

[Andrew Schultz]

Attachment: do what the comment says

This just does what the comment says would work without saying why it isn't done.  It works.  To get rid of the pref displayed in about:config, you have to refresh the display.

This also handles comment 4 (bug 333681).

An alternative solution here would be to use one of the unused flags (PREF_CONFIG, PREF_REMOTE, PREF_LILOCAL) for PREF_DEFAULTSET

Comment 22

[Andreas Morawietz]

In which versions will this be checked in ? Trunk? Branch? Or in both?

Comment 23

[[e-mail]]

(In reply to comment #21)
>This just does what the comment says would work without saying why it isn't
>done.  It works.  To get rid of the pref displayed in about:config, you have to
>refresh the display.
I assume about:config will still get the callbacks... it just needs to be updated to remove the pref once it finds that it has no type.

Comment 24

[Andrew Schultz]

Attachment: don't remove entries while enumerating

Running with this, I noticed it asserts during profile switch (I don't remember that before) due to pldhash recursion.  This handles that more properly.

Comment 25

[Darin Fisher]

Comment on attachment 219490 [details] [diff] [review]
don't remove entries while enumerating

>Index: prefapi.cpp

>+            (pref->flags & PREF_BOOL && 
>+             pref->defaultPref.boolVal == ((PRInt32) BOGUS_DEFAULT_INT_PREF_VALUE)) ||

Shouldn't this be BOGUS_DEFAULT_BOOL_PREF_VALUE?

Comment 26

[Andrew Schultz]

> Shouldn't this be BOGUS_DEFAULT_BOOL_PREF_VALUE?

Yes!  In both methods.

Comment 27

[Darin Fisher]

Comment on attachment 219490 [details] [diff] [review]
don't remove entries while enumerating

r+sr=darin with BOGUS_DEFAULT_BOOL_PREF_VALUE

Comment 28

[Andrew Schultz]

Comment on attachment 219490 [details] [diff] [review]
don't remove entries while enumerating

this landed

Comment 29

[Andrew Schultz]

Attachment: frontend patch

updates about:config to remove prefs without a type

Comment 30

[[e-mail]]

Comment on attachment 225230 [details] [diff] [review]
frontend patch

I don't think this would be complete without an extra "Delete" context menuitem to be shown instead of the existing "Reset" menuitem for prefs that don't have a default value.

>       if (gSortedColumn == "lockCol" || gSortedColumn == "valueCol")
>         gFastIndex = 1; // TODO: reinsert and invalidate range
Don't need to do this when deleting a pref.

>     } else {
>       fetchPref(prefName, index);
What should we do in the case of a pref we don't know about and can't fetch?

>+      default:
>+      case gPrefBranch.PREF_INVALID:
>+        delete gPrefHash[prefName];
>+        gPrefArray.splice(prefIndex, 1);
>+        return false;
>+        break;
No break after return :-P

Comment 31

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a6pre) Gecko/20100619 Lightning/1.1a1pre SeaMonkey/2.1a2pre - Build ID: 20100619011136

Alas, this bug seems to have fallen off the radar. And yet, if you create a pref (that doesn't exist by default) with the right name but the wrong type, or if you create a Boolean or Integer (that doesn't exist by default) resetting it will turn it into the empty string (with type String), and it is not possible to give it a Boolean or Integer value without restarting.

See for instance bug 410312 for an explanation of how disconcerting this might be.

This bug is certainly not "blocking", but could it be "wanted"? Fixing it would certainly improve the user's experience.

Comment 32

[[e-mail]]

(In reply to comment #31)
> Alas, this bug seems to have fallen off the radar. And yet, if you create a
> pref (that doesn't exist by default) with the right name but the wrong type, or
> if you create a Boolean or Integer (that doesn't exist by default) resetting it
> will turn it into the empty string (with type String), and it is not possible
> to give it a Boolean or Integer value without restarting.
The pref backend did get changed (sorry, I forget the bug number) but it's true that nobody bothered to fix about:config so you'll need to reload it (a full restart isn't necessary) to update correctly in this case.

Comment 33

[Tony Mechelynck [:tonymec]]

(In reply to comment #32)
> The pref backend did get changed (sorry, I forget the bug number) but it's true
> that nobody bothered to fix about:config so you'll need to reload it (a full
> restart isn't necessary) to update correctly in this case.

Well, thanks for telling me. I don't think I could have "discovered" it all by myself.

BTW, is the ASSIGNED status of this bug still up-to-date? The assignee (ajschult) seems to have left it unattended since 2006.

Comment 34

[Skippy le Grand Gourou]

This bug still does exist as of today (Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7, Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.13) Gecko/20101209 Fedora/3.6.13-1.fc14 Firefox/3.6.13).

Comment 37

[kud]

I still have this bug on Firefox 4 b12 (MacOS). Reseting a field which I've added personnaly doesn't remove it and I can't change at all the type of field. If I added a string one, I won't be able to have a boolean one.

Comment 38

[Andreas Eibach]

to comment 37:

Erwann, please see bug 1089164.

Comment 39

[jwms]

Reading through the comments (and from personal experience) this is a non-issue. Refreshing the screen or closing Firefox and reopening will clearly show that a custom pref reset to default is removed from the about:config screen.

Comment 40

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

The severity field for this bug is relatively low, S4. However, the bug has 10 duplicates and 11 votes.
:KrisWright, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 41

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.