GNOME Bugzilla – Bug 255303
changing folders strangeness
Last modified: 2013-09-13 12:24:39 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: When I switch from folder A to folder B back to folder A, I find myself looking at a different part of folder A than I had been the first time. Steps to reproduce the problem: 1. Go into folder A, scroll down to the bottom (where the new messages are) 2. Go to folder B 3. Go back to folder A Actual Results: The scrollbar is somewhere in the middle of folder A, not at the bottom where I left it. Expected Results: I should still be at the bottom of A. How often does this happen? "Sometimes". If there's a pattern to it, I'm not sure what it is. Additional Information:
basically this comes down to: we need to remember the scrollbar position in addition to the selected uid since in maws case, no message was selected and so we couldn't jump back to the bottom of the list.
can we: - get the top of view uid when we go away - jump back to that view position later on? i think remembering/restoring scrollbar positions directly will be a very unreliable way to do this.
NotZed: the problem with the UID thing is that ETable likes to adjust the scroll position by "centering" the selected row. the problem I see with the scrollbar position is that the number of items in the message-list may change and thus we may need a different scroll offset... ugh. I dunno.
whats wrong with centering on the selected message? its better than not showing it.
btw i've been seeing other stuff to do with changing folders. e.g. change to a big folder on a remote server, and then change to another quickly. you'll end up looking at the big folder but the other folder will be shown as the selected folder in the tree.
on the last point, that was my fault, trying to optimise interactivity too much, folders could be set out of order.
well, I've "fixed" this in the mailer code, except that the fix doesn't work due to etable's scroll-to-cursor feature which apparently is done in some idle callback or something.
Created attachment 43580 [details] [review] 55303-mailer.patch
the mailer portion of the patch will likely need to change to fit whatever workaround gets created in etree, but whatever.
*** bug 257062 has been marked as a duplicate of this bug. ***
please look at this jeff. mike certainly isn't going to.
I already looked at it before, but couldn't figure out how scrolling worked in etree for the selection stuff. just got clahey to point me at e-table-item.c:eti_show_cursor() which can sometimes be called in an idle handler. followed that to e_canvas_item_show_area_delayed() in e-canvas-utils.c which does canvasy stuff in a timeout. now I'm just scared. I really don't know what the fuck I'm doing with this code. I think I'm more likely to fuck shit up than actually manage to fix this... also note that there's a race condition in this code because sometimes when I select a folder, the last selected message gets selected, but etree never scrolls. I'm really not the right person to mess with this code.
Created attachment 43669 [details] [review] 55303-mailer-2.patch
above patch works around this problem without having to modify ETable stuff... going with this solution for now. Zucchi will probably revert it tho. Oh well. I'll let him deal with fixing ETable if he wants a better solution.
I really don't like this patch. But sure i guess it should go in. I actually don't like the whole way the scrollbar position is saved and restored anyway. It should save the top message, not the double scrollbar location, but whatever. ETable should really be fixed. Anyway, i'm going to re-open this bug at a lower priority, since no, it isn't fixed, although the symtpom in the mailer might be fixed by the patch.
*** bug 257584 has been marked as a duplicate of this bug. ***
Michael, Jeff, what is the result. Is the patch applied? What do you think about rescheduling that for 2.1 if the patch is applied?
ops, I forgot to Cc you guys.
the patch is already applied, but it'd be nice if we can fix this. I'd say it's not a high priority tho...
Using 1.5.9.1 from debian unstable I still see this problem sometime for my IMAP mailboxes (I only have IMAP mailboxes, so I don't know if it is still there for other mailboxes). It doesn't happen every time, but sometimes it sets the possition to some other place in the mailbox. It seems to be the same wrong possition in the mailbox too, at least as long an nothing else has changed (no new mail aso).
*** bug 260376 has been marked as a duplicate of this bug. ***
adding patch keyword
andre, the patch in the list is already applied. And i tried reproducing it. I couldnt. It works for me. As Mattias said, may be occuring in some specific scenario.
retargetting, moving to evolution.
also see bug 325922
*** Bug 227697 has been marked as a duplicate of this bug. ***
changing target milestone from 2.5 to future. sorry, too many bugs, too less time.
*** Bug 236532 has been marked as a duplicate of this bug. ***
Bumping version to a stable release.
Does this still happen in 3.2/3.0.3?
It does happen, and I say WontFix. Select the message and this is remembered, no way to play with scrollbar position, it'll just make things unnecessarily complicated (think also of different themes with different font sizes and so on).