Search folder is broken in disk summary.  Which exact version are you using ? 
Disk summary was merged in 2.23.5.

Will be done for 2.23.90.

Yes, it's broken (although I feel is way faster.. but it's broken).

I'm running trunk. Please tell me once it's fixed so I can confirm it is.

(In reply to comment #3)
> Yes, it's broken (although I feel is way faster.. but it's broken).
>

Ah, you are the first to say me its fast. It will be even more faster pretty soon.
Though there are some hidden bottlenecks, which Im fixing.

> I'm running trunk. Please tell me once it's fixed so I can confirm it is.
> 
Sure.

This won't be fixed in 2.24.0 :( 

*** Bug 554332 has been marked as a duplicate of this bug. ***

Any idea if this will be fixed any time soon?  It effectively makes Unread vFolders completely useless, and seems to have been known about for a while (nearly two months).

Has it at least been confirmed?

John, I'm fixing lot of bugs. This is surely on my list, but not on top of it. I would fix it asap.

This is quite a severe issue to me, as I don't double click on a message to read it on another window.  This is what happens to me:

1. the first message on the (search) folder gets selected when I open the folder
2. 1 second later it's marked as read
3. the folder refreshes itself and excludes that message because it's not unread
4. the second message moves up and is then selected
5. go to 2

In a few seconds all messages have disappeared from the search folder and are now marked as read -- what makes it rather difficult to find them.

Srinivasa, do you have any idea when the search-folder-refreshes-upon-message-change was introduced?  I'm willing to build my own version of evo without that so that I can keep reading my search folders.

Cheers

*** Bug 555080 has been marked as a duplicate of this bug. ***

*** Bug 555342 has been marked as a duplicate of this bug. ***

This is a side effect of the new disk-summary version of Evolution. I'm still working to fix it. I have a fix which makes it work the best, but due to a e-table bug, the UI isn't refreshing and Im fixing it. If you are keen to use, I can give my test fix, but the UI will refresh only if you move the selecton. I should be done today or so.

Fixed in stable/trunk.

Infact it is a hacked out patch, made custom to work for vfolder, which condition is message is unread. No other better way I could make it work. It now works reliably and the counts are meaningful for that folder.

(In reply to comment #13)
> Fixed in stable/trunk.

So should this have made it into 2.24.1?  Cause if it was supposed to be there, it never made it.  I am still seeing this behavior and it's very annoying.  vFolders increased my mail productivity considerably over having to constantly "poll" many mailboxes.

I want to know why such an immature and broken feature was allowed to land and be released in a stable (i.e. 2.24.0) release?  It was obviously broken and known broken prior to 2.24.0's release so why was it not backed out?  How did it ever get landed to the stable branch in the first place?

This and the many other regressions (bug 554175, bug 554182 just as two examples) means that 2.24.0 was not ready when it was released.  Why?

Now we have to wait until 2.26 to see all of these quite serious problems fixed or will there be a 2.24.2 *very* soon?

I am still experiencing this bug on 2.24.1 too. 

Srini: Is this included in 2.24.1 or not?

I have 2.24.1 on Ubuntu Intrepid, -71 unread messages, -47 total, and it still removes the messages from the folder, once the status changes, regardless of any rule combination, right now, single rugle with status not read for all active folders.

this is still an issue with 2.24.1 we have a quite few confirmations here: https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/275952

I had posted a fix for this in 2.24.1, but it seems to be still breaking :(. Im reworking to find the exact scenario it is breaking.

I am running 2.24.1.1 on Ubuntu Intrepid Ibex on amd64. I have experienced this bug as well. I move all incoming messages from various mailing lists to different folders then read them (and delete them) from an "Unread" folder. Since the messages disappeared as I read them, it was a bit of a pain. I changed the folder criteria to say "Find Items: If all criteria are met" and the messages no longer disappear. The count of unread items is still wrong though :(

*** Bug 561170 has been marked as a duplicate of this bug. ***

*** Bug 561160 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
> I am running 2.24.1.1 on Ubuntu Intrepid Ibex on amd64. I have experienced this
> bug as well. I move all incoming messages from various mailing lists to
> different folders then read them (and delete them) from an "Unread" folder.
> Since the messages disappeared as I read them, it was a bit of a pain. I
> changed the folder criteria to say "Find Items: If all criteria are met" and
> the messages no longer disappear. The count of unread items is still wrong
> though :(
> 

I have fixed your case on stable/trunk. I hope with that unread vfolder should be bettter. Im still working on counts.

Created attachment 123010 [details] [review]
Committed patch.

This didn't make it to 2.24.2? At least the fresh 2.24.2 build for Fedora 10 still exhibits the same problem.

Still an issue for me as well with the patch, most of the times reproducible with threads but also with messages not in one, what i do for reproduce it is: on the search folder order by "Group by threads", find a thread with all the messages as unreaded, start reading them from first to last then double click again on the last one, the mail window is empty. 

Same here. I upgraded to Fedora 10 and since then I have the same problem.

When is the anticipated resolution date?

I had asked my QA to test. Is that double click only the issue or the mail loosing from the message list? I was always worried of aggressive mail regen and overlooked that.

Can one confirm that with 2.24.2, onwards that aggressive regen of message list is gone? I think I will work around the issue of empty mail

What do you mean by "aggressive regen"? In Fedora 10's 2.24.2 build, I can't even define what I used as the "Unread mails" vFolder any more, because it's impossible to select the INBOX folder of an IMAP account as a source for a vFolder (it chooses an 'mbox:INBOX' instead, which doesn't find anything). This is a new regression between 2.24.1 and 2.24.2, I believe.

This is how the bug manifests itself to me. (It's been this way since I first installed 2.24 and the problem still exists on 2.24.2)

I have a search folder which shows only messages containing a given string on the subject and which are unread. When I select that folder, the following happens:

1. the first message on the (search) folder gets selected
2. 1 second later it's marked as read
3. the folder refreshes itself and excludes that message because it's not
unread
4. the second message moves up and is then selected
5. go to 2

In a few seconds all messages have disappeared from the search folder and are
now marked as read -- what makes it rather difficult to find them.

(In reply to comment #30)
> This is how the bug manifests itself to me. (It's been this way since I first
> installed 2.24 and the problem still exists on 2.24.2)
> 
> I have a search folder which shows only messages containing a given string on
> the subject and which are unread. When I select that folder, the following
> happens:
> 
> 1. the first message on the (search) folder gets selected
> 2. 1 second later it's marked as read
> 3. the folder refreshes itself and excludes that message because it's not
> unread
> 4. the second message moves up and is then selected
> 5. go to 2
> 
> In a few seconds all messages have disappeared from the search folder and are
> now marked as read -- what makes it rather difficult to find them.

This description is the same problem I filed in bug 562449.

(In reply to comment #29)
> What do you mean by "aggressive regen"? In Fedora 10's 2.24.2 build, I can't
> even define what I used as the "Unread mails" vFolder any more, because it's
> impossible to select the INBOX folder of an IMAP account as a source for a
> vFolder (it chooses an 'mbox:INBOX' instead, which doesn't find anything). This
> is a new regression between 2.24.1 and 2.24.2, I believe.

This is the same problem I describe in bug 554175 (which seems to be getting ignored along with a number of my other bugs).  Note in particular bug 554175 comment #4 and see if that helps you any.

Seriously... No offense, but 2.24 is/was a real lemon.

Created attachment 123943 [details] [review]
Proposed patch

This should take care of mails missing when you double click on the folder.

> I have a search folder which shows only messages containing a given string on
> the subject and which are unread. When I select that folder, the following
> happens:
> 

The unread vfolder is a hack now in Evolution. By aggressive I mean this, once a mail become unread, it goes off. I had hacked it in a way to avoid this for a few queries, like 'status is not' read, threaded/not threaded etc. But your query is a bit different, in the sense that you look for a subject and status not read.

So, you just got to do this on a terminal.

export CAMEL_DEBUG=vfolderexp

Start evolution in the same terminal. Go to the unread vfolder and mark a message as read. Immediately quit Evolution. On the console, you muse see something like

Expression for vfolder '%s' is 'foo'

Select what ever is within that quotes (foo) and do

export CAMEL_VFOLDER_UNREAD_EXP='foo'

Start evolution. You should be able to get that working. Lemme know how it goes. I'm sorry for this, but I'm trying hard to get this hack through some gconf/plugin. But Im loosing time. I would do that the earliest. Thanks for your patience guys.

> So, you just got to do this on a terminal.
> 
> export CAMEL_DEBUG=vfolderexp
> 
> Start evolution in the same terminal. Go to the unread vfolder and mark a
> message as read. Immediately quit Evolution. On the console, you muse see
> something like
> 
> Expression for vfolder '%s' is 'foo'

I did this and got the expression for my vfolder.

> 
> Select what ever is within that quotes (foo) and do
> 
> export CAMEL_VFOLDER_UNREAD_EXP='foo'
> 

Then I did the above; it looked like this:

export CAMEL_VFOLDER_UNREAD_EXP=' (match-threads \"replies\"  (and\n  \n\t(match-all (header-contains \"Subject\"  \"[NEW]\"))\n     \n  \n     (match-all (not (system-flag  \"Seen\")))\n    \n  )\n)\n'


> Start evolution. You should be able to get that working. Lemme know how it
> goes. I'm sorry for this, but I'm trying hard to get this hack through some
> gconf/plugin. But Im loosing time. I would do that the earliest. Thanks for
> your patience guys.
> 

I also tried removing the leading white space in the variable above, but it
didn't work in either case.

(This should've gone in the previous comment, but I hit 'Save' accidentally.)

(In reply to comment #36)
> I also tried removing the leading white space in the variable above, but it
> didn't work in either case.
> 
> (This should've gone in the previous comment, but I hit 'Save' accidentally.)
> 

Do you have a source build? if so if you are on irc, can we meet for 5 min? I just need a person, with a source build and who has the issue on irc.

(In reply to comment #34)
> 
> The unread vfolder is a hack now in Evolution.

This is a very sad statement.  The unread vfolder is a (what this bug should demonstrate to you) a common paradigm which should have been accounted for in the design of whatever new feature has caused such a serious regression.  I can't believe in fact that this was overlooked.

The old behavior was perfect and I think what most people would expect to happen for "the unread vfolder".  What happens now, while it might be "technically correct" according to the current design certainly does not embody the principle of least surprise.

> By aggressive I mean this, once
> a mail become unread, it goes off. I had hacked it in a way to avoid this for a
> few queries, like 'status is not' read, threaded/not threaded etc. But your
> query is a bit different, in the sense that you look for a subject and status
> not read.

It is completely unscalable, and IMHO, completely unreasonable to try to cover every single query that somebody might come up with with "exception cases".  You need to cover the general case of messages that "become" read in a vfolder that selects only unread messages.  More on this later...

> export CAMEL_VFOLDER_UNREAD_EXP='foo'

This is completely unacceptable.  Users should not have to put every possible "unread vfolder" expression into an environment variable (or gconf key or whatever) to retain a previous behavior.
 
> But Im loosing time.

So then, back out whatever change has made this mess and redesign it to properly account for this very common work paradigm.

Let me ask this... What other problem was solved by whatever redesign has caused this problem?  Was it as serious as the problem that it has caused?  You can recognize of course that if by solving problem A, you create a bigger problem, B, then the solution to problem A is invalid, yes?

Here's an alternate "general" solution to the problem...

Maybe you need to introduce some new, additional, or "intermediate" state for messages.  It seems clear that given the current design, the simple black-and-white states of read/unread are not quite enough.  Maybe some new (invisible) state, like "current" (or whatever name you want to call it) which represents a message that was unread, and became read since the last expunge.  Such a state would be treated as "unread" for the purposes of vfolder selection.

So it would go something like this:

User Action             Message State(s)
-----------             ----------------
Open evolution          Unread
Mark message read[1]    Read|Current
Expunge                 Read

[1] either explicitly through the menu, or CTRL-K or implicitly through the "mark read after <n> seconds" feature

For a given vfolder, a message selection criteria of "Status is not Read" would match messages that are flagged as Unread (or !Read, however that may be internally) or equally, messages that are flagged as "Read|Current".

Given this proposal, every message that moves from the unread to read state also gets the "current" state and expunge has a new job to clear the "current" state on any message that has it.

Probably with some poking around, even I could code that up, but for somebody with evolution internals knowledge, coding that up should be trivial.

Thots?

(In reply to comment #38)
> (In reply to comment #34)
> > 
> > The unread vfolder is a hack now in Evolution.
> 
> This is a very sad statement.  The unread vfolder is a (what this bug should
> demonstrate to you) a common paradigm which should have been accounted for in
> the design of whatever new feature has caused such a serious regression.  I
> can't believe in fact that this was overlooked.
> 
> The old behavior was perfect and I think what most people would expect to
> happen for "the unread vfolder".  What happens now, while it might be
> "technically correct" according to the current design certainly does not embody
> the principle of least surprise.
> 
> > By aggressive I mean this, once
> > a mail become unread, it goes off. I had hacked it in a way to avoid this for a
> > few queries, like 'status is not' read, threaded/not threaded etc. But your
> > query is a bit different, in the sense that you look for a subject and status
> > not read.
> 
> It is completely unscalable, and IMHO, completely unreasonable to try to cover
> every single query that somebody might come up with with "exception cases". 
> You need to cover the general case of messages that "become" read in a vfolder
> that selects only unread messages.  More on this later...
> 
> > export CAMEL_VFOLDER_UNREAD_EXP='foo'
> 
> This is completely unacceptable.  Users should not have to put every possible
> "unread vfolder" expression into an environment variable (or gconf key or
> whatever) to retain a previous behavior.

I don't expect a lot of vfolder to be this. Unread is the only case that gets suffered. Rest of the things should be all fine.

> 
> > But Im loosing time.
> 
> So then, back out whatever change has made this mess and redesign it to
> properly account for this very common work paradigm.
> 
> Let me ask this... What other problem was solved by whatever redesign has
> caused this problem?  Was it as serious as the problem that it has caused?  You
> can recognize of course that if by solving problem A, you create a bigger
> problem, B, then the solution to problem A is invalid, yes?
> 

Understand, there could be bugs, that gets introduce like this, but I'm saying I would fix it.  When you design, you can't detail it to all cases, and its possible somethings get missed out. I would say that Unmatched folder was accounted for, which I had temporarily disabled. Unread vfolder and vfolder-of-vfolder are the two things that really dropped. I know unread vfolder is a issue and thatz why you see work happening around this. 

> Here's an alternate "general" solution to the problem...
> 
> Maybe you need to introduce some new, additional, or "intermediate" state for
> messages.  It seems clear that given the current design, the simple
> black-and-white states of read/unread are not quite enough.  Maybe some new
> (invisible) state, like "current" (or whatever name you want to call it) which
> represents a message that was unread, and became read since the last expunge. 
> Such a state would be treated as "unread" for the purposes of vfolder
> selection.
> 
> So it would go something like this:
> 
> User Action             Message State(s)
> -----------             ----------------
> Open evolution          Unread
> Mark message read[1]    Read|Current
> Expunge                 Read
> 
> [1] either explicitly through the menu, or CTRL-K or implicitly through the
> "mark read after <n> seconds" feature
> 
> For a given vfolder, a message selection criteria of "Status is not Read" would
> match messages that are flagged as Unread (or !Read, however that may be
> internally) or equally, messages that are flagged as "Read|Current".
> 
> Given this proposal, every message that moves from the unread to read state
> also gets the "current" state and expunge has a new job to clear the "current"
> state on any message that has it.
> 
> Probably with some poking around, even I could code that up, but for somebody
> with evolution internals knowledge, coding that up should be trivial.
> 

I don't think this is possible/as-simple-as it looks. Live update of folder could be a problem. ABI breaks etc. But something similar should be done. I would say, I need to take some time to come out with a fresh design change for this. Not a major one, but atleast something that fits to all.

But you know, it might take some time, and what ever I'm proposing is for right away/right now till, I come out with my soln. I don't think I can do any better.

Srinivasa, I'm very glad of your responses here, I'm very grateful that you've chosen to engage with the community so actively. As I see it, Evolution is free software, and so I'm grateful for improvements and bug fixes as they happen. Muchas gracias.

Created attachment 123978 [details] [review]
Proposed patch

This patch should fix the issue, by making the hack working. Many Thanks a lot to  Guilherme Salgado for his time in testing incremental patches.

Created attachment 123979 [details] [review]
Evolution portion of patch.

So, this patch makes hack bit more easier if the vfolder has more queries beyond just unread status. Like what Guilherme Salgado had, which also checks for subect [new] or so. 

No need for any environment variable/gconf. Right click the vfolder and enable 'Unread Search Folder', it should make it work normal. It automatically stores this values and reloads and so no hurdles of environment/expression etc. Sorry for all the inconvenience. 

But this Evolution patch adds a new string, so I need to get quite a few approvals before I commit it, but please test it for me and lemme know how it goes. Thanks a lot for your patience. -Srini.

Created attachment 124003 [details] [review]
Correct Evolution patch

Sorry attached the  wrong patch for evo

It works fine for me with the latest patches.  And there's no need for environment variables or anything -- just need to flag the specific folder as an 'Unread folder' in evo.

I have posted release-team on breaking string on stable. Once I get the approval I would commit all. I'm planning for a 2.24.2.1 release may be in a week or so with so many other patches. Thanks a lot guys for your support and patience.

To get some more background: why does the user have to click on a menu item for that? Isn't it possible to automatically set this property when creating the search folder?

It sounds to me like adding this -- and therefore the new string -- is only some quick workaround. It might be okay to do that for 2.24 if a real fix is intrusive, but I'd prefer to avoid doing this in the long term.

(In reply to comment #46)
> To get some more background: why does the user have to click on a menu item for
> that? Isn't it possible to automatically set this property when creating the
> search folder?
> 
> It sounds to me like adding this -- and therefore the new string -- is only
> some quick workaround. It might be okay to do that for 2.24 if a real fix is
> intrusive, but I'd prefer to avoid doing this in the long term.
> 

Vuntz, so this should be done for unread vfolder, for which a typical query is 'message not read', for which I had hacked internally in to the system. But user do have custom queries like 'subjuect has foo' and message not read, or message from 'baa' and message not read. For such vareities its not possible to work it. I want this to go as a quick fix for users suffering in 2.24.x. May be in 2.26, I might rework around this to make it all fine.

I don't know the internals of all this, so I'm obviously very naive :-) But it really sounds like it should be possible to know if a custom query has a "message not read" part.

Anyway, I guess I'd be okay to have this in if you guys make sure a real fix is done for 2.26 -- I just don't think a popup menu will work fine for people. This will just mean "it doesn't work by default???" for them.

Thanks for your reply. Hopefully, you'll hear from the i18n team about the new string.

All the patches committed to trunk.  All patch except the Evolution hack committed to stable. Once I get the approval from r-t, I would commit this also to trunk.

All the patches committed to trunk.  All patch except the Evolution hack committed to stable. Once I get the approval from r-t, I would commit this also to stable

I agree with Vincent...

(In reply to comment #48)
> But it
> really sounds like it should be possible to know if a custom query has a
> "message not read" part.

Indeed.  What is so difficult about examining the query of a vfolder, looking for any "message not read" component and setting this hack/flag automatically?

> Anyway, I guess I'd be okay to have this in if you guys make sure a real fix is
> done for 2.26

I'm less forgiving I think.  This is not the only regression that was caused by this vfolder rework.  I think if all of the regressions (uhm, like, vfolders of vfolders just to mention one) cannot be worked out by the time 2.26 is released, the whole rework needs to be pulled and replaced with what was working in 2.22 until it is all fixed properly and provides no regressions from 2.22.

I still to this day don't understand why this reworking of vfolders was necessary -- especially given all of the trouble it has caused.

> -- I just don't think a popup menu will work fine for people.
> This will just mean "it doesn't work by default???" for them.

Exactly.  There are a number of things that don't "just work" that used to and people used.  Foisting regressions in functionality on people is just plain bad.

I am actually holding back on upgrading the people I support to the newest version of Ubuntu because of this lemon release of evolution.  That's how bad a state this release is in, IMHO.

(In reply to comment #51)
> I agree with Vincent...
> 
> (In reply to comment #48)
> > But it
> > really sounds like it should be possible to know if a custom query has a
> > "message not read" part.
> 
> Indeed.  What is so difficult about examining the query of a vfolder, looking
> for any "message not read" component and setting this hack/flag automatically?

It is possible, but not so easy or simple  and its not worth, it since, I'm gonna fix it better anyway.

> 
> > Anyway, I guess I'd be okay to have this in if you guys make sure a real fix is
> > done for 2.26
> 
> I'm less forgiving I think.  This is not the only regression that was caused by
> this vfolder rework.  I think if all of the regressions (uhm, like, vfolders of
> vfolders just to mention one) cannot be worked out by the time 2.26 is
> released, the whole rework needs to be pulled and replaced with what was
> working in 2.22 until it is all fixed properly and provides no regressions from
> 2.22.

I hate to answer multiple times to a same question. These are bugs that we would fix.

> 
> I still to this day don't understand why this reworking of vfolders was
> necessary -- especially given all of the trouble it has caused.
> 
> > -- I just don't think a popup menu will work fine for people.
> > This will just mean "it doesn't work by default???" for them.
> 
> Exactly.  There are a number of things that don't "just work" that used to and
> people used.  Foisting regressions in functionality on people is just plain
> bad.
> 
> I am actually holding back on upgrading the people I support to the newest
> version of Ubuntu because of this lemon release of evolution.  That's how bad a
> state this release is in, IMHO.

 

Committed this to stable also. Should be in 2.24.3

This is _still_ not fixed.

I have selected the "Unread Search Folder" checkbox on a folder.

Then I go select a message from the summary folder and then press CTRL-U (to see the message source).  The source displays briefly (less than a second) in a window and then the window goes blank.  The status of the message in the summary is then changed to "read".

How many hacks on top of hacks are you going to do to this "new feature" before it's considered so badly designed that it should be removed?  Does it really fix enough other bugs to make all of the UI regressions that it's causing justifiable?

Additionally, messages marked for deletion (IMAP) also disappear from the summary window less than a second after they are marked for deletion.  This is still another regression from previous (to 2.24) behavior.

I'll have to agree with comment #54, it's still very buggy.

If you have an unread search folder and have read some messages, then make a change to another message, such as marking it as junk, the list gets refreshed and the read messages disappear.  Pre-2.24, the only way to remove a read message from an unread search folder was by deselecting the folder and the returning to it, which seems to me the most intuitive way to do it.

           John

Another anomaly (with 2.24.3):

I was reading a message by selecting it in the message summary pane and reading in the preview pane.  Then all of a sudden the location of the highlighted line in summary pane line jumped to the top (I sort by received time, ascending) and the columns (From, Subject, Received, Date) of that message in the summary where either blank or "?".  A few seconds later, it jumped back down to the bottom of the summary display (where it should be) and the columns were again filled in.

I believe while this was happening, evolution was trying to fetch and filter new messages.

I have most certainly seen this more than once this morning after "upgrading" (for some value of upgrade) to 2.24.3.

(In reply to comment #55)
> I'll have to agree with comment #54, it's still very buggy.

Indeed.  I'm finding still more and more bugs with it.
 
> Pre-2.24, the only way to remove a read
> message from an unread search folder was by deselecting the folder and the
> returning to it, which seems to me the most intuitive way to do it.

Or expunging it, which I found intuitive.  I could mark a message deleted, or read and it would continue to be in the summary until I expunged.  In that sense, expunge almost seemed like "commit", which I found very intuitive.

Hrm.  2.24.3 seems to be adding additional regressions over 2.24.2.  Now there are unread messages in the "real" IMAP folder that are not showing up in my "unread" vfolder.

Additionally, amongst the thread that has missing unread messages in the vfolder (as compared to the real IMAP folder) view, while the messages show to be threaded in the real IMAP folder view, they are not showing as threaded (i.e. using the little downward pointing arrow) in the vfolder view.

I'm hitting even more regressions in the release.. now whenever some action causes an unread vfolder to refresh (I've encountered it when deleting messages, replying to messages, or marking messages as spam) evolution segfaults.

(In reply to comment #2)
> Will be done for 2.23.90.
> 

I'm out of here. I reported this bug with plenty of time to revert the changes or fix the problem. I respect a lot the work that the Evo team has done on the disk summary, but there was no need to merge it for 2.24, it could have waited another cycle if it was causing regressions.

[I wanted to remove myself from the CC list, but now is when I discover that you can't do that for bugs you have reported. Sigh]

(In reply to comment #60)
> [I wanted to remove myself from the CC list, but now is when I discover that
> you can't do that for bugs you have reported. Sigh]

Yes. You're doomed. See https://bugzilla.mozilla.org/show_bug.cgi?id=215588 :-P

(In reply to comment #60)
> I'm out of here.

I may not have been early (in fact, admittedly late, filed #561170), but this problem was frustrating enough that I switched to Thunderbird a month ago. Can't say I like it much, I find it laggy and not integrated well to my GNOME desktop, but at least it's predictable. Still wish I could come back to Evolution, but by the looks of things, that's won't be anytime soon.

Yes, I know we're not supposed to use Bugzilla for this sort of stuff, and I'm really sad I had to abandon a program I've enjoyed for years, but developers deserve to know about this sort of experience, too.

> I'm out of here. I reported this bug with plenty of time to revert the changes
> or fix the problem. I respect a lot the work that the Evo team has done on the
> disk summary, but there was no need to merge it for 2.24, it could have waited
> another cycle if it was causing regressions.

We did apply lot of work on this. Even in 2.23.90 we made some patches. In 2.24.3 as we made some patches for this. Claudio, we merged in 2.23.5 and since then we found lot of issue and fixing it every release. Just to note that 2.25.x series adds no new features apart from stability/performance fixes. We are committed to get it back to a state of *no regression*, including bringing back some of the disabled-features like unmatched vfolder etc. Thanks.

There is probably no doubt amongst us here that are complaining that work is being done to stabilize this mess but I think the bigger question is why did such an unstable mess get out into the wild where it's have such a bad effect?

Seriously.  Somebody even commented here that he posted bug(s) prior to the 2.24.0 release, and surely we (the great unwashed) are no more power users of evolution than you developers must be.  Surely you must have all seen the great big warts before 2.24.0 went out.

This whole situation really shakes my confidence in the future of evolution as a stable application.  I have to wonder how many future releases are going to be so unstable because enough QA is not being done before a feature is allowed to merge to the upcoming stable release branch?

Really, there is no shame in a feature missing a release train if it's really not ready for widespread release.  Release trains always come by.  Wait for the next one so that people will value the feature, not hate it.

Created attachment 126962 [details] [review]
Patch to fix the souce view disappearing

This is no hack. This should be failing in 2.22.x also. Go to a normal folder, choose show: message unread messages and click a message and view source. It would have failed there as well. Anyways, this patch fixes it.

(In reply to comment #56)
> Another anomaly (with 2.24.3):
> 
> I was reading a message by selecting it in the message summary pane and reading
> in the preview pane.  Then all of a sudden the location of the highlighted line
> in summary pane line jumped to the top (I sort by received time, ascending) and
> the columns (From, Subject, Received, Date) of that message in the summary
> where either blank or "?".  A few seconds later, it jumped back down to the
> bottom of the summary display (where it should be) and the columns were again
> filled in.
> 
> I believe while this was happening, evolution was trying to fetch and filter
> new messages.
> 
> I have most certainly seen this more than once this morning after "upgrading"
> (for some value of upgrade) to 2.24.3.
> 


This is bug #567654 and got fixed few minutes ago.

Committed to stable/trunk.

Just wanted to pitch in; I'm the reporter of the quite verbose bug #562912 which is related to this issue.

Currently running 2.24.3 on Ubuntu Intrepid, and the bug still manifests itself. Marking the folder as an "Unread vfolder" makes things worse. Before doing that, at least evolution had the courtesy to wait for an event that triggered an update of the view before removing a read message from the list. But since tagging the vfolder as an Unread vfolder, marking it as read via the right-click menu removes it from the list immediately and puts the list focus at bottom +1. That is: it switches focus to an imaginary message right under the last message in the list. Which it can't display of course, since the message is not really there. If I mark it as read by clicking the envelope it remains in the folder, but still disappears when the list view updates because I drag a mail to another folder for example.

To make things worse, I can't undo this change via the GUI; if I right-click the folder again and click on the now checked "Unread vfolder" option in order to uncheck it, it remains checked. Weird behaviour for a checkbox that's not greyed out.

This bug is really trying my patience:
* The functionality is broken.
* We've been experiencing this bug for months, and still no resolution.
* The bug was known before the merge of the breaking code into trunk, yet somehow someone thought it would be a great idea to merge anyway. Who the hell is your release manager?
* Several requests have been launched in this thread asking clarification of which issues have been solved or which new functionality was made possible that would justify this major regression. The only answer so far was "I hate to answer the same question multiple times". This answer has indeed not been repeated since, so there is at least truth in that statement.
* And lastly, the only "fix" right now (assuming it actually works for the rest of the users and I'm just the lucky schmuck that has hit the weird corner-case) leaves people who're not involved in the opensource community in the cold. They're expected to manually mark the "Unread" vfolder as an "Unread vfolder". It doesn't happen automatically. It doesn't even happen automatically on the default predefined "Unread" vfolder that's there at install time and which they might have had around for years. To top it off, there are only two ways in which they can figure this out: either they accidentally stumble upon that feature in the application, decide to try it out, and have fixed their issue probably without ever finding out how they did it, or they browse/search for information on the bug, accidentally stumble upon this thread, and figure it out that way. Either way, the fix relies upon accidental disovery of the solution for people who don't have time to spend hours searching for this kind of information.

I understand this is Free and Open Source Software, and hence written by people of all walks of life. But that's no excuse for the utter lack of professionalism displayed here. No real solution is offered, the turd is not reverted, but instead we get a couple of fixes which fix nothing at all and grumpy attitude from the poor dev who has to fix this mess (guess the bug has been trying your patience as well, eh?).

In short: It is broken. Your various attempts to unbreak it with ugly hacks have failed. A professional would either revert to the old codebase, or explain why this is impossible.

Some more fixes were in 2.24.4 and yesterday we released 2.24.5. Please update and lemme know. Atleast, w/2.24.4 unread vfolder was mostly usable for me. 

What about 2.26.2 ? I'm having the same issue with 2.26.2, plus with some sqlite issues (will be reported seperately).

It appears this issue is still around after many versions.  I'm on 2.28.1 in Ubuntu 9.10, and I see it exclusively on a vFolder with status=unread and at least one other condition.  If there is exactly one status=unread condition, it appears to work correctly.

What's the status of this issue?

(In reply to comment #71)
> I see it exclusively on a vFolder with status=unread and at
> least one other condition.  If there is exactly one status=unread condition, it
> appears to work correctly.

This is a good observation. I can reproduce this with actual master (~2.30.0) when I create a search folder which has:
 * all conditions are met
 * Status is not read & Label is Important
 * Specific folder: On This Computer/Inbox

then saving this, going to On This Computer/Inbox and marking few messages unread and few of them with an Important label, then going to the new virtual folder and double click the message I see how one after each other are read by Evolution itself. (They are marked read and then disappear from the message list, thus another is selected, which is also marked read and so on and so on until all the virtual folder is empty.) I have set "Mark messages as read after 1.5 seconds".

This bug is still present in 2.30 (package 2.30.3-1ubuntu7).  My search folder for unread messages used to let me open messages in Ubuntu 10.04, but since the upgrade to Ubuntu 10.10 it became unusable (automatically marking messages as read, disappearing from the search folder, opening the following message, same again until folder becomes empty). 

The search folder was only based on the Read flag. IMAP inbox.

Handling of other labels is also awkward: when processing my ToDo search folder (based on the single condition of the presence of a ToDo label) I would reset the flag on some messages, resulting in the message still appearing in the search folder, but messages show empty when trying to open.  (Arguably, an automatic refresh of this search folder might be convenient, a contrasting need from the unread folder.)

Steven: One issue per one report please...

From two Ubuntu boxes running Evolution 2.28.3.0ubuntu10 I have different behaviors, using two different message sources:

Issue exists on box 1, using the Exchange connector, with *messages with no attachments*.  Box running Linux <hostname> 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC 2010 i686 GNU/Linux per uname -a.

Symptom:  
   Opening a Search folder with Preview on (^M) and defined as "Status is not read" results in all unread messages being displayed, opened one at a time, and immediately being marked "read" (highlight removed) and disappearing from the Search folder.
   The process goes on, with messages removed from the search, until it reaches a message with attachments. That message is then marked "read" (highlight removed) but remains listed in the folder and can be opened.
   Other "read" messages, which started the session as "unread" but were opened in another view, and which would have been removed from the search but for the message with attachments (i.e., are listed below it), remain visible in the Search folder and can be opened from there without disappearing.

----

Issue appears not to exist on Box 2, which uses only IMAP to a Dovecot server. 

Behavior appears to be as intended, i.e. the folder contains messages that had an "unread" status at the beginning of the session, whether they have been read since or not.

Box running Linux <hostname> 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 09:00:03 UTC 2010 i686 GNU/Linux.

This is fixed by a change in bug #562912, thus I'm marking this as a duplicate.

*** This bug has been marked as a duplicate of bug 562912 ***