Created attachment 577106 [details] button always disabled User Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 2011110500 Steps to reproduce: I have decided to use Thunderbird to access my Gmail account using IMAP. But Thunderbird always marks it as gmail account. If I change options mail.server.serverX.is_gmail to false, Thunderbird changes it to true. So, I cannot change settings for "archive" mailbox because button is always disabled (((. Thunderbird always shows me that "all mail" mailbox is archive mailbox.
(In reply to Dmitry from comment #0) > If I change options mail.server.serverX.is_gmail to false, Thunderbird changes it to true. > So, I cannot change settings for "archive" mailbox because button is always disabled > (((. Thunderbird always shows me that "all mail" mailbox is archive mailbox. It's intentionally done due to; (A) Gmail's Archive at Web Interface is always same as "move to All Mail(==[Gmail]/All Mail folder via Gmail IMAP)". To avoid frequent unwanted bug open by general users at B.M.O due to difference between Tb's archive and Gmail's archive, Tb's archive for Gmail IMAP is designed/implemented as consistent one with Gmail. (B) "Subfolder under [Gmail]/All Mail via Gmail IMAP" is never "subfolder of All Mail at Gmail". "Subfolder under [Gmail]/All Mail via Gmail IMAP", for example "[Gmail]/All Mail/2011", is merely a Gmail Label named "[Gmail]/All Mail/2011". Because "[Gmail]/All Mail" always holds data of any mail, "mail moved to [Gmail]/All Mail/2011" is always kept in "[Gmail]/All Mail" too. And, if a mail in "[Gmail]/All Mail/2011" is moved to Trash of Gmail(==[Gmail]/Trash via Gmail IMAP), the mail is removed from All Mail of Gmail(==[Gmail]/All Mail via Gmail IMAP) too. (These are design of Gail/Gmail IMAP and is by Gmail Help of Gmail.) To avoid frequent unwanted bug open by general users at B.M.O due to the particularities of Gmail/Gmail IMAP, Tb's archive for Gmail IMAP is designed/implemented as consistent one with Gmail. (C) Further, Gmail has length limitation in Gmail Label string(40 bytes). If "keep orginal structure upon archive" is supported for Gmail IMAP, path length easily exceeds this length limitation. This is another reason why "archive to subfolder" is currently not supported if Gmail IMAP. User can open any bug at B.M.O for Tb's behaviour what he wants. However, please read Gmail Help provided by Gmail well before open Gmail IMAP related bug at B.M.O.
Summary: Thunderbird sets my gmail account as gmail account → Thunderbird sets my gmail account as gmail account (mail.server.serverX.is_gmail is always set to true by Tb)
Not disagreeing with the design, but I wanted to point out that Gmail's labels are no longer limited to 40 characters.
But Thunderbird allows me to change archive mailbox (IMAP term). If I change archive mailbox in settings, Thunderbird moves archived mails to mailbox which is set by me. But I don't understand why Thunderbird doesn't allow me to set archive options.
Next, If I open "All mail" in Tb, can Tb show more 50000 mails? Web interface groups mails in pages (limited number of mails per page).
(In reply to Dmitry from comment #3) > But Thunderbird allows me to change archive mailbox (IMAP term). > If I change archive mailbox in settings, Thunderbird moves archived mails to mailbox which is set by me. Tb's UI for archive is designed/implemented so. User can choose other folder than [Gmail]/All Mail as "Archive folder". > But I don't understand why Thunderbird doesn't allow me to set archive options. What folder did you select as "Archive folder"? (i) Gmail IMAP's mail folder(Gmail Label at Gmail) (ii) Ordinal IMAP's mail folder (iii) Local mail folder(mail folder of POP3 account or "Local Folders") I could see "enabled Archive options... button" when I select (iii).
(i) GMail label (without "[Gmail]")
(In reply to Dmitry from comment #6) > (i) GMail label (without "[Gmail]") Try (ii) or (iii) too, please.
(In reply to Dmitry from comment #4) > Next, If I open "All mail" in Tb, can Tb show more 50000 mails? > Web interface groups mails in pages (limited number of mails per page). AFAIK, there is no specific limitation on "number of mails in an Mbox" in both Tb and Gmail IMAP, although Tb's mail folder file for Mbox has file size limitation(Local mail folder: 32bits integer, signed if Linux/Mac OS X or unsigned if Win, IMAP's offline-store: 64bits signed integer). However, there are known or possible problems when many mails exist in an Mbox. - Thread depth looks limited to 256. (If reply-to nest level is greater than 256, thread display at thread pane is corrupted.) - UID of mail is probably held in 32bits signed or unsigned integer by Tb. If UID sent from Gmail IMAP is larger than limit of the 32bits integer, something wrong may happen in Tb. - UI of thread pane may not be torelant with very many mails in an Mbox. Memory relevant problem may arise. - Perormance problem may arise in Tb, if very many mails are held in an Mbox.
(In reply to WADA from comment #7) > (In reply to Dmitry from comment #6) > > (i) GMail label (without "[Gmail]") > > Try (ii) or (iii) too, please. Button is enabled only for (iii)
(In reply to Dmitry from comment #9) > Button is enabled only for (iii) I couldn't see it. With Tb 8.0 on MS Win. (i-a) Archives folder of Gmail IMAP account : Button is disabled (i-b) Others:any folder of Gmail IMAP account : Button is disabled (ii-a) Archives folder of Yahoo IMAP account(@rocketmail.com): Button is enabled (ii-b) Others:any folder of Yahoo IMAP account : Button is enabled (iii-a) Archives folder of Local Folders : Button is enabled (iii-b) Others:any folder of Local Folders : Button is enabled
I think there is another solution to list archived mails - Virtual folder with enabled online search. Filter: date 01.01.2010 - 01.01.2011 gives me mails as folder Archive|2010
So this looks like it is working as designed. Can anybody decide on a WONTFIX?
Prior to upgrading to 17.0.2 would remain persistent: mail.server.serverX.is_gmail;false Every time I restart ThunderBird, the setting goes back to true. I have been archiving to Gmail under Archives/2012/2012-01 up to Archives/2013/2013-01 without issue. Was this an intentional change or was no regression testing performed on the Archive Options for Gmail?
(In reply to sunk818 from comment #13) > Prior to upgrading to 17.0.2 would remain persistent: > mail.server.serverX.is_gmail;false > Every time I restart ThunderBird, the setting goes back to true. > I have been archiving to Gmail under Archives/2012/2012-01 up to > Archives/2013/2013-01 without issue. Which case? (a) Even though server is not Gmail IMAP server, is_gmail=true is always set after Tb 12.0.2. (b) Server is actually Gmail IMAP, and mail.server.serverN.hostname == imap.gmail.com. (c) Server is actually Gmail IMAP, but mail.server.serverN.hostname != imap.gmail.com. What is your archive folder setting? > mail.identity.idX.archives_folder_picker_mode (1=selected at Other:, 0=selected by account choice) > mail.identity.idX.archive_folder > I have been archiving to Gmail under Archives/2012/2012-01 up to Archives/2013/2013-01 without issue. It sounds that you use mail.identity.idX.archive_folder=imap://...xxx.com/Archives instead of .../[Gmail]/All Mail. > Was this an intentional change or was no regression testing performed on the > Archive Options for Gmail? If (c), it's a pheomenon after fix of Bug 798663(status-thunderbird-esr17:fixed) which resolved problem of Bug 815087. Tb 17.0.2 now detects "Gmail IMAP or not" correctly. Your problem is following? Although other than "[Gmail]/All Mail" can be selected as archive folder at UI, and although "Archive" normally moves mail to the requested archive folder, "Archives Options..." is disabled and "archive to .../yy/mm" is impossible. (If so, I could see it in Tb 17.0.2 with Gmail IMAP.) (Over application of "restriction due to particurarity of [Gmail]/All Mail") (to Gmail IMAP folder which is merely an ordinal Gmail Label. ) By the way, see bug 829185 for trash at Server Settings case.
To bug opener and problem reporters: Because Bug 798663 is fixed and problm of "incorrect Gmail IMAP detection" is resolved by that bug, is_gmail is now correctly set based on X-GM-EXT-1 capability response always. And, is_gmail(incomingServer.isGMailServer) is used for getting X-GM-MSGID, X-GM-LABEL etc. So, if bug summary and symptom of comment #0 is actual problem of this bug, this bug is INVALID or WONTFIX. What is actual problem of this bug?
The problem is that is_gmail will always stay true even if we set it to false. The problem is that we as users have been using the software with is_gmail = false for over one year now. If you say this bug will not be fixed and there is no bug, then I will be very angry. I will speak badly of the software and look for another e-mail software to use.
sunk818, why do you need is_gmail = false? What features does it give you?
is_gmail is false allows IMAP accounts to use the Archive Options in Thunderbird. If is_gmail is true, that option disappears. When is_gmail = false, I can Archive e-mails by month... For example, Jan 2013 e-mails will go to /Archives/2013-01 If is_gmail = true, then any archived e-mail goes to /Archives only. You try archiving one year worth of e-mails in that one folder and see how long it takes to load the headers.
Just for reference, it seems this special-casing of Gmail was done in bug 475852. Hopefully it contains enough reasoning.
See Also: → bug 475852
Perhaps the problem description doesn't match what sunk818 is actually requesting, or perhaps a separate bug should be created to allow what sunk818 is requesting. I have the same problem/request. I have a Gmail account, which I am accessing in Thunderbird via IMAP. In addition to it being very frustrating to have the "All Mail" folder constantly show unread messages (which you have already marked as read in your Inbox), the "All Mail" folder takes forever to load/refresh/etc. because of the number of messages it contains. To resolve these issues, I changed the folder used for Archived messages to be a label I created called "Archives". Then I unsubscribed from the "All Mail" folder so that it would no longer show up in Thunderbird. This works fine for my needs. However, archived messages are put into the parent directory ("Archives") rather than a subdirectory (such as "Archives/2013"), and the "Archive options..." button is disabled, preventing me from changing this setting. This isn't such a big deal, once a year I'll just move the messages from "Archives" into "Archives/20xx", and then "Archives" will always be the archive folder for the current year. However, perhaps a happy medium would be to check the current setting for "Keep message archives in:". If it is set to "All Mail", then disable the "Archive options..." button. If it is set to anything else (such as "Archives") then enable the button. This sounds like it would be fairly simple to implement.
(In reply to Benjamin Kraus from comment #20) Following part in original report(comment #0) doesn't exist any more. > Thunderbird always shows me that "all mail" mailbox is archive mailbox. User can already select any folder of any account as Archive folder via UI. Therefore, this bug's request is apparently "is_gmail=false for Gmail IMAP account in Tb" only, even if start point of this bug was problem in archive settings for Gmail IMAP account. Please don't hi-jack bug. See bug 800035 for "Archive option(granuality) is not allowed even when other than [Gmail]/All Mail of Gmail IMAP(==Gmail Label) is selected". Currently, "no granuality if is_gmail==true" is hard coded. "Graying out of Archive Options... button at UI" was done to avoid user's confusion due to mismatch between "hard coded logic" and UI. Indepenent bug may be better for request to change 'forcing no granuality if Gmail IMAP' to optional, because current 'forcing no granuality if Gmail IMAP' is based on incident of "server is Gmail IMAP" istead of on "[Gmail]/All Mail is Archive in XLIST".
I had no intention of hijacking this bug. Based on the comments, it sounded to me like Dmitry (the origial reporter, comment #0) and sunk818 (comment #16) don't really care about whether "is_gmail" is true or false, they simply wanted the "Archive Options..." to be available. That was my problem when I found this bug, and that is why I was following this bug, so I thought my comments were inline with the purpose of the bug, even if they didn't completely agree with the title. I also thought my comments might be helpful to anyone who (like me) stumbled across this bug. If that isn't the purpose of this bug, then based on your comment #15 and command #21, I don't see why this bug even exists.
(In reply to Benjamin Kraus from comment #22) > they simply wanted the "Archive Options..." to be available. > That was my problem when I found this bug, (snip) If so, why not simply open crisp bug for the clear problem? This bug was opened with old Tb, with wrong request involved. After it, some changes are already done. - Archive setting can select any folder of any account alraedy. - setting logic of is_gmail is already improved(changed). - As I already wrote in bug 800035, what is cause is already apparent. So, requst should be done by crisp bug report. > If that isn't the purpose of this bug, then based on your comment #15 and command #21, I don't see why this bug even exists. No response from bug opener yet, and another request of "capability to change is_gmail to false even though Gmail IMAP" was added, and complaint on "No Archiv Option... for non [Gmail]All Mail Mbox of Gmail IMAP" is repeatedly added to this bug again, without appropriate bug summary change and suffcient correction of wrong request, ..., so we can't close this bug as IVALID nor WONTFIX, and we can't confirm this bug as valid request. I believe bug what started with wrong request merely produces confusion and chaos.
I believe change by Bug 798663(set isGmail based on X-GM-EXT-1 capability) is correct action, so closing as INVALID. "Inconvenience of you after the change" is already covered by other bugs. If closing is wrong, re-open, please.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.