GNOME Bugzilla – Bug 739955
Wrap on mail Preview's width, not its content width
Last modified: 2017-10-23 17:11:40 UTC
Hi, At work, I frequently receive messages with some tables inside. Sometimes, the tables are horizontally long and do not fit into the preview panel. Evo is in "show message preview, vertical" mode as I have a wide screen monitor (22", 1920x1080). When such message arrives, due to the tables, a horizontal scroll bar appears in the preview panel. This if fine and useful to look at the table. However, the text inside the email is no longer wrapper at the end of panel boundary, it goes on and on without wrapping to next line until the end of the table. As a result, if there's a horizontally long table in a long email chain, I end up scrolling the horizontal scroll bar just to read normal sentences. as a comparison, Thunderbird successfully adjusts it wrapping for such messages and once the characters in a sentence/line reaches the end of the preview panel, it wraps and continues from the next line. Hope I could explain. I can't attach an example message due to privacy, but i think it's easily reproducible.
Thanks for a bug report. The description is clear to me. Tomas, I think there is some attribute which can limit the width to the current allocated widget's width, even without using JavaScript, isn't it? If not, then involve JavaScript here, which will update the expected width on demand (widget's allocated width change).
Hi, would there be any news on this bug? It's making really difficult to read emails at work. Note that now this problem is not limited to messages with Tables, but it applies to all messages. I have to scroll right & left to be able to read those. Very annoying :( PS. I upgraded, now version 1.15.91.
Created attachment 307968 [details] [review] Proposed patch I'm attaching a proposed patch that I used for some time and it's working for me, but for Milan it caused Evolution to crash on some messages in WebKit code with following backtrace:
+ Trace 235291
Thread 1 (Thread 0x7f10f503ca40 (LWP 17902))
Hi Tomas, Milan, I compiled EVO today from git master and applied the patch to evolution. This seems to solve the bug on most of the messages with all html content. So I'm happy with it. I did not get any crash since an hour with it. However, I recognized the bug persists on messages where 1) the original long line message is a plain text message from a mobile phone 2) There are no tables 3) consequent replies are in html and text I'm attaching the related mbox file to help in debugging. However, I had to replace all message content with bogus characters and remove all email addresses and server names as this is a work related email which I can't disclose. This behaviour can be replicated in each message thread which starts Hope it still helps to understand what's going on.
Created attachment 308448 [details] Wrapping bug when first message is plain text with long sentence.
(In reply to Emre Erenoglu from comment #4) > I compiled EVO today from git master and applied the patch to evolution. > This seems to solve the bug on most of the messages with all html content. > So I'm happy with it. I did not get any crash since an hour with it. Thanks for testing! I'm running it for more than a week and I didn't saw the crash either. > However, I recognized the bug persists on messages where > 1) the original long line message is a plain text message from a mobile > phone > 2) There are no tables > 3) consequent replies are in html and text > > I'm attaching the related mbox file to help in debugging. However, I had to > replace all message content with bogus characters and remove all email > addresses and server names as this is a work related email which I can't > disclose. The problem is that the long line is in preformatted element and it should stay as is. We are sticking with Thunderbird behavior and they are not wrapping the preformatted content as well.
Bad news! Got the crash today systematically on a message. I get this in gdb output, how can I further debug? (evolution:24230): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed [New Thread 0x7fff7a623700 (LWP 24808)] [New Thread 0x7fff493e4700 (LWP 24802)] [New Thread 0x7fff7ae24700 (LWP 24743)] [New Thread 0x7fff78c1a700 (LWP 24716)] [New Thread 0x7fff79c1c700 (LWP 24277)] [New Thread 0x7fff417fa700 (LWP 24268)] [New Thread 0x7fff41ffb700 (LWP 24267)] [New Thread 0x7fff427fc700 (LWP 24266)] [New Thread 0x7fff42ffd700 (LWP 24265)] [New Thread 0x7fff69ffb700 (LWP 24258)] [New Thread 0x7fff808a3700 (LWP 24239)] [New Thread 0x7fff8f5b6700 (LWP 24238)] [New Thread 0x7fffcfdb9700 (LWP 24237)] [New Thread 0x7fffdf532700 (LWP 24235)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5ec5346 in ?? () from /usr/lib/x86_64-linux-gnu/libwebkitgtk-3.0.so.0
Created attachment 308451 [details] backtrace command output I got this output when i issued backtrace command in gdb after the crash.
Without debuginfo for your webkitgtk3 hard to tell for sure, but seeing all the frames coming from webkit, like with the backtrace from the comment #3, I believe it's the same issue.
Probably. Anyway I can test again when that crash is fixed.
Comment on attachment 307968 [details] [review] Proposed patch Just marking this to needs-work, to get it out of unreviewed patches list. The reason for needs-work is the crash with certain messages, which might not be neccesary an issue with the patch, but as long as it'll crash it cannot be used, because not wrapped content is not that big issue as the crash.
*** Bug 686012 has been marked as a duplicate of this bug. ***
Coming back on this for 3.20.3, I can still reproduce this with emails I receive from our exchange server.
Just for a reference, and possibly totally useless, but for example this [1] page has text wrapped on the window width, but the below table can be left wider (just make the window as small as possible and notice that the paragraphs are still within the window width, but the table defines the overall canvas width). I do not know how they do it, maybe it's something in javascript, which is a no-go for evo. I tested the page in WebKit2's 2.12.2 MiniBrowser and it seems to handle it fine. [1] https://hsprod.investis.com/shared/v2/irwizard/sec_item_new.jsp?page=sec_item_new&cik=&epic=redhat&ipage=11007963&DSEQ=1&SEQ=33&SQDESC=SECTION_PAGE&exp=&subsid=41
Has anyone obtained a stacktrace with debug symbols enabled, and/or forwarded this issue to the WebKit folks?
(In reply to Paul Smith from comment #15) > Has anyone obtained a stacktrace with debug symbols enabled, and/or > forwarded this issue to the WebKit folks? There was no need for this, because the patch is based on WebKit1, which is basically unmaintained (in the maintenance mode) by the upstream. Once the patch will be updated to work with the latest development evolution, which uses WebKit2, which is actively worked on by the upstream, then the issue can be shared with them, if any.
Created attachment 335924 [details] [review] Patch for WebKit2 Here is the updated patch for WebKit2 port of Evolution. Feel free to test it.
Created attachment 336168 [details] [review] Patch for WebKit2 Add the missing call to e_dom_resize_document_content_to_preview_width() when the document was loaded. Otherwise the resize was triggered only when the preview was resized.
Comment on attachment 336168 [details] [review] Patch for WebKit2 I'm setting the patch as 'reviewed', to get it out of the unreviewed patches list.
I did a quick testing of the updated patch and it worked as expected, and even didn't crash, on a set of messages I tried it with. Let's commit it and deal with any (if any) issues when (if) they arise. Thanks.
Fixed with the following commits: Bug 739955 - Wrap on mail Preview's width, not its content width Force the width of the elements based on the preview width, but not for messages that were formatted with text-highlight module (there is one exception and it is the plain text formatting). Also include additional fixes to our CSS: * don't break the text in the middle of contact * add missing border around some iframes * remove some of the margins and paddings commit 8f32c35 in the master branch for Evolution 3.23.2+
(In reply to Milan Crha from comment #20) > I did a quick testing of the updated patch and it worked as expected, and > even didn't crash, on a set of messages I tried it with. Let's commit it and > deal with any (if any) issues when (if) they arise. Thanks. I just got a crash, with the below backtrace. It was when Ctrl+Shift+F in a message source (Ctrl+U) after having several messages viewed in a dedicated window (double-click in message list). It looks like the signal handler had been registered twice, due to dynamic loading (as written elsewhere in the code), one with an already freed 'document' pointer. Removing the previous handler works, thus: Created commit feed865 in evo master (3.25.3+) Created commit cf80358 in evo gnome-3-24 (3.24.3+)
+ Trace 237560
Thread 1 (Thread 0x7f6fc4078f40 (LWP 28913))
Another follow up change due to a similar crash reported downstream [1], which shows that the above change was not good enough. Created commit 929dbca69c in evo master (3.27.2+) Created commit 6fd3d59c28 in evo gnome-3-26 (3.26.2+) [1] https://bugzilla.redhat.com/show_bug.cgi?id=1504503