Plain text body didn't word-wrap. No scrollbar in full screen mode.

[Github-Citizen]

Roundcube v1.5.0

I saw an email today that had no mime/content types and was plain text. There were two lines of text that were very long and went past the edge of the screen. One line was a > quoted reply and was truncated. The second line was complete but off the edge of the screen, you could only read it if using the horizontal scroll bar at the bottom of the message body window. Shouldn't this have just word wrapped instead? Why is the > quoted section truncated and not readable even using the scroll bar?

I double clicked the email in the folder list to open the message body full screen. Both the > quoted and regular long lines still went off the edge of the screen however there was no horizontal scroll bar. It was impossible to read the ends of the two lines.

Raw Email

Return-Path: <dovecot-bounces@dovecot.org>
... [Headers shortened] ...
Reply-To: Dovecot Mailing List <dovecot@dovecot.org>
Errors-To: dovecot-bounces@dovecot.org
Sender: "dovecot" <dovecot-bounces@dovecot.org>

On 05/11/2021 07.01, Sean McBride wrote:
> But now I have a user who accidentally used a POP client, and it deleted all his email.  He told me this only days later, and it's now been days later still, and so of course he has sent and received email since.  I have backups of course, but it is a feasible thing to 'merge' the deleted emails from the backup into his current mailboxes?

Personally, I'd restore them to another, temporary account set up for the purpose. Then I'd either use

- dovecot sync,
- imapsync, or
- manual drag and drop from one account to the other in Thunderbird

to put the mails back in place, depending on volume of mail involved and personal whim. The Thunderbird route would be easiest for a user to do themselves once set up. However as mail is downloaded from the server to the desktop and then back up to the server, it would take a while if there were lots of messages to deal with.

P.

You can see both lines not word wrapping.

And when using the scrollbar the > quoted line is truncated.

And in full screen there is no scrollbar, and i noticed the > quoted line is not being truncated but you are still unable to read the full line because you can't horizontal scroll the screen. This is on desktop using Firefox and not on mobile.

[alecpl]

No wrapping for non-format=flowed plain text is intended. The problem with quoted lines is a bug.

Ref: #6974.

And I'm pretty sure this is not 1.5.0, but git-master. In 1.5.0 the quoted text is wrapped for me.

[Github-Citizen]

What about no horizontal scrollbar in full screen mode?

[Github-Citizen]

Since you said wrapping worked for you i did more testing. I copy and pasted the email to resend to myself with different config settings. And on the emails i sent to myself it did word wrap and never produced a horizontal scroll bar. I confirmed in message raw source they were still single non wrapped lines.

I have a theory. Maybe the original sender used a linux command line editor and whatever was used to compose the original email did not include proper \r\n end of line confusing roundcube.

[Github-Citizen]

And you can see, on the emails i sent myself from roundcube, the > quoted line also wrapped and did not truncate.

So i am not sure there is anything to fix on this issue as it seems to be a one off issue caused by the original sender, maybe incorrect end line line characters.

[alecpl]

If Content-Type contains format=flowed parameter the text is auto-wrapped, if there's no such thing it is not. The fix we need is to make sure that in the latter case the text is not cut (quoted lines only). It is a css issue we have to fix.

[Github-Citizen]

Unless im misunderstanding you, in the above testing they did not contain format=flowed but still wrapped. Those email's headers contained:

MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[alecpl]

I described git-master behavior, 1.5.x is different. Sorry, for confusion.

[Github-Citizen]

Referring to git-master confuses me. I thought this git (1.5.0) is the master. Is the git-master the work in progress that will end up being the next released stable version, such as 1.5.1?

[alecpl]

The master branch is work-in-progress, unreleased, potentially unstable, to-be released as 1.6.x in the future. Stable 1.5.x versions are being worked on in the release-1.5 branch.

[Player701]

I seem to be having a similar issue: I just received a message with Content-Type: text/plain; charset=us-ascii; format=flowed, and it seems that it should wrap but doesn't: the message proper is rendered as a single long line with a horizontal scrollbar at the bottom. Should I open a separate report for this? I'm using 1.5-rc for now but planning to upgrade to a stable release (1.5.1) sometime later this month. Please let me know if there has been any changes related to this part of code since 1.5-rc, and I could try to expedite the upgrade process somewhat (provided I can find some time for that) and report back as soon as possible.

[Player701]

Reported another issue potentially relevant to this one (see above): #8378

[Github-Citizen]

Just to update this situation. I updated to Roundcube v1.5.2 today and this is still an issue. Some emails with long lines are not wrapping and producing a horizontal scroll bar.

Here is the show source of an email that causes the horizontal scroll bar.

...Unimportant Headers Pruned...

From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: postfix-users@postfix.org
Subject: Re: Google and UK.COM domains
Message-ID: <20211214185849.h4faj3w4kmmizmtj@crankycanuck.ca>
Mail-Followup-To: postfix-users@postfix.org
References: <733c7018-c37a-ec8d-f4db-fd0a84d43a2d@linkcheck.co.uk>
 <20211213104145.GA20726@rafa.eu.org>
 <209120682bc5e90f122f5651a14acf7c@junc.eu>
 <8a9baddc-72b4-c613-3050-a431441e363f@tomatoservers.com>
 <447D651F-5CE8-49CF-A655-90D61CD3A8F5@billmail.scconsult.com>
 <20211214181036.3yiz7dybfzsr2zxl@crankycanuck.ca>
 <79920177-1326-4279-A14F-3B543E1C21AA@billmail.scconsult.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <79920177-1326-4279-A14F-3B543E1C21AA@billmail.scconsult.com>
Sender: owner-postfix-users@postfix.org
Precedence: bulk
List-Id: Postfix users <postfix-users@postfix.org>
List-Post: <mailto:postfix-users@postfix.org>
List-Help: <http://www.postfix.org/lists.html>
List-Unsubscribe: <mailto:majordomo@postfix.org>
List-Subscribe: <mailto:majordomo@postfix.org>

On Tue, Dec 14, 2021 at 01:34:06PM -0500, Bill Cole wrote:
>
>For example, I could *CLAIM* to be an independent customer of whoever 
>runs scconsult.com as a registry, and I just "registered" 
>billmail.scconsult.com with them, and therefore am completely innocent 
>of the bad behavior by some evil guy who "registered" 
>spammer.scconsult.com.

Yes, totally.  This was an issue we experienced with dyndns.org domains, for instance (I used to work there).  The ICANN community remit is basically policy over the DNS root zone, and despite the many efforts various people have made to sell them as "the people in charge of the DNS" the DNS, plainly, does not actually work that way.

>The legitimacy of eu.org and uk.com *as registries* is unmoored to 
>ICANN policy, just as scconsult.com would be if I ran it as a 
>registry+registrar. I don't follow ICANN activities closely but I 
>believe that they explicitly allow registrars and registries to judge 
>a domain to be used abusively and rescind the registration. Back in 
>the distant past, some would do so.

COM has always been fairly reluctant to cancel things.  PIR, who are the registry for ORG, have IMO a fairly robust but narrow meaning of "abuse", which they definitely enforce.  There are ICANN consensus policies that make it much easier for the registrar to act than for the registry, however, and that is how the market is designed & so is as it should be.  (Full disclosure: I'm the CEO of the Internet Society, and PIR is a supporting organization of the Internet Society.  I am not speaking for the Internet Society here and I'm definitely not speaking for PIR.)

And this is what it looked like in Roundcube 1.5.2

[alecpl]

Fixed.