David :Bienvenu Reporter
	Description • 25 years ago

In 4.5, when the user deleted an imap message, we would store an offline delete
and load the next message; then playback the offline delete. This bug is to do
the same thing in 5.0

	David :Bienvenu Reporter
	Comment 1 • 25 years ago

accepting

	David :Bienvenu Reporter
	Comment 3 • 25 years ago

I found a speedup for deleting imap messages - we were updating the source
folder each time, which can be expensive when the folder is large. The patch
changes delete to run the copy message process through the destination folder,
as God and Jeff intended.

	David :Bienvenu Reporter
	Comment 4 • 25 years ago

move perf to summary

	leger
	Comment 5 • 25 years ago

Adding perf to keyword field.

	David :Bienvenu Reporter
	Comment 6 • 25 years ago

not going to make it for beta. Too bad.

	David :Bienvenu Reporter
	Comment 7 • 25 years ago

moving to m16

	selmer (gone)
	Comment 8 • 25 years ago

Not M16 stopper.  Marking M17.

	David :Bienvenu Reporter
	Comment 9 • 25 years ago

I don't think this is going to happen in 5.0

	scottputterman
	Comment 10 • 24 years ago

moving to future milestone.

	Matthew T (active 1999-2002)
	Comment 11 • 24 years ago

Resummarizing for brevity.

Once this one-stage queuing of deletes/moves is implemented, the next step would
be to allow multiple deletes/moves to be in the queue at once, with the first
action from the queue being played back if there were no message loads pending
(that is, message loads for messages which hadn't already been deleted).

	David :Bienvenu Reporter
	Comment 12 • 24 years ago

adding mail3 keyword

	scottputterman
	Comment 13 • 24 years ago

How big do you think the performance impact would be on this? I always thought
the problem was that we want to prevent loading the message just in case the
user was deleting really quickly.

	David :Bienvenu Reporter
	Comment 14 • 24 years ago

the perceived performance impact will be the time it takes to do a delete
message url, so it will vary based on the connection speed, turnaround latency,
etc. The reason we want to do this is that to the user the next message will
start loading immediately. In 4.x, this was done by storing the delete as an
offline operation so that we would not lose track of the fact that the user
wanted to delete the message if something went wrong during the loading of the
message.

	scottputterman
	Comment 15 • 24 years ago

moving to mozilla0.9 and marking nsbeta1+.

	scottputterman
	Comment 16 • 24 years ago

moving to mozilla0.8 milestone.

	scottputterman
	Comment 17 • 24 years ago

moving to mozilla0.9

	scottputterman
	Comment 18 • 24 years ago

marking nsbeta1- and moving to future.

	Jarrod Gray
	Comment 19 • 23 years ago

Would it be at all possible to halt the load of a message then proceed to delete
it when the user hits delete? This would speed things up tremendously as now the
message has to be fully loaded and displayed before a delete is processed.

I've been looking through the imap code to see how one might do this but I've
not really found anything 'good' so far. Any pointers?

	David :Bienvenu Reporter
	Comment 20 • 23 years ago

yes, it's possible to do what you want - what we need to do is issue a pseudo
interrupt of the message load when delete is pressed. When we fetch messages, we
fetch them in chunks based on your connection speed from 5K -> 40K or more. What
a  pseudo interrupt is to simply read the current chunk and don't ask for any
more. This is opposed to a real interrupt, which is what happens when you press
stop, in which we kill the connection. We don't want to kill the connection in
this delete case because it would be more expensive to rebuild the connection
and folder selection state.

So, currently, if you click on a large message, then click on an other message,
we pseudo interrupt the first message load. We would just need to do this same
thing for when delete is pressed. Look at calls to PseudoInterruptMsgLoad. Hope
this helps.

	Jarrod Gray
	Comment 21 • 23 years ago

Sorry for the spam. These are just notes for myself to help me understand whats
going on when a message interrupted.

Have a message loaded fully, then hit "down-arrow, down-arrow":
  In nsImapService::DisplayMessage
  In nsImapService::FetchMessage
  In nsImapProtocol::PseudoInterruptMsgLoad
  interrupt msg load : FALSE
  End nsImapService::FetchMessage
  In nsImapService::DisplayMessage
  In nsImapService::FetchMessage
  In nsImapProtocol::PseudoInterruptMsgLoad
  interrupt msg load : TRUE
  End nsImapService::FetchMessage

Have a message loaded fully, then hit "down-arrow, delete":
  In nsImapService::DisplayMessage
  In nsImapService::FetchMessage
  In nsImapProtocol::PseudoInterruptMsgLoad
  interrupt msg load : FALSE
  In nsImapProtocol::PseudoInterruptMsgLoad
  interrupt msg load : FALSE
  End nsImapService::FetchMessage
  In nsImapMailFolder::DeleteMessages

  In nsImapService::DisplayMessage
  In nsImapService::FetchMessage
  In nsImapProtocol::PseudoInterruptMsgLoad
  interrupt msg load : FALSE
  In nsImapProtocol::PseudoInterruptMsgLoad
  interrupt msg load : FALSE
  End nsImapService::FetchMessage

	Jarrod Gray
	Comment 22 • 23 years ago

The more that I've looked into this - it seems that PseudoInterruptMsgLoad is
being called properly and it is working. I'm not sure if what I was seeing
before was a problem with a slow internet connection or what.

	Alexander Sack
	Comment 23 • 19 years ago

David,

this bug still applies? maybe its outdated and can be closed.

	David :Bienvenu Reporter
	Comment 24 • 16 years ago

fixed by bug 435153