456839 - nsAutoSyncManager needs to expose method(s) to cancel on going download operations

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Emre Birol]

In order to allow the user to cancel the auto-sync on a folder, nsAutoSyncManager should expose nsresult Cancel(nsIMsgFolder aFolder), nsresult CancelAll() APIs.

Comment 1

[David :Bienvenu]

a note about "cancelling" imap urls. If you break an imap connection, it is generally more expensive to re-establish the connection and get into the selected state in a folder than it would be to wait for the current operation to finish, if the current operation is kept to a reasonable size. That's why I suggested not doing a huge amount of work in each url.

Comment 2

[Emre Birol]

As you know we try to download messages in 50K groups, as long as they fit into this limit. But we don't partially download large messages since we don't have such mechanism in place afaik.. 

Is there an easy way to chunk background message downloads as we do for display?

Comment 3

[David :Bienvenu]

yes, you can do that, but you'll slow the download down quite a bit, which is also bad. 

I have a few suggestions 

1 - (stolen from Andrew) have a super-idle mode, and do large downloads in that mode. 10 seconds is what I would call barely idle - if you're idle for a minute, then you're pretty idle...

2. Don't kill the connection unless you're downloading a really large message that's going to take more than a few seconds to finish. E.g., if we're downloading a 51K message, I would not kill the connection. If we're downloading a 1MB message, it might be faster to kill the connection and start a new one. However, the time it takes to start a new connection is directly proportional to the number of messages in a folder. If a folder has 10K messages, it could take around .5MB of data just to re-establish the connection and to the flags sync, so again, maybe not such a great trade-off.

Comment 4

[Mark Banner (:standard8)]

I think this fine tuning can take place in beta 2.

Comment 5

[David Ascher (:davida)]

taking over for now, although i probably will need to find someone more familiar w/ that code to do it.

Comment 6

[David :Bienvenu]

taking, moving to b3

Comment 7

[David :Bienvenu]

If the user is canceling, I think dropping the connection as if they had pressed the stop button is the way to go. So as long as the auto sync code knows what url it is running, or the load group, this should be easy.

Comment 8

[David :Bienvenu]

moving to rc1 - I really haven't heard any feedback that this is a big issue w/ autosync. It's also unclear to me how the user would cancel autosync - is the idea that we would automatically abort an autosync message fetch if the user did something that required a connection to the folder currently being autosynced?

Comment 9

[Bryan Clark (DevTools PM) [:clarkbw]]

I think there were two cases we were originally supporting, the first might be solved by automatic means now.

1) Allow the user to cancel the autosync of any folder via a ( Cancel ) button on the activity manager activity items.

2) Allow the UI to override/cancel the autosync of any folder if a person clicks into that folder.

For 1) it seems like having the idle detection means that we won't often be in conflict with users and so it's unlikely they'll actually be seeing autosync progress while they are actively using Thunderbird.

Comment 10

[Mark Banner (:standard8)]

The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a result, we feel that this bug shouldn't stand in the way of all the other good work getting into the hands of users sooner rather than later. Therefore we are retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242 for more details. The 3.1 release is expected to be a quick release soon after Thunderbird 3.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Since the main point of 3.1 is to make a softer landing pad for Tb2 users at major update time, I think this does want to block; carrying over to the new multi-state flag.  bienvenu or clarkbw, now would be a good time to say something if you disagree...

Comment 12

[David :Bienvenu]

yeah, I'm not convinced this is really a big issue. Gloda gets in the way more noticeably than autosync, from what I can tell.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

I was working under the assumption that this would mostly be painful for folks who have very slow connections.  That said, I don't know how many people we've been seeing with that concern.  Roland, do you have any sort of feel for that?

Comment 14

[David :Bienvenu]

for those people, dropping the connection and rebuilding it is going to be painful, so the cure might be worse than the problem. Plus, we try to avoid downloading large messages in autosync up front anyway.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

I'm assuming the workflow here is likely to be:

1) autosync starts happening
2) user realizes that it's going to take forever (and, in the case of metered connections, cost them a bunch of $$$)
3) user aborts
4) if we're lucky, use figures out how to disable autosync
5) user reads in online mode

If we don't fix this, the user would need to disable autosync and then restart, and for metered connections, the meter would be running while they were trying to do that, unless they intentionally put Tb into offline mode.  

Am I understanding it correctly?

Comment 16

[David :Bienvenu]

In that situation, they could always shut down the app.  I think that's more likely than them bringing up the activity manager and clicking a cancel button.

I think the way out here is to change the migration assistant to be more in your face so that users are warned *up front* about what our behavior is going to be, so they can make an informed decision there.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Yeah, that sounds right to me too, and that will be tracked by a blocker bug flowing from <https://wiki.mozilla.org/Thunderbird:UX/Priorities/3.1>.  Removing the blocking indicator from this bug and adding wanted+.