[Kde-pim] [REGRESSION] Pop3 message status change is broken on Enterprise branch

Volker Krause vkrause at kde.org
Fri Feb 1 11:25:34 GMT 2008


On Sunday 27 January 2008 13:01:29 Ingo Klöcker wrote:
> On Sunday 27 January 2008, Ingo Klöcker wrote:
> > On Sunday 27 January 2008, Ismail Dönmez wrote:
> > > Hi Volker,
> > >
> > > Thursday 20 December 2007 12:51:49 tarihinde Volker Krause şunları
> >
> > yazmıştı:
> > > > Since apparently only the triggering of the status change
> > > > operation is broken and not the actual status changing itself,
> > > > the only thing I could think of are the XMLGUI .rc files,
> > > > although that would usually hide the action altogether. Also,
> > > > there is nothing special for local folders in that area. Do you
> > > > still have the old files for comparison?
> > >
> > > Sorry for the late reply, attached is the problematic kmailrc file.
> > > Issue is still reproducable with Enterprise branch according to
> > > users.
> >
> > FWIW, with the very latest enterprise version I have noticed a
> > similar problem. It occurs intermittently with messages in IMAP
> > folders. Most of the time it's just the last message in a thread that
> > cannot be marked as unread. When I mark the whole thread as unread
> > then the status of the problematic message is also marked as unread.
> > I'll keep an eye on it to make out a pattern.

I've seen this as well by now, on IMAP, mostly when marking messages as unread 
that just have been downloaded and marked as read. But I've been unable to 
reproduce it reliably so far.

> I have made a quick test trying to mark all messages in a thread as
> important. You can see the result of the test in the attached
> screenshot.
>
> The only pattern I can make out (also in a few other threads where I
> have tested it) is that if a message is affected by the problem then
> all of its children are affected as well. The level of a message in the
> thread does not seem to be the looked for pattern as one of the
> messages on level 2 could be marked as important. OTOH, I have noticed
> that the problem is more likely to occur with message on level 2 and
> beyond.
>
> > Now that I think about it I have a theory:
> > Maybe for some reason KMail sometimes changes the status in the
> > KMMessage object, but not in the corresponding KMMsgInfo object (or
> > vice-versa?). So this bug might have been introduced by my change
> > which prevents crashes due to the former KMMsgInfo object by
> > KMMessage object replacement. Now the KMMsgInfo object is no longer
> > destroyed, but kept around and re-used when the KMMessage object is
> > destroyed. I have warned about possible inconsistencies due to
> > changes in the KMMessage object not being applied to the KMMsgInfo
> > object. Anyway, it's just a guess. Maybe there's still another
> > problem.
>
> The above observation makes my theory very unlikely.

My guess is that's caused by some of our changes to 
KMFolderImap::flagsToStatus(), but I haven't investigated that yet.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080201/8cf1eacd/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list