Re: New odd behavior - selected message not within dislay and others.



Hi Jack!

Am 19.07.20 00:20 schrieb(en) Jack via balsa-list:
Normally, when I've read all new messages in the current mailbox, and click "Next Unread" Balsa switches to 
the mailbox with the next unread message, selects that message and displays it, and scrolls the message list to show 
the new message line.  The first part does always happen - display the next mailbox with an unread message.  However, 
sometimes, the message selected is an old one (or perhaps the one with the highest message number, which is essentially 
random for maildir mailboxes.  That has happened infrequently, but for a long time.  It now seems more frequent.  What 
is new, however, is that the selected message is NOT scrolled to the center of the display, and may be very far away.

No Heisenbug!  I also observed the latter effect (wrong scrolling), in particular with a somewhat crowded 
Maildir mailbox (Postgresql mailing list), with threading enabled and a high depth of the threads (more than 
10 levels, sometimes).  In this case, typically the sorting in the mailbox is also broken (although Peter 
*mostly* fixed this effect, it still –but rarely!– occurs).  I don't use the “Next Unread” function, so I 
can't tell if it occurs here too.

The final, least common bit, is that I do NOT see any scrollbar on the message list.  It is always there if I 
switch to another mailbox and then back.  It someimes seems to appear, if i don't pay any attention and just 
start reading the new messages, and look up later to see it's back.

Huh!  Never saw that.

This is with a version compiled from the index_row_height_workaround  branch, but I'm pretty sure I saw these 
issues in master before that.  I'll recompile from master shortly to see if it's still present.

Yes, I can confirm the same issue has already been in master.

Any (strange?) thoughts?

Good question.  Some strange kind of race, maybe.  To be honest, I don't /fully/ trust GtkTreeView, as the 
workaround for the broken row heights is really nasty.  But as other applications (e.g. I saw it in the file 
chooser of the Tor browser) also show the issue, I tend to blame the library for that.

BTW, I didn't forget to investigate the crash you reported in May.  I performs may tests (really!) trying to 
reproduce the issue, but without success.  I'm a little lost there, to be honest.

Best,
Albrecht.

Attachment: pgp9BeLcwh9VM.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]