Closed Bug 505759 Opened 15 years ago Closed 15 years ago

Upgrading Thunderbird 2.0 -> 3.0beta3 marks all folders as "Select this folder for offline use" and accounts as "Keep messages for this account on this computer"

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: hpa, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1) Gecko/20090630 Fedora/3.5-1.fc11 Firefox/3.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 I have a very large number of IMAP folders, many of which contain hundreds of thousands of messages. It was suggested that I'd try Thunderbird 3.0beta3 to get better performance (which is good.) However, when I upgraded, it marked the account as "Keep messages for this account on this computer". After finding that checkbox and turning it off (I really don't want it to download several million email messages) it seems to have spontaneously set the "Select this folder for offline use" flag on a large number of my folders, apparently at random. I have no idea which ones are affected, and I have mostly found out by which ones Thunderbird suddenly decide to start downloading. Needless to say, this is rather disturbing. I have a lot of folders, and going through a multi-click sequence for each one of them to check for the flag would take a long time. (Also do keep in mind that there are people who export all of Usenet to IMAP.) Reproducible: Didn't try Steps to Reproduce: 1. Upgrade an IMAP profile from Thunderbird 2 2. 3. Actual Results: Both the account, and some random set of folders set to auto-download. Expected Results: Thunderbird should not change my defaults behind my back. This is an upgrade from the standard Fedora 11 build to the 3.0beta3 binary from mozilla.org.
The better performance is mainly obtained through having your IMAP folders set to offline. The change in behaviour was detailed in the beta 2 release notes, but got missed from the beta 3 notes: http://www.mozillamessaging.com/en-US/thunderbird/3.0b2/releasenotes/#whatsnew You shouldn't need a multi-click process to disable each folder. Select one of your imap folders, then File -> Offline -> Offline Settings. The account manager will then come up, on the right-hand side click Advanced under Message Synchronization, you can then go through your folders with one-click per folder.
& i'm the one who did it to him
I could be wrong, but it definitely looks like performance on online folders is better, too: I don't get the minute-plus-long freezes when thunderbird suddenly decides to start read an .msf file from the top down for no apparent reason. At the same time, I have to admit being surprised that the IMAP .msf files are text files. I would have thought a binary database would be able to get better performance (and since this is non-precious data, should be safe.) As far as the suggestion in comment #1, the Advanced box is greyed out unless I select "Keep messages for this account on this computer". Turning it back on enabled this, but I still had to click through every folder and expand every hierarchy. Now, I realize I'm a rather extreme power user, but still (somewhere around 1,500,000 emails across 613 active folders; the biggest folder is about 300,000 emails.)
(In reply to comment #3) > As far as the suggestion in comment #1, the Advanced box is greyed out unless I > select "Keep messages for this account on this computer". Turning it back on > enabled this, but I still had to click through every folder and expand every > hierarchy. Toggling the checkbox should affect all folders of that account, thus switching it on and then off again should reset the offline status for all folders. Note that bug 482476 and bug 506024 are aiming for options to cap disk space and download rate for offline copies, thus limiting the issues you mention.
Well, it doesn't seem to; in particular, toggling that checkbox OFF doesn't seem to properly prevent downloads -- in fact, I see all the folders still being downloaded.
Summary: Upgrading Thunderbird 2.0 -> 3.0beta3 marked a bunch of folders as "Offline" → Upgrading Thunderbird 2.0 -> 3.0beta3 markes of folders as "Offline"
For what it's worth, I might have fumble-fingered somewhere. With 3.0beta2 the following works for me: a) as quickly as possible, unmark "Keep messages" b) shut down Thunderbird c) DELETE ALL NON-.msf FILES IT CREATED IN THE ImapMail DIRECTORY *It seems to me* that step (c) has to be performed manually, or it will still try to download files for the folders it already started...
Keywords: qawanted
I believe: Tb3 shouldn't change(enable) folder property of "select this folder for offline use" of all IMAP folders by upgrade from Tb2 to Tb3, without user's permission. Tb3 shouldn't force Tb2 users who upgraded to Tb3 to use auto-sync with offline use setting enabled for all IMAP folders. I think "Keep messages for this account on this computer" should be defaulted to Off in Tb3 final release build. Defaulting of "Keep messages for this account on this computer" should be limited to Tb3 beta builds for testing. > mail.server.serverN.offline_download : true / false Mark Banner, Wayne Mery, rsx11m, what do you think? Please note next. Even if per account auto-sync=off is defaulted, new user can use it with single click, if user wants to enable per account auto-sync. Even if per account auto-sync=off is defaulted, Tb2 user who already used auto-sync can continue to use auto-sync by single click or by enabling offline use setting of some IMAP folders.
From the feedback I see there are quite a few IMAP users surprised to find their profiles growing to several gigabytes and to see substantial network traffic in the background. Per bug 385502 comment #18, a migration message was initially planned to notify the user of this change, but then quickly discarded as that change would be announced in the release notes. Unfortunately, not many users seem to read those release notes, thus a more explicit notice may help to avoid user confusion (possibly with an "not now" option). (In reply to comment #4) > Note that bug 482476 and bug 506024 are aiming for options to cap disk space > and download rate for offline copies, thus limiting the issues you mention. While those bugs would reduce the impact, by default they may be set to apply no restrictions, thus wouldn't help the unsuspecting user either. If also Gloda-indexing is activated by default as planned, activity for IMAP syncing and indexing at the same time could pose some drag on performance for migrating (or new) users, so that aspect may be part of the equation as well.
Per design... -> WONTFIX
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Keywords: qawanted
Resolution: --- → WONTFIX
Summary: Upgrading Thunderbird 2.0 -> 3.0beta3 markes of folders as "Offline" → Upgrading Thunderbird 2.0 -> 3.0beta3 markes all folders as "Offline"
Status: RESOLVED → VERIFIED
Summary: Upgrading Thunderbird 2.0 -> 3.0beta3 markes all folders as "Offline" → Upgrading Thunderbird 2.0 -> 3.0beta3 marks all folders as "Select this folder for offline use" and accounts as "Keep messages for this account on this computer"
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
I adamantly agree with WADA - TB should absolutely *not* *never* *never* mess with my settings like this. Consider: I have 16+ IMAP accounts, some with 10+ GB of email in them, most with dozens and some with *hundreds* of folders, with only a select few set to full offline mode. For TB to arrogantly presume to ignore my carefully selected settings, when it could *very* easily* simply honor them, is just plain wrong. Please note: I'm sorry, but I'm only showing a little attitude in this comment because of the arrogantly dismissive comment by Magnus Melin saying 'Per design... -> WONTFIX. I've been using TB since about version 0.8, and this upgrade to TB3 is the first time I've been considering switching clients. I love TB, but this attitude of 2 or 3 developers shoving stuff down our throats because 'they knwo whats best' is getting old. (My other major peeve is the inability to force the Calendar to open in the current Tab *and* the ability to move the calendar toolbar buttons to another toolbar.)
So, Magnus' arrogance rules. Sad. And I am now seeing more and more threads in lots of different forums where people are reaming TB3 a new one, all because of the performance SLAM when TB starts downloading GBs of messages and indexing them at the same time. Good job, Magnus. Are you happy now? At the *very* least, TB should *not* start downloading messages or indexing anything until the user has the chance to tell it *not* to in the Migration tab.
(In reply to comment #13) > So, Magnus' arrogance rules. Sad. WONTFIX is reflective of drivers' decision which iirc are 8+ people, the resolution isn't Magnus' decision. It's useful to remember that * Reports of performance issues are often not being properly diagnosed, and in general are being dropped at the doorstep of gloda or autosync, when in fact a good percentage of issues are turning out to be antivirus, add-ons, etc. https://bugzilla.mozilla.org/buglist.cgi?keywords=perf%20hang;keywords_type=anywords;resolution=INVALID;chfieldto=Now;chfield=resolution;query_format=advanced;chfieldfrom=60d;chfieldvalue=invalid;product=MailNews%20Core;product=Thunderbird lists a few (and doesn't include the many duplicate bug reports). * The user is being given a choice via migration assistant But indeed, there are solid cases of problems ... and so in partial response to wada's question in comment 8, I lean toward "TB should *not* start downloading messages or indexing anything until the user has the chance to tell it *not* to in the Migration tab." which is why I filed bug 520247 - consider making Migration Assistant be "sticky", and which in hindsight probably doesn't go far enough. 1. MA might require an explicit choice by the user before the user can proceed and the tab can be closed 2. the user might be helped by having more information about the account's, and about the possible impact of their choice Unfortunately, a) I'm not sure 1. is easily done b) some information is hard to get ... much disk space will be used? can my computer handle the overhead? c) assuming the user had such information, what percentage are capable of making such a smart choice Also consider that people often view performance not in the context of the benefits of the new stuff they are getting, but by "how it used to work. So I think the developers, who were aware of these issues at the time, got the decision right at the time. And are getting the hoped for feedback that will help fix issues that make this default value the overall best choice. WONTFIX of default=offline doesn't mean we can't give the user a better experience. And there aren't many big issues to tackle: a) improve Migration Asst (needs bug?) b) more testing on small/old computers? c) address the major bugs that emanate from gloda and autosync: * bug 506024 Enable Download rate policy for autosync (not nominated for blocking) * Bug 530098 - gloda deletion processing is more expensive than it needs to be (nominated for blocking) d) some gmail bugs? It would help if these were designated as strong goals for 3.1, and accepted ~blocking (if not also being pushed into 3.0 before auto-update is turned on). questionable: * Bug 519543 - Gloda search while indexing hangs and is very slow; search activity should suppress indexing there is also a need for the community to pound on the following UNCO bugs to find which are valid issues https://bugzilla.mozilla.org/buglist.cgi?keywords=perf;chfieldto=Now;query_format=advanced;chfield=[Bug%20creation];keywords_type=allwords;chfieldfrom=150d;bug_severity=blocker;bug_severity=critical;bug_severity=major;bug_status=UNCONFIRMED;resolution=---;product=MailNews%20Core;product=Thunderbird
(In reply to comment #14) > * bug 506024 Enable Download rate policy for autosync (not nominated for > blocking) For the record, both bug 506024 and bug 508276 were nominated to block TB 3.0, which got denied in both cases. The line of argumentation to either bug didn't change, bandwidth is a non-neglectable issue for many IMAP users and with certain providers or types of service. Since there is no indication that the opinion of the drivers changed, and also given the rather aggressive schedule for TB 3.1, I didn't see any point thus far in renominating them. But please, go ahead if you feel that these bugs got a chance.
FYI. Next bug is a request for Tb 3.1 in this area. > Bug 541209 Profile Update should honor existing offline folder settings
(In reply to comment #14) > (In reply to comment #13) >> So, Magnus' arrogance rules. Sad. > WONTFIX is reflective of drivers' decision which iirc are 8+ people, > the resolution isn't Magnus' decision. Ok, my apologies then to Magnus for singling him out. Now, unless someone explain to me in simple terms why you think it is ok to ignore a users existing and often carefully chosen offline settings - seriously, I can't even think of a *bad* reason, much less a good one - I redirect my prior comment to the 8+ drivers who made this bone-headed decision. What *were* you guys thinking? Look. I don't mean this as an insult or anything. My comments below are reflective of my passion for Mozilla products in general. I want TB to be the best it can be. I'm here, yelling at you guys, because *I* *care*. I sincerely hope you understand that. I make bone-headed decisions sometimes, but I also own up to them and do what I can to make it right once I realize it, I don't continue to defend it. What I would *like* to hear from those responsible for this one is something like 'yeah, we made a bad decision here, sorry about that, and we're fixing it for the next release.' > It's useful to remember that > * Reports of performance issues are often not being properly > diagnosed, and in general are being dropped at the doorstep of gloda > or autosync, when in fact a good percentage of issues are turning out > to be antivirus, add-ons, etc. True enough, but that only accounts for *some* of them. A *lot* of them are people like me with many IMAP accounts and many many GBs of messages. Another bunch are ones experiencing the bug that kicks in when profiles are on network shares. That's another one that should have been caught before release. Does no one test in a network environment? Now, combine these two real problems - one intentional (ignoring existing offline settings) and one unintentional (network performance bug) - and you have hundreds of people screaming in the forums and rightly so. Lots of people will fix the problems caused by AV themselves, either because they're saavy enough to know to look for that, or by googling. > * The user is being given a choice via migration assistant Choice? Come one. Why are you continuing to defend a bad decision? The fact is: 1. the downloading/indexing begins *immediately* and doesn't stop if you change it until TB is restarted, and 2. many (most?) people will simply close the migration tab immediately without reading it, and 3. *everyone* who, like me, took the time to carefully select certain folders for offline use and not others, will be surprised *and offended* by the upgrade process totally ignoring their settings. Now, if the migration window was a pop-up with a big fat warning about the consequences of setting everything to full offline mode, *and* that blocked TB from doing anything until after the decision was made, that would have made a big difference - but I *still* would have been very upset that there wasn't a *third* option that was *the default*, which was simply 'Keep my current offline folder settings'. In case you hadn't noticed, this particular BUG bit me big time. I have 16+ IMAP accounts, some with dozens, and a couple with *hundreds* of folders, with *only* a very few *select* folders set to offline mode. I was absolutely *furious* (can you tell? I'm still steaming about it) when I learned that TB arrogantly ignored my carefully chosen settings. My personal opinion is that this should absolutely be fixed *now* - for 3.0.2, not for 3.1 - and it should be a blocker. Oh - and by the way - I wouldn't have even *noticed* this issue had the third option (to honor my existing settings) been the default. Making full offline mode the default for *new* accounts is another matter. But how someone could think this was a good idea for *existing* accounts I will never understand. > But indeed, there are solid cases of problems ... and so in partial > response to wada's question in comment 8, I lean toward "TB should > *not* start downloading messages or indexing anything until the user > has the chance to tell it *not* to in the Migration tab." As long as it is *blocking*, and contains with a very prominent warning, *and* has a new *default* option to honor the *existing* settings, that would be acceptable. Look, if this was complicated to do, I can understand some opposition, but I'm sorry, I know enough about programming to know that this could not *possibly* be that complicated. Why is this so hard to comprehend? LEAVE MY CAREFULLY SELECTED OFFLINE SETTINGS ALONE. PERIOD. bug 541209 > So I think the developers, who were aware of these issues at the > time, got the decision right at the time. I'm sorry, but changing my existing settings for absolutely no reason other than you think it is a good idea was not, is not now and never will be 'the right decision'. Your comment just shows more arrogance - again. > a) improve Migration Asst (needs bug?) bug 541209 > It would help if these were designated as strong goals for 3.1, and > accepted ~blocking (if not also being pushed into 3.0 before > auto-update is turned on). If you guys turn on auto-update before providing a new *default* option to honor existing offline settings for existing accounts, then you will deserve the firestorm of complaints you will get, and the potential loss of lots of loyal users. For new accounts, I still think only the Inbox should be set to full offline mode, but that's just me - I can see the argument for making everything offline, so won't argue much about it other than to make my personal opinion known.
(In reply to comment #16) > FYI. Next bug is a request for Tb 3.1 in this area. >> Bug 541209 Profile Update should honor existing offline folder settings Why wait for 3.1? This should be a very simple fix. sheesh.
(In reply to comment #18) > (In reply to comment #16) > > FYI. Next bug is a request for Tb 3.1 in this area. > >> Bug 541209 Profile Update should honor existing offline folder settings > > Why wait for 3.1? This should be a very simple fix. sheesh. because 3.0 is string frozen, and because it must be first tested on 3.1?
But this isn't an extremely complex new feature. This is a very simple 'import the existing settings' thing. It is *simple*, and should *not* require the same kind of review that new features require. But, at a bare *minimum*, this *must* be a blocker before Auto-Update is enabled.
Ok, something is getting lost in all the back and forth. I would appreciate it if one or more of the appropriate devs would please answer the following two questions: 1. Do you or do you not agree that honoring the end users carefully selected offline settings is a reasonable thing to do? 2. Do you or do you not agree that enabling Auto-Update for TB before fixing this problem *correctly* - ie, making the honoring of a users existing offline settings the *default* - would be a potential disaster? If yes, then please *say* so. If not, then please provide a rational explanation of *why*. The fact is, I've not seen even one of the devs acknowledge that the users existing settings *should* in fact be honored.
I think it should be an option in the migration assistant, and the MoMo staff all agree that the migration assistant needs to be more "noticeable".
(In reply to comment #22) > I think it should be an option in the migration assistant, and the MoMo staff > all agree that the migration assistant needs to be more "noticeable". You don't think it should be the *default* behavior?
No, I don't. Things like global search don't work unless we turn on autosync. I agree that there is an issue with new imap accounts and the new account wizard where it's not possible to turn off autosync from the get go. I'm not saying I'd jump off a bridge if my friends did, but all other major mail clients download imap folders by default, so it's not quite the wild and crazy behavior that some have claimed. We just need to make it easy to turn off. I also think we should also do things like warn users with large imap folders about the disk space requirements in the migration assistant, and we should implement disk space limits.
(In reply to comment #24) > No, I don't. Things like global search don't work unless we turn on > autosync. Ok, so you're one of the 'arrogant' devs my original comment was aimed at. ;) Seriously - here comes some constructive criticism that goes to the heart of this discussion, and I hope you will take it as such: What makes you think *everyone* wants/needs the new Global Search? Arrogantly ass-u-me-ing that everyone does is the problem here, and why my comments have been so negative - and escalating - on this issue. The fact is, dovecot's server side index/search is faster than GLODA, but most importantly, vastly superior because it is *server-side*, ie, client independent. Read my lips (and no offense is intended, but no one seems to be getting what I'm saying): *I* *DON'T* *WANT* *YOUR* *SHINY* *NEW* *KNOB* (and I'm quite certain this goes for a lot of other people)! > I agree that there is an issue with new imap accounts and the new > account wizard where it's not possible to turn off auto-sync from the > get go. <sigh> More evidence that you aren't listening, and why I'm getting so frustrated... I'm not talking about *new* accounts, and that's *not* what this bug is about. I'm talking about a profile with *existing* accounts that is being *updated*. > I'm not saying I'd jump off a bridge if my friends did, but all other > major mail clients download imap folders by default, I don't think that is accurate. Outlook certainly doesn't (yeah, I know its IMAP support sux balls), and honestly, I don't know of another standalone client that has decent IMAP support, so that argument is kind of irrelevant. Let's make TB have the *best* IMAP support. > so it's not quite the wild and crazy behavior that some have claimed. Again - this bug is about the profile update process *ignoring* *existing* *user* *settings. It is *changing* the way I had it set before. Hello!? McFly!? Is anyone home??? > We just need to make it easy to turn off. What you need to do is *honor* *my* *existing* *settings*, dammit. > I also think we should also do things like warn users with large imap > folders about the disk space requirements in the migration assistant, > and we should implement disk space limits. Well, on this at least we can agree... :)
You're not listening. In reply to your question about keeping your 2.0 settings, I said "I think it should be an option in the migration assistant", i.e., keep your 2.0 offline settings.
On the contrary, I'm listening very closely. In response to my follow-up question you said it should *not* be the default, and the only comments in support that you had to offer - and that I shot all to hell - all had to do with *new* accounts and the *new account wizard*, as well as some new feature (GLODA) that you seem to believe the majority of users will want/need/love. Again, for the umpteenth time: Honoring the users *existing* settings should *always* be the default during upgrades, unless there is a *damned* good reason. Anyone who disagrees with this philosophy is, imnsho, an arrogant ass, and that is the whole point. Now, I think I've made my position clear, and your response(s) have and will make yours obvious to everyone bothering to read this long and twisted (because you guys keep going off point) exchange, so I'll try not to continue to beat the dead horse.
Charles, please observe the etiquette rules for bugzilla. Thanks. It's not a dead horse, there is still bug 541209 pending, where this recent discussion should have been placed to start with (less the language).
Charles: enough, OK? Don't make me choose between having happy developers and you being able to continue to comment. Because I'll pick happy developers every time. Gerv
True - and my sincerest apologies for the language. I just got back from the bathroom and dousing my face with a bunch of cold water, ran around the building, and did some boxing with a tree. I'm calmed down now, but my fingers are a bit bloody... Seriously - I do apologize to David, Wayne and anyone/everyone reading, for the tone and language in some of these comments, but the heart and soul of them remains. I am simply very frustrated at what appears to be a disconnect between two totally different aspects of this: 1. New accounts, and 2. Upgrading profiles that already have user defined settings. David is the only one to specifically answer my two questions in comment 21, and I am baffled at how he could be of the position that it is ok to have the default behavior for upgrading a users profile to be to simply ignore that users specifically and intentionally (and in my case very carefully planned) offline settings. If I wanted them to all be offline, I would have set them up that way. I don't understand this. But I guess since I am a lowly user, it doesn't matter. But imo it doesn't bode well for the future of TB.
After a private exchange with Wayne, I think that there was a serious misunderstanding, at least partly (if not all) mine. In essence Wayne said that what was now being planned is a blocking (cannot simply close it and no 'OK' button) Migration Assistant with a 3rd option to 'Keep my offline settings', and nothing at all happens unless/until the user picks one of the 3 choices. David, if this is what you meant, then I can only say what I said to Wayne... "Or... wait... so, there really isn't a 'default' then? There are simply three buttons, and no 'OK' or 'Close' button with a 'default' action that will reset the users settings. Well dang it all, why didn't you guys say so! :) Ok, that will work for me... <sigh> I really need to learn to calm down before posting anything that I typed while in a highly agitated/frustrated emotional state. My apologies for all of the **** today..." I was focusing on 'the default', and no one bothered to explain/point out that there wouldn't *be* a default, since the user has to click one, and cannot simply close the tab or click 'OK' to invoke a 'default'. So, my apologies to all. I'll shut up now about this, and will try very hard to be less confrontational *and* less of a butthead (yes, I know I can be one) in the future, and try to figure out instead just how *I* might be misunderstanding something.
(In reply to comment #31) > After a private exchange with Wayne, I think that there was a serious > misunderstanding, at least partly (if not all) mine. > > In essence Wayne said that what was now being planned is a blocking (cannot > simply close it and no 'OK' button) Migration Assistant with a 3rd option to > 'Keep my offline settings', and nothing at all happens unless/until the user > picks one of the 3 choices. That's my thinking, and perhaps what david may be saying - but I'm not saying it's a plan, and there may be other ways to accomplish the goal (or 90% of it) in a simpler way. Lots of details and workflow to think through, and related bugs. >will try very hard to be less confrontational *and* less of a butthead (yes, I > know I can be one) in the future, and try to figure out instead just how *I* > might be misunderstanding something. a good goal. an exercise that may help while in a frustrated mood is to write something, walk away from it for several hours or a day, and when you come back reexamine what you wrote: a) is it accurate from several points of view, b) how will the message be received, c) would you use the same tone and wording face to face with a friend, etc?
We all agree that it's way too easy to miss the questions the migration assistant asks and plan to fix that for 3.1. I'm not sure what the UI is going to look like for 3.1 - that's clarkbw's bailiwick (Bryan, you're welcome!). We also agree that we need to give the user more information to help make their decisions (e.g., if they have 10GB of messages on the imap server, we'd want to tell them how much extra disk space is going to be consumed).
Yeah, I know... and I do that quite often, but this particular issue is very important to me, and I got sucked into a frustration vortex - and it doesn't help that I type pretty fast. One more really frustrating thing is sometimes I ask very precise, specific questions, and get off-point, vague or no answers at all. For example, I've been waiting for a response to 6 specific questions so I can get to work on the wiki page to try to bring a lot of these IMAP issues together (since that is the thing most important to me and since I'm not a programmer, this is the only way I can help), but no one will respond: https://bugzilla.mozilla.org/show_bug.cgi?id=508276#c28
Thanks David - but would you mind actually confirming *how* this will be fixed? Will it be fixed the way I described? Specifically, with a blocking Migration Assistant that doesn't have a 'default' behavior, but simply waits until the user makes their choice(s) before continuing on with establishing account connections etc? Thx...
As I said, "I'm not sure what the UI is going to look like for 3.1" because a) I don't decide the UI, and b) I don't think Bryan has decided yet. I'll try to answer your questions in bug 508276 as soon as I have a chance.
Ok, I guess 'I'm not sure what the UI is going to look like' translates to 'I don't know what the actual behavior is going to be yet'. UI != behavior (necessarily) So, is Bryan the only one who decides on the actual end-result behavior? If so, maybe he and I can put on the gloves and go a few rounds (off-bug of course... ;)
Following is copy of Bug 508276 Comment #31 by David:Bienvenu. > > 1. When 'Synchronization & Storage' > 'Keep messages for this account on this > > computer' is *not* checked, what, precisely, does TB3 download? Is it only the > > 'Normal' headers and not the full headers? Does it download any of the body > text? > That setting only affects whether newly created folders will be set for offline use. > It does not control autosync directly. > Autosync will only download the bodies of messages in folders that are set for offline use. Culprit was unable-to-understand-why (wrong for Charles Marcus and me) behaviour of UI upon check/uncheck of 'Keep messages for this account...". Unchecked=>Checked: Set offline use=on for all folders of the IMAP account. Checked=>Unchecked: Set offline use=off for all folders of the IMAP account. I should have requested to disable such behaviour in this bug, instead of requesting "default of auto-sync=off" for which WONTFIX sounds reasonable...
There are two kinds of issue around auto-sync of Tb. (1) Mismatch among implementation of auto-sync of Tb3, preference names, terms in UI, behaviour of UI, which causes bad/unexpected behaviour for user. > mail.server.default.autosync_offline_stores : same as Tb2. Tb2:default=false, Tb3:default=true > true : auto-sync is enabled for any IMAP account since Tb2 > false : auto-sync is disabled for any IMAP account since Tb2 > Auto-sync of Tb3 now respects per folder "offline use" of IMAP folder. > mail.server.serverN.offline_download : new by Tb3. default for "offline use" of IMAP folder of the IMAP account. > true : "offline use=on" is set when folder is created/subscribed under the IMAP account > false : "offline use=on" is set when folder is created/subscribed under the IMAP account Confusing terms in UI is probably a result of confusing preference names. Confusing behaviour of UI may be a result of the confusing preference names. (2) Real bugs, performance problems, insufficient functionalities, ... For (1), current UI, current behaviour of UI: Upon check/uncheck of 'Keep messages for this account...", UI does do next. > Unchecked=>Checked: > Set mail.server.serverN.offline_download=true (default=true, so it's reset). > Set "offline use=on" for all folders of the IMAP account. > Enable "Advanced" button to manage "offline use" of IMAP folders. > Checked=>Unchecked: > Set mail.server.serverN.offline_download=false. > Set "offline use=off" for all folders of the IMAP account. > Disable "Advanced" button to manage "offline use" of IMAP folders. Same action as Unchecked=>Checked is done upon migration. If current behaviour of UI is correct, terms in UI should be changed appropriately. If current terms in UI is correct, behaviour of UI should be changed appropriately. Current terms in UI/behaviour of UI is better to be changed to one which is consistent with current implementation of auto-sync of Tb3 and pref.js entries for it. Some bugs are already opened for such changes, but I don't know bug numbers for them. Some bugs were opened due to confusing terms in UI. - Request of seprated setting for default of "offline use" of new IMAP folder. As already written in this bug, option for auto-sync upon migration is already requested.
You need to log in before you can comment on or make changes to this bug.