GNOME Bugzilla – Bug 699603
Message list scrolls to cursor on style change
Last modified: 2013-08-16 18:24:37 UTC
Using evolution-3.8.1-1+git20130430.fc19.x86_64 Select a folder in the mail view. Select a message to show it in the preview pane. Scroll the message pane (using the scrollbar) such that the selected message is no longer visible, then click away to any other window. Note how the message pane resets so that the selected message is in view again. Please don't warp scroll views for no reason.
Hmm, I can only reproduce that when I switch to another mail folder and back. For me the scrollbar stays where I left it when switching to other windows and also after minimizing/unminimizing. This is with GTK+ 3.8.0.
gtk3-3.8.1-1.fc19.x86_64 here. I feel like I've been seeing this for a while though, I want to say for most of the F19 cycle but obviously that's just an anecdote at this point.
Finally reproduced this, but can only do so in GNOME Shell and Cinnamon environments. Cannot reproduce it on XFCE, MATE or KDE using the same gtk3 and evolution packages. Perhaps it's a feature of the window manager?
I don't fully understand what's going on, but here's what I've observed: - The scrolling is triggered by a "focus-out-event" signal, which in turn triggers a "style-set" signal. - Deep inside ETable, there's a function to determine whether the selection is on screen, and if it is, scroll to the selection. This is executing in response to the "style-set" signal. It uses the scrolled window's vertical adjustment (GtkAdjustment) to help make this determination. - If I pick a large folder, select a message at the top and then scroll all the way down to the bottom, I see the following difference when making the on-screen calculation in various environments: XFCE / MATE / KDE: The GtkAdjustment value is approx 2000, which is about what I would expect since I've scrolled to the bottom of the folder. ETable correctly determines the selection is NOT on screen. GNOME Shell / Cinnamon: GtkAdjustment lies. It reports a value of 70, which is approx the vertical offset of the selected message. ETable mistakenly believes the selected message is on screen and scrolls to it. Why GtkAdjustment is behaving differently in different desktop environments is beyond me. I guess I could try to bisect GTK+ to figure out where this went screwy. Adam, maybe you have some insight here?
*** Bug 705284 has been marked as a duplicate of this bug. ***
Created attachment 250637 [details] [review] evo patch for evolution; The problem is gnome-shell, as Matthew also found, and its style change. The message list tries to keep cursor on screen even after the style changed, which is a good thing, if the cursor was on the screen before. The problem in evolution was that the cursor visibility was "never" recomputed, especially not after the scrolling position changed, thus the ETableItem thought that the cursor is still on the screen, while it wasn't.
Created commit 098b065 in evo master (3.9.90+) Created commit ba0b889 in evo gnome-3-8 (3.8.5+)
*** Bug 706008 has been marked as a duplicate of this bug. ***
please undupe 706008, it's still there despite Milan's patch.