Open Bug 771487 Opened 12 years ago Updated 2 years ago

filter rules incorrectly changed when moving an IMAP folder containing umlaut (rename of IMAP folder doesn't use modified utf-7 string as internal folder path when "modified utf-7 of Mbox name" != "IMAP folder name for Tb")

Categories

(MailNews Core :: Networking: IMAP, defect)

defect

Tracking

(Not tracked)

People

(Reporter: stephan.edel, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1 Build ID: 20120615112143 Steps to reproduce: Use up-to-date Thunderbird 13.0.1 on Ubuntu 12.04. Create an imap folder with an umlaut in its name, like "testü". Create a filter rule that moves messages to this folder. Drag and drop the imap folder into another folder, e.g. make it "testsub/testü". Actual results: The "move to" filter field shows an empty string; The filter rule will not move matching messages. Expected results: The filter target should have updated correctly.
Component: Folder and Message Lists → Filters
Product: Thunderbird → MailNews Core
Following is Tb 13.0.1 behavior on MS Win-XP, with Gmail IMAP, with Offline-use=Off for simple testing. (1) Under ABC folder, rename existent IMAP folder(AA for example) to "A日本語". Modified utf-7 string of Mbox name = A&ZVnLIqe- Folder Property, Location = imap://yatter.one@imap.gmail.com/ABC/A%E6%97%A5%E6%9C%AC%E8%AA%9E Used file name = A日本語.msf (2) Rename "A日本語" to "B日本語". Modified utf-7 string of Mbox name = B&ZVnLIqe- Folder Property, Location of "B日本語" imap://yatter.one@imap.gmail.com/ABC/B%E6%97%A5%E6%9C%AC%E8%AA%9E Used file name = B日本語.msf Note: "A日本語" was not removed from folder pane. (3) Click non-removed "A日本語" folder The current operation on 'A日本語' didn't succeed. ... server responded: [NONEXISTNT] Unknown Mailbox: ABC/A&ZVnLIqe- (Failure) (4) Click new "B日本語" folder The current operation on 'B日本語' didn't succeed. ... server responded: [NONEXISTNT] Unknown Mailbox: ABC~B&ZVnLIqe- (Failure) Note: "^" instead of "/". (5) Restart Tb, open ABC folder(parent folder) Folder Property, Location of "B日本語" imap://yatter.one@imap.gmail.com/ABC/B%26ZeVnLIqe- Used file name = B&ZeVnLIqe-.msf File of B日本語.msf was not deleted. Note: Non existent "A日本語" folder disappeared at folder pane. (6) Create message filter rule of "Move to B日本語". action="Move to folder" actionValue="imap://yatter.one@imap.gmail.com/ABC/B&ZeVnLIqe-" It works well. (7) Rename "B日本語" to "C日本語". Modified utf-7 string of Mbox name = C&ZVnLIqe- Folder Property, Location of "C日本語" imap://yatter.one@imap.gmail.com/ABC/C%E6%97%A5%E6%9C%AC%E8%AA%9E Used file name = C日本語.msf msgFilterRules.dat was automatically changed to following. actionValue="imap://yatter.one@imap.gmail.com/ABC/C日本語" (8) Edit the message filter rule. - "Move target folder" field was blanked out. - Even when ABC/C日本語 was selected at folder selection UI, nothing was shown at "move target folder" field. i.e. Unable to select renamed folder. (9) Restart Tb, open parent folder(ABC in this test). Folder Property, Location of "C日本語" imap://yatter.one@imap.gmail.com/ABC/C%26ZeVnLIqe- Used file name = C&ZeVnLIqe-.msf Selection of ABC/C日本語 was possible at Edit of the message filter rule, and following was correctly written in msgFilterRules.dat. actionValue="imap://yatter.one@imap.gmail.com/ABC/C&ZeVnLIqe-" This problem is not message filter bug. This is problem in back end of IMAP folder when "Modified utf-7 Mbox name" != "IMAP folder name for Tb". Message filter is a victim. And, this was not newly generated problem. Problem was observed in Tb 3.1.20, 8.0.0, 9.0.1, 10.0.1, 11.0.1, and Tb 13.0.1. Confirming.
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Filters → Backend
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Summary: filter rules incorrectly updated when moving an IMAP folder containing umlaut → filter rules incorrectly updated when moving an IMAP folder containing umlaut (problem when modified utf-7 of Mbox name != IMAP folder name for Tb)
Correction. At step (9), used file name was not changed by restart of Tb. Used file name = C日本語, instad of &ZeVnLIqe-.msf Relation between file name and folder name is kept in panacea.dat and the cached data is used. So, if panacea.dat is deleted and Tb is restarted, "modified urf-7 string of Mbox name" is used elsewhere as expected by Tb. (a) If newly created Mbox by Tb(for example, ABC/X日本語), or already existent IMAP folder and folder name is initially obtained via SUBSCRIBE or LIST command, following is used by Tb as expected. Modified utf-7 string of Mbox name = X&ZVnLIqe- Folder Property, Location of "X日本語" imap://yatter.one@imap.gmail.com/ABC/X%26ZeVnLIqe- Used file name = C&ZeVnLIqe-.msf actionValue="imap://yatter.one@imap.gmail.com/ABC/X&ZeVnLIqe-" (b) "Move IMAP folder under same IMAP account" is internally same as "rename IMAP folder". These explain phenomenon you saw by "create IMAP folder with umlaut" + "move the IMAP folder".
Summary: filter rules incorrectly updated when moving an IMAP folder containing umlaut (problem when modified utf-7 of Mbox name != IMAP folder name for Tb) → filter rules incorrectly updated when moving an IMAP folder containing umlaut (problem in rename of IMAP folder when "modified utf-7 of Mbox name" != "IMAP folder name for Tb")
This bug occurs even on 7bits-ascii only IMAP Mbox name if "&" is contained in Mbox name, because "modified utf-7 string for letter of &" is "&-". Above error in step (3)/step (4) is observed by rename AA to 1&A, and rename 1&A to 2&B.
Component: Backend → Networking: IMAP
Summary: filter rules incorrectly updated when moving an IMAP folder containing umlaut (problem in rename of IMAP folder when "modified utf-7 of Mbox name" != "IMAP folder name for Tb") → filter rules incorrectly updated when moving an IMAP folder containing umlaut (rename of IMAP folder doesn't use modified utf-7 string as internal folder path when "modified utf-7 of Mbox name" != "IMAP folder name for Tb")
If IMAP folder is renamed to Mbox name of "modifid utf-7" != "folder name for Tb", "move target folder not found" and "blank move target folder" can occur upon restart of Tb. (1) Move target folder of a mesae filter rule = AA Folder properties/location : imap://yatter.one@imap.gmail.com/AA Used file name : AA.msf Message filter rule : actionValue="imap://yatter.one@imap.gmail.com/AA" (2) Rename AA to A&1 Modified utf-7 of A&1 == A&-1 Folder properties/location : imap://yatter.one@imap.gmail.com/A%261 Used file name : A&1.msf Message filter rule : actionValue="imap://yatter.one@imap.gmail.com/A&1" At this stage, message filter works, because there is no mismatch exists between internal path of mail folder and actionValue. Folder of A&1 is shown at edit panel of message filter rule. (3) Restart Tb, access Inbox(login is done, Mbox name is obtained) Modified utf-7 of A&1 == A&-1 Folder properties/location : imap://yatter.one@imap.gmail.com/A%26-1 Used file name : A&1.msf (not changed, due to cached data in panacea.dat) Message filter rule : actionValue="imap://yatter.one@imap.gmail.com/A&1" actionValue of message filter rule is not automatically changed by Tb because "rename event" doesn't happen. So, if messsage filter runs, "move target folder not found" happens. (4) Edit the message filter rule. Move target folder field is blanked out. Re-selection of folder named "A&1" is possible, and following is written. Message filter rule : actionValue="imap://yatter.one@imap.gmail.com/A&-1"
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Severity: major → normal
Summary: filter rules incorrectly updated when moving an IMAP folder containing umlaut (rename of IMAP folder doesn't use modified utf-7 string as internal folder path when "modified utf-7 of Mbox name" != "IMAP folder name for Tb") → filter rules incorrectly changed when moving an IMAP folder containing umlaut (rename of IMAP folder doesn't use modified utf-7 string as internal folder path when "modified utf-7 of Mbox name" != "IMAP folder name for Tb")
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.