GNOME Bugzilla – Bug 706008
Workaround gnome-shell style change on focus change
Last modified: 2014-02-12 23:16:52 UTC
when evo gets the focus, the scrollbar in the preview pane jumps unexpectedly and if some text was selected, it's reset too. this happens both with evo and another app in the same viewscreen, or when changing workspace (both when evo re-obtains the focus). This is annoying in itself, but it makes copy/pastes difficult, especially when using a WM in follow or sloppy focus mode. evo 3.9.5, webkitgk 1.10.2, gtk 3.9.11, gnome-shell 3.9.5
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 699603 ***
@mbarnes, I just tried master, the bug I described is still there. It's even worse now: selecting some text now resets the scroll too (it was fine before). evo rev 18d8747, eds rev d30742e
Where do you select the text, please? Aka, could you be a bit more specific what to do in gnome-shell to see the bug happening, please? Honestly, this seems like a bug in gnome-shell, for me, doing some nasty things in the background.
case 1: scroll reset 1/ preview a mail longer than the preview pane height 2/ scroll down a bit 3a/ in gnome-shell, move to another workspace (i do it with the keyboard shortcuts) and come back to the workspace where evo is or 3b/ assuming evo is not full screen and you have another app on the same workspace, just move the focus from evo to that app and back to evo ==> the preview pane scroll is back at the top case 2: selection reset same steps as case 1, but in step 2, you can select some text (I do it with the mouse, just click drag some text so it's highlighted) ===> the selection is gone (no more highlight), and of course the scroll is back on top. the difference between my initial report and my #c2 is that those two resets now happen when evo loses the focus. It's clearly visible when doing step 3b. as for it to be gnome-shell bug, i'm not that sure. no other app behaves that way (I tried gedit, gnome-term, emacs, chromium, xchat, you name it..). it's clearly a regression but as i'm tracking most of gnome 3.9.*, it's difficult to tell which piece has caused that regression.
oh, i just found another scroll regression case 3: message list pane scroll jump 1/ in the message list pane (with the From/Subjects/Dates), scroll down a bit and select a message, it's displayed in the preview pane 2/ scroll again, up or down but without selecting another message 3/ give the focus to another app => in evo, the message list pane scroll unexpectedly jumps to where it was at step 1.
OK, I can reproduce case 1 and case 2, they are the same issue, from my point of view. The case 3 is bug #699603 and I cannot reproduce it, as long as I scroll as much as the selection in the message list is not shown on the screen.
So, this is caused by the style change on the window (or widget in general), when the focus changes. I can mimic it by changing Theme in my desktop. Because of gnome-shell changing the style context, the message preview is redrawn to show the view in a way of the current style. That's a good thing, isn't it? This redraw is initiated by e_mail_display_reload() called as a callback on a color change for the EMailFormatter. The most we can do might be to define colors as CSS properties and change only the CSS, instead of redrawing the view completely, with all the side effects. The thing is that I do not know whether it is possible with Webkit at all. Tomas, do you have any idea, please?
Given that the message content is typically transient (user reads a message and moves on to another), and that gnome-shell has taken to triggering these style change signals spuriously, I wonder if we should just ignore the style change signal completely. If it can't be trusted then it's not worth the trouble.
Right, I thought that too, but then recalled that "the right GNOME way" is to "see what you get" immediately, like no Cancel on preferences change. We cannot distinguish between "gnome-shell cheats us" and "user changes current theme", thus we might end with bug reports about "the preview panel updates its view only after message change", "the preview doesn't change when I focus out in gnome-shell", and other similar "why doesn't this just work" issues. Hmm, what about not reloading, if there is active selection? It'll not fix the scrollbar position (gtkhtml had a flag for it, to "keep scroll position", maybe we can mimic it in EWebView), but it'll "address" the selection issue.
e_mail_formatter_set_color() calls gdk_rgba_equal() to check for an actual change from the previous color value, so the fact that these color change emissions are happening implies GtkStyleContext may be changing its color values on selection and focus changes. And since the theme remains constant for selection and focus changes, the GtkStyleContext colors may be momentarily set to wrong values, which would explain the spurious signal emissions. Bit of a long shot, but worth at least checking before we go hacking around this too much in Evolution. If my guess pans out then there's a gnome-shell bug to be filed.
I'm not sure I've got the comment #10 right. A "selection change" is not the case here, but the "focus change", in a meaning of changing between toplevel windows, is a problem in gnome shell, because it intentionally changes colors to light gray, probably to suggest the window is in the background, while the foreground window is drawn with "sharp" colors.
*** Bug 706751 has been marked as a duplicate of this bug. ***
Created attachment 254657 [details] [review] Proposed patch Avoid redrawing (thus loosing the selection and scroll position) of preview window in Mail, Memo, AddressBook on style change by utilizing the CSS in preview.
Review of attachment 254657 [details] [review]: Nice. That looks way more elegant than the previous clumsy color handling.
Review of attachment 254657 [details] [review]: e_mail_display_set_status() still uses old colors, no styles. Nonetheless, the patch testing seems to provide expected output, thus I'd say just fix the minor things and commit. Thanks. ::: e-util/e-web-view.c @@ +3366,3 @@ + WEBKIT_DOM_CSS_STYLE_SHEET (sheet), + ii, NULL); + } Can there be more than one rule of the same name? If not, then 'break;' inside the 'if' @@ +3381,3 @@ + +static void +add_css_rule_into_style_sheet_recursive (WebKitDOMDocument *document, there is a \t between the function name and '(' @@ +3424,3 @@ + * + * Insert new CSS rule (defined with @selector and @style) into CSS style sheet + * with given @style_sheet_id. If style sheet doesn't exists, it's created. s/exists/exist/ ::: em-format/e-mail-formatter-text-plain.c @@ +111,3 @@ + content = g_strdup ( + "<div class=\"part-container pre " + "-e-mail-formatter-content-color -e-web-view-text-color\" " I see an inconsistency in a replace of E_MAIL_FORMATTER_COLOR_CONTENT. Here is used -e-mail-formatter-content-color, while elsewhere is used -e-web-view-background-color. Which one is correct? ::: mail/e-mail-display.c @@ +881,3 @@ + color_value); + + g_free (color_value); you are leaking the 'color' here. I would also initialize the 'color' to NULL. @@ +1611,3 @@ + color_value); + + g_free (color_value); you are leaking the 'color' here. I would also initialize the 'color' to NULL.
Created attachment 254768 [details] [review] Proposed patch v2 Updated patch with fixes from Milan's notes. Also background for HTML messages was reverted back to white.
Review of attachment 254768 [details] [review]: Thanks, I didn't check the patch as such, only its functionality, and it overall works as expected. Feel free to commit it. I found only one issue, with a dark theme, when I have nothing in the preview, and I invoke Edit->Preferences for the first time, then its background turns into white. Selecting a message makes it dark again. You can fix this either separately, or before committing this patch. It's up to you. You definitely didn't cause that by your patch.
Fixed with commit f6bad3 in master.
Looks like 3.10 is still affected by this, I guess it's too hard to backport to that one? Thanks :)
It was committed to master for 3.9.92 development version, thus it is part of 3.10.0+. How is that it regressed for you? Could you provide any precise steps and what you see, please? Tomas, could a webkit update cause misfunctionality with compare of tested environment back in 2013-09-12?
The issue I am still suffering is: - Having a lot of new unread mails in a folder - Start reading one - One I remove it pressing Ctrl+D, the next message is shown but, on the list of mails, the list is not pointing to that new opened mail, but to some random place in the big list of unread mails
Ah, OK, then it's a different issue, because this one is about a message preview jumping to the top when user switched to a different application (and back to Evolution). Your bug is most likely bug #446659 if I understand correctly that your problem is with the message list, not with the message preview panel. I marked your already filled bug #706782 as a duplicate of it too.
Indeed it's with the list, but that bug is also supposedly fixed in 3.10 and it is not the case (at least with my problem) :(