GNOME Bugzilla – Bug 757504
[Composer] Do not wrap URLs in Plain Text mode
Last modified: 2018-08-28 06:55:59 UTC
The old composer handled URLs well, and simply: it just never wrapped them. If you were typing a URL and you went past the line length limit, the entire URL moved down a line. If a URL, alone, was longer than the line length limit, Evo would ignore the limit and keep the URL on a single line. The new composer (in Normal mode, where the composer is doing line wrapping for you) does both of those things wrong. If you're typing a URL and you hit the line length limit, it splits the URL somewhere. In a test I just did with this text: Hi there, I'm typing an email, and http://www.foobar.com is a URL. http://www.google.com is too. it kept the 'http' of 'http://www.google.com' on the first line and wrapped the rest of the URL to the second line. I also tried putting this URL on a new line: http://www.whatalongurl.com/ohmygoodnessthatsreallylongbutwerestillnotgoingtowrapitohdearwedid the old composer would have kept that URL on a single line, despite the fact that it's longer than 72 characters, but the new composer wraps it at 72 columns. Any time the composer wraps a URL, of course, that URL will be broken for anyone clicking on it in the mail as sent out.
(In reply to Adam Williamson from comment #0) > The old composer handled URLs well, and simply: it just never wrapped them. > If you were typing a URL and you went past the line length limit, the entire > URL moved down a line. If a URL, alone, was longer than the line length > limit, Evo would ignore the limit and keep the URL on a single line. > > The new composer (in Normal mode, where the composer is doing line wrapping > for you) does both of those things wrong. If you're typing a URL and you hit > the line length limit, it splits the URL somewhere. In a test I just did > with this text: Hi, I didn't know about that behavior. You are saying that if you are pasting an URL that is longer than "word wrap length defined in preferences" Evo inserts a new 'Preformated' block (in plain text mode the 'Normal' paragraph will always wrap and I won't change it) below the current one and inserts the URL there. If the URL is shorter and it still doesn't fit the current line it will put the link into a new 'Normal' block below. Sounds reasonable, but you can achieve the same by using splitting the URL to the 'Preformated' block if you see that it was wrapped. That is what I'm doing now.
Well, yes, of course, you can work around the problem manually, but it's silly to expect users to sit there fiddling around with 'Normal' and 'Preformatted' blocks, especially when they never used to have to. I should just be able to include URLs in-line when I'm typing and not have Evolution wrap them across lines, ever, just like it used to. How you want to implement that is up to you ;)
*** Bug 760549 has been marked as a duplicate of this bug. ***
Why is this considered a normal enhancement, this is a regression. This should be fixed asap. As an evolution user for over 10 years, I am actively looking for a new mail client after updating from FC21 to FC23 and this bug is one of the reasons for that. Sorry for the noise, but please fix this.
*** Bug 762549 has been marked as a duplicate of this bug. ***
That's indeed very annoying. I got trapped several times when sending URLs which the recipients considered as invalid because they were cut. How embarrassing when sending this to a large mailing list...
*** Bug 768698 has been marked as a duplicate of this bug. ***
Adding myself to the list as I also stumble across this once in a while. Evolution 3.20.5 on antergos.
It’s still present in Evolution 3.22.0 (Debian Sid/unstable).
Any plans to fix this?
*** Bug 773311 has been marked as a duplicate of this bug. ***
Part of this is still valid in 3.23.91. Short URLs entered near the end of a line correctly get wrapped to the next line, but a long URL (longer than the entire line length) still gets wrapped, which I maintain is incorrect.
Definitely a serious bug, I wonder how people can keep using this e-mail client professionally. I wanted to switch from Thunderbird to Evolution. I have had many times the suprised to have my recipient calling me telling me that I put the wrong link. Please fix this.
jc: A workaround is available (use preformatted mode for a line that includes an URL only). In general, please avoid '+1' comments in bug reports - thanks! :)
To avoid the problem, maybe the url in text mode should not be converted into link ?
It worked perfectly fine before the switch to WK2 composer, so... just switch back to the old behavior?
URIs *can* be word-wrapped, FWIW. See bug 783811: <https://bugzilla.gnome.org/ show_bug.cgi?id=783811>
(In reply to Michael Catanzaro from comment #16) > It worked perfectly fine before the switch to WK2 composer, so... just > switch back to the old behavior? That's not true, it behaves in the same way in the WK1 and the WK2 based composer. And if anything changed, it was not intentional.
(In reply to Tomas Popela from comment #18) > (In reply to Michael Catanzaro from comment #16) > > It worked perfectly fine before the switch to WK2 composer, so... just > > switch back to the old behavior? > > That's not true, it behaves in the same way in the WK1 and the WK2 based > composer. And if anything changed, it was not intentional. I can only verify over the weekend where I have access to Evolution 3.12.9 from Debian 8 (Jessie). But it worked in the past. Maybe just in GtkHTML(?).
David: well, neither Evolution nor Firefox works with that, so if those two don't work, I'm not sure trying to use it is a good idea.
And I agree with Paul and Michael that this is *definitely* a regression with the 'new' (not so new, now) composer. Evolution absolutely used to do this properly with the old composer (it would automatically keep URLs on a single line).
I thought it was caused by switch to WK2 composer, but I might be misremembering. At least it started around that time.
As Adam (the reporter) is saying, this is a regression, but from GtkHTML to WK1, not from WK1 to WK2, AFAIR.
Yeah, that sounds about right. Note that the WK1->WK2 change occurred around 2016-08, but this bug was filed 2015-11.
So is it possible to just add a condition to the composer to not wrap the urls ?
There's a mixed behaviour here. If a very short link is at the end of a line, it gets entirely moved on the next line, and this is the expected behaviour. But if a long link, still shorter than the line length limit, lets say 65 chars, follows a short text, it gets split, rather than moved to the next line. ex: <15 chars text>www.link.com/<41chars>/test.html will be wrapped as follow: <15 chars text>www.link.com/<41chars>/t est.html instead of: <15 chars text> www.link.com/<41chars>/test.html That doesn't happen if the link is short. In my testing I found out that if the text before the link is longer than 33 characters the link is wrapped correctly.
Created attachment 364929 [details] [review] test patch I can disable wrapping of recognized URLs (those which are "underlined") with this change, but it has side-effect that what users see is not what they get, because composer still wraps the URL, even it is sent unwrapped. I do not know how to make this work also in the visual side of the composer.
Unfortunately I think it really needs to be WYSIWYG, I'd be very confused by that I think :/ I tend to take it as a given that what I see is what actually gets sent, otherwise how else can you compose?
(In reply to Milan Crha from comment #27) > because composer still wraps the URL I end up all the time with manually inserting linebreaks before and after long URLs and manually setting that URL line to "Preformatted" instead of "Normal". And the user settings offer a value for "Number of characters for word wrapping". So all logic seems to already be in place anyway?
(In reply to Adam Williamson from comment #28) > Unfortunately I think it really needs to be WYSIWYG, I'd be very confused by > that I think Yes, I agree, that's why I made it as a test patch, not as a solution. (In reply to André Klapper from comment #29) > I end up all the time with manually inserting linebreaks before and after > long URLs and manually setting that URL line to "Preformatted" instead of > "Normal". Yes, I do it too. > And the user settings offer a value for "Number of characters for > word wrapping". So all logic seems to already be in place anyway? Yes, this kind of logic is truly there. Once upon a time, Tomas told me about an idea of splitting the paragraph just that way, only automatically, instead of forcing users to do that. One of the reasons for the split is that the wrapping in the editor is done by WebKit, not by the evolution code. That has its pros and cons, of course. I'm pretty bad in WebKit/DOM/composer coding, thus it's only a little push up from my side now, nothing more.
I'm wondering how much I'll break with this... Let's see after the Monday release. Created commit 15bb2cb6fb in evo master (3.29.4+) Created commit 651d9f4fe4 in evo gnome-3-28 (3.28.4+)
yay for breaking stuff! If you send a build to Rawhide I'll be able to test it.
(In reply to Adam Williamson from comment #32) > yay for breaking stuff! If you send a build to Rawhide I'll be able to test > it. Here's one for Fedora 28 from yesterday: https://koji.fedoraproject.org/koji/taskinfo?taskID=28111037 and here's the one for rawhide (ongoing): https://koji.fedoraproject.org/koji/taskinfo?taskID=28136650 , but I do not know whether it'll finish, because there are some build issue in rawhide currently (or had been in the few past days), I noticed some folks talking about it on the Fedora devel list. Let's see.
(In reply to Milan Crha from comment #33) > and here's the one for rawhide (ongoing): It failed due to other commit missing. I added it and then it succeeded: https://koji.fedoraproject.org/koji/taskinfo?taskID=28136850
*** Bug 752166 has been marked as a duplicate of this bug. ***
There is my completely untested etc. package for openSUSE https://build.opensuse.org/package/show/home:mcepl/evolution#
An issue caused by the above change: https://gitlab.gnome.org/GNOME/evolution/issues/71
One more thing I missed while testing the initial change: https://gitlab.gnome.org/GNOME/evolution/issues/103