Closed Bug 2654 Opened 25 years ago Closed 8 years ago
Path(change of Server Settings/Local directory) does not take effect until restart
<Contents pasted from bugsplat bug 311903.> Customer is Paul Carroll (email@example.com) The customer views the lack of notification that preferences set in Mail & Groups, Mail Server do not take effect until Communicator is restarted, as a bug, because the behavior differs from that on PC. Additional Details : When you change the "Local mail directory" or the "IMAP4 mail directory" in Edit-> Preferences-> Mail&Groups-> Mail Server, the change does not take effect until the next time you start Navigator. However, no message is given at Navigator must be restarted for this change to take effect on Solaris. The PC version of Navigator 4.5 does give this notice. To reproduce: 1) Bring up the Preferences dialog from the Edit menu in Navigator 2) Go to the Mail&Groups-> Mail Server section 3) Click More Options 4) Change local mail directory to another directory with different mail folders/ directories, click OK 5) Go to Mail&Groups -> Messages and look at the 'Automatically copy outgoing message to folder, Mail Messages:' list box, its contents (the items in the drop-down list) should not have changed. 6) Exit Netscape and restart. Go to the location in the last step and look at the drop-down list again, it should now reflect the changes you made in step 4.
Setting all current Open/Normal to M4.
This may no longer apply in 5.0, but we'll check it once we have a product to test.
Assignee: phil → putterman
Summary: Should not have to restart program after chging preferences → Pref change should take effect, or tell user it won't
Improved bug summary. Assigning to scottip since I think the right thing is for the data source to catch this pref changing and rebuild the RDF graph.
Assignee: putterman → alecf
Status: ASSIGNED → NEW
Target Milestone: M7
reassigning to alecf. I doubt this will be fixed for M7 so I'm going to remove the taget mileston. I think the underlying design of this will be similar to what you have to do for rename server/account assuming we keep that in.
oh goodness. This is going to be ugly. I'd kind of like to force a restart of messenger for this to work. (We can restart messenger without restarting the browser)
Component: Front End → Back End
Summary: Pref change should take effect, or tell user it won't → server directory Pref change should take effect, or tell user it won't
Summary: server directory Pref change should take effect, or tell user it won't → localPath does not take effect until restart
Spoke to AlecF about this - this bug affects all platforms and is hard to fix. OK to fix this bug after PR1, but we will need to describe this behavior in release notes.
This requires some architecture changes that I've been working on for a while. I'm pushing this past PR1 because not all the architecture will land by PR1, and even so I'm still not sure if this is really possible.
moving non-critical bugs to M20
Target Milestone: M16 → M20
Moving target milestone to "future" to be reviewed at a later time
Target Milestone: M20 → Future
Last I checked there was no relnote3, but we should describe this in all future release notes until it is fixed. I'm nominating for nsbeta3 with a request that if the real fix can't be done for nsbeta3 that a simple alert dialog be included. Setting platform/os All/All per sol. Adding CC. Actually... I don't suppose this was already fixed?
we've had this behavior since 4.x, and the fix is non-trivial because we currently cache each folder's path in the folder itself. I really don't think it's worth fixing for beta3 or even RTM...you generally don't change your server path unless you know what you're doing. And if you know what you're doing, you're certainly going to try restarting. as for the alert dialog, there also isn't a great way of adding this and I also don't think it's worth doing for beta3...
reassign to sspitzer..this will have to somehow update all the folder objects as well..
argh, actually assigning to sspitzer
Assignee: alecf → sspitzer
Status: ASSIGNED → NEW
This one's still in the release notes for 1.2a. It's been almost two years since anything happened in this bug. Any chance of fixing this before we release 2.0? :)
and now it has been an other year, as well.
*** Bug 209585 has been marked as a duplicate of this bug. ***
Changes of settings do not take effect at all, the program does not remember any changes in names, email address, bcc, attach signature, etc
UI of Mozilla Mail&New and Thunderbird refers to "localPath" as "Local Directry". Please change summary for ease of search or understanding bug, in order to avoid too many similar Thunderbird bugs in addition to many Mozilla's DUP bugs (I have no privilege of summary change). For example ; > localPath change(change of "Local directry" in "Server Settings") does not take effect until restart
*** Bug 263195 has been marked as a duplicate of this bug. ***
Summary: localPath does not take effect until restart → localPath(change of Server Settings/Local directry) does not take effect until restart
*** Bug 288417 has been marked as a duplicate of this bug. ***
*** Bug 298326 has been marked as a duplicate of this bug. ***
19 years ago
Summary: localPath(change of Server Settings/Local directry) does not take effect until restart → localPath(change of Server Settings/Local directory) does not take effect until restart
*** Bug 302630 has been marked as a duplicate of this bug. ***
*** Bug 308476 has been marked as a duplicate of this bug. ***
*** Bug 222646 has been marked as a duplicate of this bug. ***
*** Bug 349335 has been marked as a duplicate of this bug. ***
Assignee: sspitzer → nobody
QA Contact: nobody → backend
*** Bug 359905 has been marked as a duplicate of this bug. ***
Nominating wanted-thunderbird3 due to the sheer number of dupes. It'll be up to drivers to decide if it will make tb3 though.
Removing relnote keyword from bugs that are no longer significant or not needing to be mentioned in the release notes.
11 years ago
Since bug 224831 TB forces a restart if you change the Local Directory. So this problem is almost solved if you use the GUI account manager. The problem remains if you change it via the programatically.
I think we can say this is as resolved as it can be, by bug bug 224831. Making things work on the fly without a restart is not gonna happen.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Whiteboard: nsbeta3- → [resolved by bug 224831]
You need to log in before you can comment on or make changes to this bug.