504989 - "Restore Defaults" in the column list chooser doesn't work.

Status: NEW

(Thunderbird :: Folder and Message Lists, defect)

Description

[Dave Miller [:justdave]]

The "Restore Defaults" button in the column list chooser in a message folder currently does nothing since the landing of bug 498209.  Previously it would restore the built-in default list of columns.  With the new column persistence behavior, it would make sense for choosing this on any folder other than the Inbox to cause that folder to re-inherit its column list from your Inbox.  Choosing it on the Inbox would restore the built-in default list as previously (and do so for any folders currently inheriting from it also).

Comment 1

[Rain [:rain1] (inactive)]

Could this be the same as bug 463396? Or did Restore Defaults work for a while before breaking again with the landing of bug 498209?

Comment 2

[raoul bhatia]

i'd say this is a dupe of bug 463396

Comment 3

[Ronald Killmer]

This bug is a spinoff for followup from Bug 498209. Though the summaries are similar the difference is when in the history of the code the bugs were detected.

Comment 4

[Mark Banner (:standard8)]

Whichever way you look at it they are the same issue. Why and how are useful to know, but it is the same bug. As it is possible it worked for a while before breaking again, then I'll dup bug 463396 to this one as this has a bit more info anyway.

Comment 6

[Peter B]

(In reply to comment #0)
> With the new column persistence
> behavior, it would make sense for choosing this on any folder other than the
> Inbox to cause that folder to re-inherit its column list from your Inbox.

This only makes sense for user created folders. All the standard folders Inbox, Outbox, Drafts, Templates, Sent, Trash, and Junk would have their own logical default columns. Would they not? Some may be the same as Inbox but Outbox, Drafts, Templates, and Sent,certainly would not be. Perhaps these would all be the same as Sent.

> Choosing it on the Inbox would restore the built-in default list as previously
> (and do so for any folders currently inheriting from it also).

Using inheritance to re-establish defaults in other previously created folders would destroy any custom settings previously made in that folder. Better that the "Restore Defaults" button only works on the currently viewed folder.

I have no problem that when a folder is created it should either take the attributes of a parent folder, if a child, or, in the case that it is not a child folder, take the attributes of the Inbox. For an advanced user it would be always possible to create a folder as a child folder, thereby inheriting from the parent, and then move the folder to parent level. This is currently what occurs. The "Restore Defaults" button could then restore the defaults of the child to that of the parent if a parent exists. This would be consistent with creating a new child folder.

Comment 7

[Pete Riley]

Please also consider RSS mailboxes since they don't have their own Inbox.  One way would be to use the primary email account's Inbox (or the first email account in the list of accounts).  Alternatively it could be based on the RSS account's Trash mailbox, or on the first RSS mailbox in the account.

Also, none of this (including previous comments) seems very discoverable.  Perhaps the phrase should be changed from "Restore Defaults" to "Make same as <mailboxName>".  Even then, it's not clear what you're changing:

1) current mailbox only
2) all mailboxes in current folder branch
3) all mailboxes in current account
4) all mailboxes everywhere

Comment 8

[Pete Riley]

(In reply to comment #7)
> Perhaps the phrase should be changed from "Restore Defaults" to "Make same as
> <mailboxName>".

Or perhaps better something like "Apply to whole account" that would apply the current mailbox's column set to all mailboxes in the current account.

Also, is there really any need to ever restore TB's defaults considering that the user has already taken ownership and changed them?  If so then perhaps that could be an additional menu item.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

This is presumably related to the front-end refactoring.  asuth, do you have any insight here into how hard/what the fix might be?

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

This is really a toolkit regression, as per philor's comment in the bug 367130 that this now depends on.  Given the history here, I don't think blocking on this makes a lot of sense.

Comment 11

[Peter B]

As at this moment "Restore Defaults" seems to set the column order to the order as displayed in the drop down menu. This is as stated in bug 367130. As mentioned there it is not what one would expect from the title, and I question whether it (a re-setting default on column order) is even useful.

"Restore Defaults" should always restore to the initial state, whatever that may be, in this case column selection and column order. The discussion of what that initial state should be is another issue entirely.

With "Restore Defaults" perhaps there is a nice counterpart that I could suggest and that is "Set as Default" which would set the current state as the default. Perhaps this concept would only make sense if there was only one default for all folders. In the case that the folders in different classes, ie Inbox, Sent and etc., have their own specific “factory” default the “Set as Default” option would then have to apply only to that specific class.

Just some of my usual long winded thoughts.

Peter

Comment 12

[Thomas D. (:thomas8)]

This is not a regression. As Phil rightly points out in bug 367130, "Restore Defaults" is just a wrong label for the command which has ever only restored the default order, but never the default set of columns:
> Then justdave filed bug 504989, pointing directly at a regressing bug which
> actually didn't change a thing, because it seemed so obvious that we wouldn't
> have had a menuitem to restore ordering at the bottom of a menu that changes
> which columns are shown and hidden without saying that it doesn't change what's
> shown or hidden, only the order, and none of us realized that it hadn't
> actually ever done what the label says it does.

IOW, this bug is currently a feature request to implement extra functionality of a combined "Restore Defaults" command that restores both column order and default set. For this RFE, a better summary would be:
"Implement combined "Restore Defaults" functionality in the column list chooser (restore both default order and default set of columns)".

However, we would then loose the current functionality of "Restore column order (only)". But there might be users (like me) who just want to restore the default order, but not the default set. IMO, there should be two separate commands for two separate actions:
- "Restore default order" (cf. Phil's proposal in bug 367130, comment #3)
- "Restore default columns"
What the default columns are in each folder is an entirely different aspect.
Probably "Restore default columns" should then NOT restore the default order, but that's another minor detail to be discussed.

****************************
I therefore propose that the current summary of this bug be morphed into:
"Implement "Restore default columns" command in the column list chooser"
Any objections?
****************************

(Note that strictly speaking, the current summary of this bug is not actionable, because it's not a regression and so the "doesn't work"-behaviour of "Restore Defaults" isn't even defined yet.)

Comment 14

[Peter B]

(In reply to comment #12)
> IMO, there should be two separate commands for two separate actions:
> - "Restore default order" (cf. Phil's proposal in bug 367130, comment #3)
> - "Restore default columns"

Remember the story of the man with the donkey that tried to please everyone and finished up pleasing no one.

Keep it simple! "Restore defaults" should do just that - Restore defaults of both order and column selection. Once you are in that area making any adjustments in column selection or order is a matter of child's play and too individual to try and second guess.

> What the default columns are in each folder is an entirely different aspect.

I agree, but there is a certain logic to what they should be which is not too difficult to work out.

Comment 15

[Wayne Mery (:wsmwk)]

Does this still fail?

Comment 16

[Mitra Ardron]

The bug part about Restore columns certainly appears to restore columns to me,

There also seemed to be a feature request in terms of inheritance that I don't fully understand an am not commenting on (so i'll leave the "needsinfo" flag for someone else to clear.

Comment 17

[Dave Miller [:justdave]]

OK, the inheritance stuff that was requested actually exists now, that's the "apply columns to" at the bottom of the menu. So that part should be considered completed.

The menu item that was complained about at the start of this bug was titled "Restore Defaults". That menu item no longer exists. In its place is a menu item labeled "Restore Column Order", which does exactly what it says.

It sounds like this also has a feature request for an option to restore the default list of columns as well, which does not exist yet, so that's the part of this that's still missing. To restore the set of columns in that mailbox to be the ones Thunderbird would have used had it not been customized at all.

Comment 18

[Wayne Mery (:wsmwk)]

It sounds like this also has a feature request for an option to restore the default list of columns as well, which does not exist yet, so that's the part of this that's still missing. To restore the set of columns in that mailbox to be the ones Thunderbird would have used had it not been customized at all.

I suspect we already have a bug report for this, no?

Comment 19

[Wayne Mery (:wsmwk)]

Attachment: Screenshot 2025-10-14 at 11.37.38 AM.png

Dave, this works for you in 140?