Hi Devs,
I don't want to be some jerk who questions every commit, but I'm worried that 1920 will exacerbate some RC problems. 1920 removes the ability reload the folder currently being viewed by clicking on the folder's name in the folder list. I think 1920 has a good idea and I would go farther and say the user shouldn't even be able to click things that do nothing.
Unfortunately, being able to click the current folder name that was one of the easiest and most obvious ways for a user to reload their mailbox. (They can still hit the browser's refresh).
Reloading the mailbox you are currently in is a work around (admittedly not a proper fix) for at least two problems.
1.) If you're not using the default sorting, messages inserted by check mail will be at the top of the list regardless of their proper place. (http://trac.roundcube.net/ticket/1484664)
2.) Under some conditions, like having Thunderbird open and reading the same mail account as RC, RC's check mail call will update the inbox count, but fail to add the message to the message list. (I'll open a ticket later if I can narrow it down)
Thanks for your consideration, Ziba
Ziba Scott wrote:
Hi Devs,
I don't want to be some jerk who questions every commit, but I'm worried that 1920 will exacerbate some RC problems. 1920 removes the ability reload the folder currently being viewed by clicking on the folder's name in the folder list. I think 1920 has a good idea and I would go farther and say the user shouldn't even be able to click things that do nothing.
Unfortunately, being able to click the current folder name that was one of the easiest and most obvious ways for a user to reload their mailbox. (They can still hit the browser's refresh).
Reloading the mailbox you are currently in is a work around (admittedly not a proper fix) for at least two problems.
1.) If you're not using the default sorting, messages inserted by check mail will be at the top of the list regardless of their proper place. (http://trac.roundcube.net/ticket/1484664)
2.) Under some conditions, like having Thunderbird open and reading the same mail account as RC, RC's check mail call will update the inbox count, but fail to add the message to the message list. (I'll open a ticket later if I can narrow it down)
I also noticed that unread counter in RC may go out of sync when TB has the mailbox open. It happens all the time, when TB moves the message out of INBOX into some other folder via message filters.
On Thu, Oct 2, 2008 at 22:56, Dennis P. Nikolaenko dennis@nikolaenko.ru wrote:
Ziba Scott wrote:
2.) Under some conditions, like having Thunderbird open and reading the same mail account as RC, RC's check mail call will update the inbox count, but fail to add the message to the message list. (I'll open a ticket later if I can narrow it down)
I also noticed that unread counter in RC may go out of sync when TB has the mailbox open. It happens all the time, when TB moves the message out of INBOX into some other folder via message filters.
The reason is that RoundCube only adds messages to the list that have the "RECENT" flag set. This flag is gone when the first MUA accesses the messages (which probably is Thunderbird in your case). Because we cannot distinguish between unread messages that are already listed on the client and unread messages that are just arrived we have to rely on the RECENT flag. As a workaround RC needs to remember the messages IDS that are currently shown on the user's screen to prevent from double-listing unread messages when updating the list.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On Oct 3, 2008, at 7:03 AM, Thomas Bruederli wrote:
On Thu, Oct 2, 2008 at 22:56, Dennis P. Nikolaenko
dennis@nikolaenko.ru wrote:Ziba Scott wrote:
2.) Under some conditions, like having Thunderbird open and
reading the same mail account as RC, RC's check mail call will update the inbox count, but fail to add the message to the message list. (I'll open a ticket later if I can narrow it down)I also noticed that unread counter in RC may go out of sync when
TB has the mailbox open. It happens all the time, when TB moves the
message out of INBOX into some other folder via message filters.The reason is that RoundCube only adds messages to the list that have the "RECENT" flag set. This flag is gone when the first MUA accesses the messages (which probably is Thunderbird in your case). Because we cannot distinguish between unread messages that are already listed on the client and unread messages that are just arrived we have to rely on the RECENT flag. As a workaround RC needs to remember the messages IDS that are currently shown on the user's screen to prevent from double-listing unread messages when updating the list.
I would +100 this. I had been seeing the behavior, but never new what
the problem was. My home computer is logged on all day with Apple
Mail running. I use RoundCube when at work, and have seen that often
either the list of messages or the unread count is incorrect (and
they don't often match).
I use a SSB for RoundCube (Fluid), and I'm not sure if there's a
reload button (if there is it's hidden). Clicking on INBOX is
currently the best way to refresh the mailbox list.
Scott
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/AV/93Jus85t/smime.p7s Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
Scott Houchin wrote:
On Oct 3, 2008, at 7:03 AM, Thomas Bruederli wrote:
On Thu, Oct 2, 2008 at 22:56, Dennis P. Nikolaenko dennis@nikolaenko.ru wrote:
Ziba Scott wrote:
2.) Under some conditions, like having Thunderbird open and reading the same mail account as RC, RC's check mail call will update the inbox count, but fail to add the message to the message list. (I'll open a ticket later if I can narrow it down)
I also noticed that unread counter in RC may go out of sync when TB has the mailbox open. It happens all the time, when TB moves the message out of INBOX into some other folder via message filters.
The reason is that RoundCube only adds messages to the list that have the "RECENT" flag set. This flag is gone when the first MUA accesses the messages (which probably is Thunderbird in your case). Because we cannot distinguish between unread messages that are already listed on the client and unread messages that are just arrived we have to rely on the RECENT flag. As a workaround RC needs to remember the messages IDS that are currently shown on the user's screen to prevent from double-listing unread messages when updating the list.
I would +100 this. I had been seeing the behavior, but never new what the problem was. My home computer is logged on all day with Apple Mail running. I use RoundCube when at work, and have seen that often either the list of messages or the unread count is incorrect (and they don't often match).
I use a SSB for RoundCube (Fluid), and I'm not sure if there's a reload button (if there is it's hidden). Clicking on INBOX is currently the best way to refresh the mailbox list.
The first real confused user found :) See http://trac.roundcube.net/ticket/1485417
In my experience clicking the check new messages icon doesn't work.
I've tried it, but it still doesn't see any "new" messages and also
generally doesn't then display messages that had been seen by the
other mail client but haven't yet been displayed in RoundCube.
Scott
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/MY/jVbemT//smime.p7s Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
Scott Houchin wrote:
In my experience clicking the check new messages icon doesn't work. I've tried it, but it still doesn't see any "new" messages and also generally doesn't then display messages that had been seen by the other mail client but haven't yet been displayed in RoundCube.
Created ticket: http://trac.roundcube.net/ticket/1485459
-
Dennis P. Nikolaenko -
Scott Houchin -
Thomas Bruederli -
Ziba Scott