1483485 - Changing IMAP server name in Server Settings does has no effect on IMAP folder address/location/URI in Inbox folder Properties

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[mail]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20100101

Steps to reproduce:

* add a mail account using the assistant
* in account settings: change its IMAP server from old.example.com to new.example.com
* right-click on my inbox folder, click properties, look at the folder address


Actual results:

"imap://[e-mail]/INBOX"


Expected results:

"imap://[e-mail]/INBOX"

Comment 1

[Jorg K (CEST = GMT+2)]

We keep track of old server and new server internally. It's really confusing and leads to a few bugs. We need to revise that whole area.

Comment 3

[Thomas D. (:thomas8)]

This may or may not be a bug in technical terms, but it's a bug in terms of UX at least (UX-implementation-level).
Even if perhaps we're still using the original/old server name internally (so the Location property might still be technically correct, don't know), exposing that to the user without some in-place explanation appears pretty irritating.

Comment 4

[Martin]

My e-mail provider changed the IMAP server address, so I changed it accordingly in Thunderbird settings for this account.
When trying to retrieve new messages from this account, it still tries to connect to the outdated IMAP server address and fails therefore.

Thomas D. wrote, "This may or may not be a bug in technical terms...". If it is so: how can I change the IMAP server address, if the intial set one is outdated (no more in use)?

Comment 5

[Ping Chen [:rnons] (away)]

Attachment: Bug 1483485 - Require a restart after changing server or user name. r=mkmelin

Two changes:

• On server/user name change, save to temporary .pendinghostname/.pendinguserName pref
• On start up, replace the value of .hostname/.userName with .pendinghostname/.pendinguserName or .realhostname/.realuserName

With this change, .realhostname and .realuserName becomes obsolete, related code will be removed in a follow-up patch.

Comment 6

[Ping Chen [:rnons] (away)]

Attachment: Bug 1483485 - Remove realHostName/realUsername from nsIMsgIncomingServer. r=mkmelin

Skip and fix a few tests.

Depends on D144790.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3b683e321528
Require a restart after changing server or user name. r=mkmelin
https://hg.mozilla.org/comm-central/rev/e7602ee8cf16
Remove realHostName/realUsername from nsIMsgIncomingServer. r=mkmelin

Comment 14

[Axel Grude]

I haven't read the full patch but does changing the name (by the user) now also modify Folder URIs?

Internal / silent Folder URI modification can have breaking consequences on my side (QuickFolders Add-on) because it uses them to persist folder locations. see https://github.com/RealRaven2000/QuickFolders/issues/281

It would be great if any circumstances that can modify folder URIs (apart from the obvious which is renaming / moving a folder) based on server settings / modification were documented in some place.

Comment 15

[Axel Grude]

Just an update on this - here is how I remedy the problem from an Add-ons writer's perspective. QuickFolders now also stores the account id (e.g. "account1" together with the URI to store its folder shortcuts; once the upgrade to Thunderbird 102 happens (or a server is renamed), Thunderbird can detect invalid URIs and tries to rebuild the URI with the new root and fixes them quietly. Note that when you use Services.io.newURIto generate a new valid uri from the old one, you cannot use "imap" unless the folder exists for certain - POP3 and Local host have no such problem (hence the replacement with http)

    function reconstructUri(e) {
      let ac = MailServices.accounts.getAccount(e.account), acType = "N/A";
      if (ac && ac.incomingServer) {
        acType = ac.incomingServer.type || "unknown";
        if (acType!="im") { // do not reconnect to chat accounts - these are not supported.
          let oldUri = e.uri.replace("imap://", "http://"); // non-existent imap URIs throw!!
          let tempUri = Services.io.newURI(oldUri); // generate a fresh URI to retrieve path portion
          // or oldUri.filePath - not sure whether query params make sense or are allowed for  folder URIS
          return ac.incomingServer.serverURI + tempUri.pathQueryRef; 
        }
      }
      throw new Error(`Failed to reconstruct URL for ${e.uri} of account ${e.account} - account type ${acType}`);
    }