GNOME Bugzilla – Bug 752166
Line wrapping non-WYSIWYG
Last modified: 2018-07-13 08:04:17 UTC
When I enter a long URL into a compose window, it is not word-wrapped in the composer. I hit 'send'. And then it's word-wrapped, breaking the URL, before it actually gets sent. I've seen various other non-WYSIWYG behaviours from the composer which are probably related, but which I've had less luck with reproducing. I often seem to see lines which I *thought* were going to be on their own, ending up *not* word-wrapped and appended to the previous line. I think they can all be addressed with the same principle — when I hit the 'send' button, you must not send *anything* different to what I was actually looking at, at the moment I pressed the button!
It looks like there is a specific URL which triggers this; not just *any* long URL. However, the real reason for all these non-WYSIWYG issues is a simple one, which is that Evolution doesn't actually *use* the same word-wrapped version which was being displayed by webkit. Instead, it processes it again for *itself*. It is not really appropriate just to patch Evolution's word-wrapping so that it *happens* to behave the same as this particular version of webkit does, with the wind in this particular direction, for this particular text (and tracking down all the other failures which I've been unable to reproduce at will and often don't even notice). The only real fix here is to use the *same* word-wrapping for what we see, as we do for what we send. Can we not work out what was being displayed in the composer when the user hit 'send'? Or invoke the webkit CSS formatting directly somehow?
(In reply to David Woodhouse from comment #1) > However, the real reason for all these non-WYSIWYG issues is a simple one, > which is that Evolution doesn't actually *use* the same word-wrapped version > which was being displayed by webkit. Instead, it processes it again for > *itself*. Is needs to as there is no way how to get the text version of what is displayed by WebKit as wrapping is done by CSS so while generating the final plain text version we need to wrap it again in Evolution. Another thing are the lists. There is no way in DOM how to get the version of it with bullets/numbering.
Then this is a fundamental design flaw. We absolutely *have* to ensure that the *same* wrapping happens for what you see on screen, and what actually gets sent. It's utterly unacceptable to just have some code which *tries* to mostly get it the same. Looking back at my Sent folder, I now realise *just* how badly it's mangled some of the things I've been sending since upgrading to Evolution 3.16, and it's actually really embarrassing. Some of what I've sent is just unreadable. How can we fix it? Either we do the wrapping for ourselves in every case, or we allow WebKit to do it in every case. Surely there's a way we can allow WebKit to render the text using the CSS, and then know what it's done? Even if we have to add new 'internal' APIs to WebKit to allow us to access its rendering functions... We certainly can't leave it as it is.
I filed https://bugs.webkit.org/show_bug.cgi?id=146966
Yay, I've just sent an internal email to about two dozen people, containing a patch snippet which *looked* fine on-screen, but in my Sent folder it looks like this (all on one line): --- crypto/x509v3/ext_dat.h Thu Jun 11 21:50:12 2015+++ crypto/x509v3/ext_dat.h Fri Jun 12 11:11:03 2015@@ -127,8 +127,10 @@ &v3_idp, &v3_alt[2], &v3_freshest_crl,+#ifndef OPENSSL_SYS_UEFI &v3_ct_scts[0], &v3_ct_scts[1],+#endif }; /* Number of standard extensions */ And then there's the footnotes at the bottom of http://lists.freedesktop.org/archives/systemd-devel/2015-July/033555.html which were also corrupted, and what was three lines on my screen became one. Meaning that the first URL there was actually broken and clicking it would take you to a 404 error. I desperately need to have a functioning email client again. Is there any prospect of any kind of fix in the short term?
It might be that we need to stick with the existing design for a while, and continue to play whack-a-mole with the differences between our own rendering and WebKit's. In that case, would it be possible to have a hack which saves the original "internal" version of *every* message that's sent? That way we should at least be able to coherently report the problems when they occur, rather than purely looking at mail archives of the post-rendition plain text and saying "that's wrong". Even better if it pops up a 'preview' window when I hit 'send', and allows me to choose 'yes' to send it, or 'no' to automatically file a bug :)
(FWIW, kinda reminds me of bug #751083... and maybe bug #751398, bug #750657, bug #750615, etc., but not sure about those)
The URL wrapping thing is still going on - see e.g. the fedorahosted.org link in https://lists.fedoraproject.org/pipermail/test-announce/2015-August/001109.html . Like David, I have to say I'm finding the zillion little niggles in post-3.16 pretty demoralizing, it's hard to remember to file a bug for *every single one*, and embarrassing when you find that a mail you sent was badly misformatted...sorry to be negative, but it is kinda a big problem.
I'm closing this as a duplicate of the "Do not wrap URLs in Plain Text mode" bug. For David's "check how it looks like before sending", I use Edit->Preferences->Composer Preferences->[x] Send messages through Outbox folder [Send after 5 minutes], which gives me time to open On This Computer/Outbox and check what will be sent. Not that I always do it, but sometimes I do. right-click the Outbox folder and use Flush Outbox, or File->Send/Receive/Send All, or under Send/Receive toolbar icon, to send them immediately. *** This bug has been marked as a duplicate of bug 757504 ***