Closed Bug 180604 Opened 22 years ago Closed 14 years ago

View | Sort by settings get lost

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jon.roland, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 The View | Sort by settings get lost, most often from one session to the next, but sometimes during a session. Reproducible: Sometimes Steps to Reproduce: 1. Set Sort by to Order Received and Descending for a folder, such as Inbox. View resorted messages. 2. Close mail window. 3. Reopen mail window. Find Sort by settings sometimes reset to Date and Ascending, sometimes all unselected. Actual Results: Sort by settings lost or reset to defaults. Expected Results: Sort by settings same as when set during previous session. Have lost Sort by settings for a folder during a session in going from one account to another. The problem seems to occur most often with the folders containing the most messages, but it sometimes occurs even with folders containing few messages. Also recommend: 1 - Make it possible to set both the field and ascending/descending in one operation, without having to open the Sort by window twice. 2 - Allow user to set the Sort by parameters globally for all folders of an account, or for all folders of all accounts.
QA Contact: olgam → laurel
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021122 I also see it. It happens (seemingly) randomly. I don't have to close the MailNews window. I cannot find another dupe. Confirming. pi
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Still happening in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030107. This is really annoying. pi
Still happening in 1.3b build 2003021008 Win 98se, but not as often as it did in 1.1. Most occurrences now seem connected to the freeze problem #186368.
NACK, still happening as often with 1.3b Release on Linux, not related to any freeze or crash. Cannot test later nightlies since sources are no longer provided to compile. pi
This works for me in a recent 1.4b nightly, as well as 1.3 Final. Jon Roland, can you confirm?
I can confirm that the problem has for the most part disappeared in 1.3final, but not entirely. It has recurred when there is an abnormal closure of Mozilla or one of its components, usually after a resource limit has been reached. This tends to support my request that users be able to change their setting defaults in a way that survives crashes. In other words, they should be set in a file that is not kept open during a Mozilla session, but is only opened briefly for changes and then closed again and thereafter read only, and read after a reboot following a crash. The same should be done for other user settings, in the manner of .ini or .cf files, which are protected from being lost or corrupted by crashes.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030425 Still seeing it. pi
*** Bug 217487 has been marked as a duplicate of this bug. ***
It is still around. Now it has become worse, I cannot even swith back to threaded sort, but this will be another bug. pi
*** Bug 232888 has been marked as a duplicate of this bug. ***
*** Bug 236788 has been marked as a duplicate of this bug. ***
This bug has become worse in last released nightly for OS/2 - used to happen occassionally now happens almost evey time the inbox is opened
My previous post regarding this bug becoming worse under the nightly OS/2 relateted to the 03/03/2004 build. However I have d/led the CONTRIB nightly OS/2 2004031708 build and this seems much better - in fact in the short time I have been using it, it has not failed(restarted Warpzilla 19 times)
Unfortunately this bug seems to be getting worse. Current nightly OS/2 builds seem to be consistantly losing sort order. Although minor it is highly annoying
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040708 I have been experiencing this problem since August on 1.6, and it seems to be getting worse. It is seriously annoying, especially when you have thousands of messages in a folder. It has been enough to make me want to switch to a different mail client. Has *any* progress been made on this? It's been in Bugzilla for *two years*.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Is anything happening about this? I am still getting the problem. Thunderbird version 1.0.7 (20051017) linux/debian
(In reply to comment #16) > Is anything happening about this? I am still getting the problem. I've seen folder settings getting lost in certain situations involving search folders -- see bug 267727 comment 15 -- but that feature is more recent than most of this bug's comments were about. > Thunderbird version 1.0.7 (20051017) linux/debian This probably won't address your problem, but you ought to consider upgrading to 1.5 (altho 1.5.0.2 will have several useful fixes).
Yes, it won't. I am now on 1.5.0.2 and it is still happening.
(In reply to comment #18) > Yes, it won't. I am now on 1.5.0.2 and it is still happening. Here's a hunch -- let's see if I can confirm it. Are the users on the cc list using IMAP servers? Please reply -- it will help narrow down the problem.
I am using a home computer with POP and SMTP.
(In reply to comment #20) > I am using a home computer with POP and SMTP. Well, so much for my hunch. I've been using IMAP exclusively -- I guess this is most definitely a Mozilla/Thunderbird problem.
1.5.0.5 and it is still happening. Any progress on this?
Assignee: mail → nobody
QA Contact: laurel → message-display
does anyone still see this problem? (if not, bug will close )
Whiteboard: [closeme 2011-03-21]
I am not using Seamonkey anymore, so I don't know if the problem is still there. It is not present in Thunderbird 3.1.7 for Linux.
Haven't seen this in ages if at all in SeaMonkey.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-03-21]
You need to log in before you can comment on or make changes to this bug.