A.L.E.C wrote:

Vladislav Bogdanov wrote:

...

How to reproduce (I tried to nail it down to the simplest case that shows error):

1. Open folder that contains a bit more messages then could be shown on

a single page (f.e. 41 message with 40 rows limit). 2) Select and delete any number of messages, but not one and not all. You may do it with either method (mouse or keyboard). 3) Try to select all messages on a page after remaining messages are loaded to list. Artifact is shown. You are unable to select one of messages (which has duplicate in another row).

I'm unable to reproduce this with current svn-trunk version. I'm also

I'm always reproducing this with clean current SVN roundcube, clean database, clean browser cache, clean cookies list. No plugins. No user settings.

I don't see where it could depend on options, the only relevent change in my config comparing to dist is $rcmail_config['delete_always'] = TRUE;

Changing it back to default value doesn't have any effect.

What else can affect is the order of message set. Im my case messages in a folder are NOT in a date-sorted order. So their ID's appear in RC list not in a numeric sorted order. I prepared that set by copying messages from various other folders.

Server-side versions and settings (although I can bet it doesn't have any influence): CentOS 5.3 PHP 5.2.8 (rebuild from recent Fedora) mysql server and library 5.0.45 DB collation utf8_general_ci SVN RC is installed in a subdirectory of a site

Client side: Firefox 3.5.2

In Eric's case messages are sorted by sender in a list. I'm able to reproduce this as well.

The only difference is that Eric is able to hit this at the first page in a thread-enabled view, while I hit it only at the last page of a message-list (when all messages in a list except several are deleted and the only page in a view remains),

unable to view this video file, so it's all that I can say.

It requires binary codecs from mplayer site to be installed. A bit of info is at http://www.mjmwired.net/resources/mjm-fedora-f11.html#binarycodecs

I attach a quickly-converted AVI.

Vladislav

--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/rd/tWXRBmqQ/bug.avi Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---

List info: http://lists.roundcube.net/dev/

Hi Vladislav,

VB> I'm pretty sure that I'm able to reproduce this on ALL recent roundcube VB> versions (at least from 0.3-beta) WITHOUT thread patch applied.

VB> How to reproduce (I tried to nail it down to the simplest case that VB> shows error): VB> 1) Open folder that contains a bit more messages then could be shown on VB> a single page (f.e. 41 message with 40 rows limit). VB> 2) Select and delete any number of messages, but not one and not all. VB> You may do it with either method (mouse or keyboard). VB> 3) Try to select all messages on a page after remaining messages are VB> loaded to list. Artifact is shown. You are unable to select one of VB> messages (which has duplicate in another row).

VB> Thus, I'd say that bug shown in Eric's video is not related to a VB> threaded-view patch and is a separate long-standing issue.

VB> Hope this will help to fix this.

VB> Should I open a ticket in trac? Or someone can find erroneous code quite VB> quickly?

VB> Eric, would you try to check it again on a clean RC installation without VB> threading patch?

VB> Vladislav.

VB> BTW, deleted message rows are not removed from a DOM model, they only VB> switched to a hidden state. I'm not sure if this is an expected VB> behavior. Can they ever be removed from the inside of JS?

I cannot reproduce it on clean RC In my case comes the bug only with a thread patched RC. I test this today with a diffrent envoirement.

many thanks

Vladislav, A.L.E.C and all Involved !!

List info: http://lists.roundcube.net/dev/

Hi all,

I'm pretty sure that this bug raises due to asynchronous http requests. But maybe not only because of this. What I mean: When dragging messages to another mailbox or deleting them from folder (thus either moving them to trash or deleting), we do following (in a backend part triggered by move_messages() and delete_messages() JS functions):

• (if not an immediate delete) copy messages to another folder
• mark original messages with \Deleted flag
• Expunge them

This is not an atomic operation, and if one polls folder state between second and third operations are run, (s)he will get list with messages marked for deletion too. And, original messages will be shown in a source folder if this happen between first and second operations. IMAP logs show following: == First login, select, etc. Let's call this session SESS_1 (SESS_1) C: cpy1 UID COPY 846,848,853,852,847,851,849,838,839,860,858,859,857,856,855,854,864,840,843,845,844,842,841,863,865,867,861,86 2,866,872,873,874,869,870,871,868,850,875,879,876,877,878,880,890,891,892,893,894,895,896,901,900,898,899,897,889,888,886,887,885,884,883,882,881,902 "Tests/ a" == Here is an another login, select, etc. (SESS_2) (SESS_2) C: thrd1 THREAD REFERENCES UTF-8 ALL (SESS_1) S: cpy1 OK [COPYUID 1252415407 838:902 1074:1138] Completed (SESS_1) C: flg UID STORE 846,848,853,852,847,851,849,838,839,860,858,859,857,856,855,854,864,840,843,845,844,842,841,863,865,867,861,86 2,866,872,873,874,869,870,871,868,850,875,879,876,877,878,880,890,891,892,893,894,895,896,901,900,898,899,897,889,888,886,887,885,884,883,882,881,902 +FLAGS (\Deleted) (SESS_1) S: * 1 FETCH (FLAGS (\Answered \Deleted \Seen $MDNSent) UID 838) ... (SESS_1) S: * 24 FETCH (FLAGS (\Deleted \Seen NonJunk) UID 861) (SESS_2) S: * THREAD (66)(70)(69)(68)(67)(65)(44)(45)(46)(47)(48)(50)(49)(51)(52)(60)(61 62)(63)(64)(43 53 (54 55 56 57 58)(59))(38 (42 39 40)(41))(13)(31)(32 33 34)(35 36 37)((24 (25)(29))(30))(3 (6 (8 7 5)(4))(26)(28))(27)(17)(18)(19)((20)(22))((21)(23))(1 2)((12)(14))((10)(15)(16)(11))(9) (SESS_2) S: thrd1 OK Completed (70 msgs in 0.000 secs) (SESS_2) C: FH12 FETCH 9,11,16,15,10,14,12,1,2,23,21,22,20,19,18,17,27,3,6,8,7,5,4,26,28,30,24,25,29,35,36,37,32,33,34,31,13,38,42,39,40 ,41,43,53,54,55,56,57,58,59,64,63,61,62,60,52,51,49,50,48,47,46,45,44,65,67 (UID RFC822.SIZE FLAGS INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-PRIORITY)]) (SESS_1) S: * 25 FETCH (FLAGS (\Deleted \Seen NonJunk) UID 862) ... (SESS_1) S: * 65 FETCH (FLAGS (\Deleted \Seen) UID 902) (SESS_1) S: flg OK Completed (SESS_1) C: exp1 UID EXPUNGE 846,848,853,852,847,851,849,838,839,860,858,859,857,856,855,854,864,840,843,845,844,842,841,863,865,867,861 ,862,866,872,873,874,869,870,871,868,850,875,879,876,877,878,880,890,891,892,893,894,895,896,901,900,898,899,897,889,888,886,887,885,884,883,882,881,902 (SESS_2) S: * 1 FETCH (FLAGS (\Answered \Deleted \Seen $MDNSent) UID 838 INTERNALDATE "13-Jul-2009 18:19:26 +0200" RFC822.SIZE 6526 BODY [HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-P RIORITY)] {436} ... (All requested headers are printed) (SESS_2) ==(All messages are printed) (SESS_1) S: * 1 EXPUNGE ... (SESS_1) S: * 1 EXPUNGE (SESS_1) S: * 5 EXISTS (SESS_1) S: * 0 RECENT (SESS_1) S: exp1 OK Completed

Bug do not appear when moving/deleting a small amount of messages, probably because of high speed of all operations in that case.

Do anybody knows, how to avoid such asynchronous behavior when doing non-atomic IMAP operations?

Best, Vladislav _______________________________________________ List info: http://lists.roundcube.net/dev/

A.L.E.C wrote:

Vladislav Bogdanov wrote:

...

• (if not an immediate delete) copy messages to another folder
• mark original messages with \Deleted flag
• Expunge them

This is not an atomic operation, and if one polls folder state between second and third operations are run, (s)he will get list with messages marked for deletion too. And, original messages will be shown in a source folder if this happen between first and second operations. IMAP logs show following:

[cut]

...

Do anybody knows, how to avoid such asynchronous behavior when doing non-atomic IMAP operations?

We should just disable 'list' action on folder from which messages are deleted/moved until we receive a response from 'move_del' action. We should also add an operation progress indicator.

So simple solution, cool...

Can I hope that you or someone else with enough code knowledge will supply a quick patch for that, so I can concentrate on a next revision of threaded-view-mode patch, (upcoming and almost ready, but depends on a threaded-view because touches same code fragments) spam-column patch and promised enhancements to JohnDoe's sauserprefs plugin?

Cheers, Vladislav _______________________________________________ List info: http://lists.roundcube.net/dev/