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

[Jack <ostroffjh users sourceforge net>]

Hi Albrecht,

Thanks for confirming my sanity, if nothing else. :-)

On 2020.07.20 15:27, Albrecht Dreß wrote:
> 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.
Yes, I also see this in folders with deep threading.
> > 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.
Probably related is that the vertical scroll-bar often seems very  
narrow to me, and I have to look harder than I remember doing to be  
able to click in it or on the slider.  That's why I not absolutely sure  
it isn't there, or if it's just narrower than usual, although I can't  
imaging the width of the scroll-bar varying.
> > 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.
I realized that, but wanted to be sure no other recent updates had any  
effect on this, and they don't.
> > 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.
I seem to be seeing it less frequently recently, but try creating an  
mbox folder with tens of messages.  Then delete the second, fourth,  
.... from the last.  Select the last message and hit Expunge.  That  
seems to be a common scenario for me.  Before you hit "Expunge" the  
last message is message N, but after expunging several messages, it  
SHOULD be N - number expunged.  I don't know if it's also some race  
condition or if the message number just isn't getting reset to reflect  
the expunging before trying to redraw the message list.
> Best,
> Albrecht.

------quoted attachment------
> _______________________________________________
> balsa-list mailing list
> balsa-list gnome org
> https://mail.gnome.org/mailman/listinfo/balsa-list