545681 - Deprecated mail.root.imap (and related) still used?

Status: UNCONFIRMED

(Thunderbird :: Account Manager, defect)

Description

[Charles]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 3.0.1 final

This bug is being filed to track the issue discovered after opening bug 454243 requesting a user pref to define the Parent/Default ImapMail root.

David :Bienvenu informed me of the mail.root.imap-rel user pref, but when I looked at it in about:config, I saw mail.root.imap, and asked if that wasn't the one I wanted. David said that the non-rel prefs were obsolete and should have been removed.

Well, when I tested this, I discovered that changing just mail.root.imap-rel wasn't enough, I also had to change mail.root.imap before the new setting took.

Maybe this is a non-issue - maybe the mail.root.imap is aliased somehow to the -rel setting, and when these are removed everything will 'just work' - if so, my apologies and feel free to close this bug...

Reproducible: Always

Comment 1

[WADA:World Anti-bad-Duping Agency]

Charles Marcus(bug opener), when, at where and how, did you change mail.root.imap-rel setting?
Changed mail.root.imap-rel via config editor while Tb is running, and no restart of Tb after the change?
How about mail.root.imap setting change?

Tb 3.0.4 used mail.root.imap-rel as designed upon account creation when Tb was restarted after change of mail.root.imap-rel in prefs.js.
Update of mail.root.<type> was executed only when account creation of <type> was executed using changed mail.root.<type>-rel.
It looks same since initial of xxx.<type>-rel support.
  - xxx.<type>-rel is read upon restart only.
    So, change of xxx.<type>-rel while Tb is running is not reflected.
  - xxx.<type> is still kept for backward compatibility.
    xxx.<type> is updated only when xxx.<type>-rel is reffered or used.
    "reffered or used" :
      when xxx=mail.root, account creation
      when xxx=mail.server.serverX, read of account settings upon restart
  - if xxx.<type>-rel doesn't exist in prefs.js (i.e. prefs.js was created by
    old Tb versions which didn't support xxx.<type>-rel),
    xxx.<type>-rel is generated from xxx.<type> setting.
  <type> :
     when xxx=mail.root,           <type> = imap, pop3, news, none etc. 
     when xxx=mail.server.serverX, <type> = directory
This(restart is needed to refrect <type>-rel change) may be one of causes of issue of "Restart is needed after Local Directory: setting change of an account"(Bug 2654). 

(1) Initial, after termination of Tb.
> user_pref("mail.root.imap", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\ImapMail");
> user_pref("mail.root.imap-rel", "[ProfD]ImapMail");
> user_pref("mail.root.none", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\Mail");
> user_pref("mail.root.none-rel", "[ProfD]Mail");
> user_pref("mail.root.pop3", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\Mail");
> user_pref("mail.root.pop3-rel", "[ProfD]Mail");

(2) Modify root.xxx-rel in prefs.js.
> user_pref("mail.root.imap", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\ImapMail");
> user_pref("mail.root.imap-rel", "[ProfD]ImapMail-X");
> user_pref("mail.root.none", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\Mail");
> user_pref("mail.root.none-rel", "[ProfD]Mail-X");
> user_pref("mail.root.pop3", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\Mail");
> user_pref("mail.root.pop3-rel", "[ProfD]Mail-X");

(3) Restart Tb, and define an IMAP account.
> user_pref("mail.root.imap", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\ImapMail-X");
> user_pref("mail.root.imap-rel", "[ProfD]ImapMail-X");
> user_pref("mail.root.none", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\Mail");
> user_pref("mail.root.none-rel", "[ProfD]Mail-X");
> user_pref("mail.root.pop3", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\Mail");
> user_pref("mail.root.pop3-rel", "[ProfD]Mail-X");
>(added IMAP account's directory-rel and directory)
> user_pref("mail.server.server1.directory", "C:\\ ... \\Profiles\\4kzqej5p.yyy\\ImapMail-X\\a.a.a");
> user_pref("mail.server.server1.directory-rel", "[ProfD]ImapMail-X/a.a.a");

Please don't assume that any prefs.js setting change via Config Editor while Tb is running is immediately reflected on any component with keeping consistency.
(Example of one of worst cases, off-topic though)
- Change of mail.server.serverX.type(pop3, imap) via settig UI is impossible.
- Change of mail.server.serverX.type via Config Editor is possible.
    (I don't know whether the change is saved in prefs.js or not)
- Change of mail.server.serverX.type via text editor is possible.
- If Tb is restared, changed mail.server.serverX.type is read, and server type
  is changed, and some problems may occur due to inconsistency between
  mail.server.serverX.type and other mail.server.serverX.xxx settings, and
  due to difference of directory/file structure between imap and pop3.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> This bug is being filed to track the issue discovered after opening bug 454243
> requesting a user pref to define the Parent/Default ImapMail root.

Your Bug 545243, isn't it?
(bug of bi-endian of Power-PC? 45=little-endian, 42=bit-loss,43=big-endian... :-)

Comment 3

[Charles]

(In reply to comment #1)
> Charles Marcus(bug opener), when, at where and how, did you change
> mail.root.imap-rel setting?
> Changed mail.root.imap-rel via config editor while Tb is running, and no
> restart of Tb after the change?
> How about mail.root.imap setting change?

WADA - yes, sorry, I typo'd the bug# when reporting this (it's really frustrating that you cannot edit comments here).

I don't run on a PowerPC, or a 64-bit OS, currently, and as you can see in my comment number 10 in bug 545243, yes, I restarted after every change...

Maybe this was fixed at some point after 3.0.1 - I'll test again to confirm your findings...

Thanks...

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> Maybe this was fixed at some point after 3.0.1 (snip)

mail.root.<type>-rel in prefs.js had been working/worked with Mozilla, SeaMonkey1/2 and at least Tb 2, and is working with SeaMonkey 2.0.2.

(a part of your bug 545243 comment #10)
> I tried setting mail.root.imap-rel pref first, created a new account,
> and it still created the new account offline store in the old/original/default
location in %AppData%.

Did you properly specify "relative path from Profile Directory which is being used" in mail.root.imap-rel?
Did you specify following path which was presented to you as example of relative path notation?
> user_pref("mail.root.imap-rel", "[ProfD]../../../../Local  Settings/Thunderbird/ImapMail");

FYI.
Following is my setting during I used SeaMonkey 1 on Win XP. Profile was placed in standard directory under %appdata%.
> user_pref("mail.root.pop3", "C:\\wada\\MAIL-NEWS\\Mail");
> user_pref("mail.root.pop3-rel", "[ProfD]../../../../../../../wada/MAIL-NEWS/Mail");
> user_pref("mail.server.server62.directory", "C:\\wada\\MAIL-NEWS\\Mail\\mail.spymac.com");
> user_pref("mail.server.server62.directory-rel", "[ProfD]../../../../../../../wada/MAIL-NEWS/Mail/mail.spymac.com");
>
>(profile directory, relative path)
> [ProfD] = C:\Documents and Settings\wada\Application Data\Mozilla\Profiles\wada\ss93y1tt.slt
> [ProfD]../ = C:\Documents and Settings\wada\Application Data\Mozilla\Profiles\wada
> [ProfD]../../ = C:\Documents and Settings\wada\Application Data\Mozilla\Profiles
> [ProfD]../../../ = C:\Documents and Settings\wada\Application Data\Mozilla
> [ProfD]../../../../ = C:\Documents and Settings\wada\Application Data
> [ProfD]../../../../../ = C:\Documents and Settings\wada
> [ProfD]../../../../../../ = C:\Documents and Settings
> [ProfD]../../../../../../../ = C:

(a part of your bug 545243 comment #12)
> Ok, so something is apparently broken if that's the way its supposed to work,
> because thats not how it worked when I tested it.

Is what broken really Tb's design/implementation/code etc.?

Comment 5

[David :Bienvenu]

I think if the -rel pref is broken, we will fall back to the non-rel pref. Broken might mean pointing at a non-existent directory

Comment 6

[Charles]

I dunno... I just opened this bug to track this because David had said that the non -rel prefs were obsolete and should have been removed...

Feel free to close this if desired, I just wante to make sure that the prefs actually got removed if they were indeed supposed to have been removed...