GNOME Bugzilla – Bug 678408
WebKit renders frames with plain/text parts too small
Last modified: 2013-09-13 01:08:05 UTC
For some mails I get a really small (correct width, about 10 pixels tall) mail view in the preview and in the mail view window. It seems to happen only for non-multipart mime mails. Everything still works, i can scroll inside the tiny view if i hold down the mouse and move around. If i resize the window then the view returns to a "normal" size, but I need to do it again when i show the next mail. Attaching an example screenshot.
Created attachment 216754 [details] Example screenshot
Just for completeness, you're seeing this with the latest Evolution git revision at the time you filed this, correct? Can you also mention your gtk3 and webkitgtk3 versions?
gtk3 is recentlyish git master and webkit is 1.9.3.
and yes, latest git evo
Just as an extra data point, I'm running gtk 3.4.2 and webkit 1.8.1 with the latest evolution git revision and have not seen this problem yet.
Updated to latest gtk+ git master, same problem.
Works OK with WebKit 1.8.2, but I was able to reproduce this issue with WebKitGtk 1.9.3, so it is definitely a regression in WebKit's automatic frame flattening. Reported upstream: https://bugs.webkit.org/show_bug.cgi?id=89553
*** Bug 680330 has been marked as a duplicate of this bug. ***
*** Bug 680562 has been marked as a duplicate of this bug. ***
*** Bug 680991 has been marked as a duplicate of this bug. ***
Can we at least get a work-around in Evolution? Is anyone working on fixing the WebKit bug? It hasn't had a single comment in a month and a half since it was filed.
*** Bug 681313 has been marked as a duplicate of this bug. ***
Created attachment 220559 [details] [review] evo patch for evolution; Let's have this workaround. Even it is a workaround, I consider this bug as fixed, thus I'm closing it too. Once webkit has this fixed, the workaround can be removed.
Created commit ad93908 in evo master (3.5.90+)
For your information: I'm seeing this again using webkit 1.9.6 with evo master.
Hrm. I was testing my workaround on 1.9.6 with one short email (about 4-5 lines of text) and it worked. What I didn't try heavily was moving between messages. There seem to be some state remembered on message change which prevents this workaround to work. Basically, if I move between approximately same long messages, taller than the preview panel, then it works fine, frames are "expanded" as expected in the view. If I move to my short message then, then it's also shown correctly, but moving back to the long message keeps frame 10 pixels height. Interestingly, resizing preview panel makes it work again, same as moving between more messages.
Yes, thats exactly what I see. Eg. the mail of your latest comment is a candidate for the 10px frame.
I've just finished building gnome-3.5.90 which requires webkit 1.9.6. I also built today's evo git/master. The problem is back. Worse, and perhaps unrelated, is I've occasionally gotten stuck in a mode where the message rolls vertically (like an old-style tv screen). At this point, all I can do is kill off evolution and restart.
I've upgraded to webkit 1.9.90, the problem remains.
I've upgraded to webkit 1.9.91, the problem remains.
*** Bug 684039 has been marked as a duplicate of this bug. ***
mbarnes said it might be useful to repost these details here from my bug, so here it is. Basically it's what Milan said in comment #16: any kind of 'refresh' of the preview pane or message window triggers the bug: "Evo seems very susceptible to breakage in the preview pane and message display windows. The symptom is that you have a message selected in the mailbox list view, but the preview pane shows only the headers and a tiny, tiny empty box where the message preview should be. The message text appears to be 'present', in some sense, in the tiny box - if I point the cursor at it carefully I can see that it's activating hyperlinks in the text. But I can't actually see even part of a line of text or anything, it's just empty. Two ways I've found to trigger this: 1. Select an unread mail, it will be properly displayed in the preview pane: then switch to any other window. I just picked the latest unread mail in my box, alt-tabbed to this window, and saw the bug happen immediately. This is 100% reproducible for me. 2. Select a mail in the list, read it in the preview pane, hit 'up' to select the next mail up in the list, hit 'down' to go back to the mail you just read, and you'll see the bug. In fact, any time I click on any mail I've already read in my mailbox, the preview pane is broken in this way. It _only_ correctly shows mails I've never read before, and only ever once, as long as I don't alt-tab. For any mail suffering from this bug, it will also display incorrectly if double-clicked to open in its own window - again the headers will be shown but the box where the message text should be is tiny and apparently empty. Obviously this renders Evo effectively unusable."
One fix is to zoom in or out in the message. Another is to resize the window. I can't reliably reproduce either of the triggers mentioned in comment 22: 1. doesn't happen at all. 2. seems sort of random; i.e., I select a message, zoom in or out to get it to view properly and then switch to another message using up/down. The displayed message sometimes changes and sometimes doesn't. Nonetheless, while evo is still usable, it's a pain to have to constantly zoom in or out.
Created attachment 224485 [details] [review] proposed evo workaround ][ for evolution; Could you try with this workaround, please? It does the zoom-in+zoom-out for you, which seems to force frame size recalculation better than the previous workaround, which pretended size allocation change. It helped me, but I would like to know the results on your side too (and we are under code freeze anyway). Dan, if it'll work, could you ask the release-team for an approval, and push this for 3.6.0, please? I'll be gone, same as Matthew, thus you left here for us to do the paper work and commit :)
Works for me so far. Thanks
In a quick test, seems to be working for me too. For Fedora users, there's a scratch build here of 3.5.92 with the patch: http://koji.fedoraproject.org/koji/taskinfo?taskID=4493177
It works here too. Thanks Milan
Code freeze break approved [0], the fix will be available in Evolution 3.6 Committed to master for Evolution 3.7+ as becfa9 [1] Committed to gnome-3-6 for Evolution 3.6+ as 4a2b0d4 [2] [0] https://mail.gnome.org/archives/release-team/2012-September/msg00163.html [1] http://git.gnome.org/browse/evolution/commit/?id=becfa99e066d525ea2ba3408225235a8542b0005 [2] http://git.gnome.org/browse/evolution/commit/?h=gnome-3-6&id=4a2b0d4f31ee0e5cddaf87ccac2294e6f3f3a620