User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 When receiving a mail which contanins long http-Links, the links are displayed correctly and I can follow the link. However if the message is moved, the link gets line wrapped (even if mail text wrapping is switched off in preferences) and when clicking on the link, only the first part of it which wasn't wrapped is followed. It doesn't matter whether the mail is moved automagically by a mail filter or manually with DnD. In case it matters, the mail folder is an Imap account. Reproducible: Always Steps to Reproduce: 1. receive a message with a long link (doesn't have to exceed the window width) 2. Move (or copy) the message to a different folder 3. Look at the wrapped link Actual Results: The link can't be followed any more, copy-paste is needed. Expected Results: Link should be followable by clicking.

How long of a link is required to exhibit the problem? Is the message in plain text, or HTML? If plain-text, is it "format=flowed"? (Check the source to see the Content-Type header.)

(In reply to comment #1) > How long of a link is required to exhibit the problem? > > Is the message in plain text, or HTML? If plain-text, is it "format=flowed"? > (Check the source to see the Content-Type header.) Here is the header copied from such a mail up to the wrapped link (the link is already wrapped): Received: from appmail2.eu.infineon.com ([172.29.27.229]) by mucse204.eu.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Apr 2004 08:09:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Received: from mucse014.eu.infineon.com ([172.29.27.231]) by appmail2.eu.infineon.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Apr 2004 08:09:31 +0200 Received: from sonja.muc.infineon.com ([172.31.97.182]) by mucse014 with tre nd_isnt_name_B; Fri, 23 Apr 2004 08:09:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Received: from mail-g.muc.infineon.com (mail-g.muc.infineon.com [172.29.175. 37])by sonja.muc.infineon.com (8.12.11/8.12.9) with ESMTP id i3N69Ti6024529 for <Dominik.Strasser@infineon.com>; Fri, 23 Apr 2004 08:09:29 +0200 (MEST) Received: from heizer5.muc.infineon.com (heizer5 [172.29.175.36])by mail-g.m uc.infineon.com with ESMTP id i3N69LTj001439for <Dominik.Strasser@infineon .com>; Fri, 23 Apr 2004 08:09:22 +0200 (MET DST) Received: from heizer5.muc.infineon.com (localhost [127.0.0.1])by heizer5.mu c.infineon.com with ESMTP id i3N69JZ7022576for <Dominik.Strasser@infineon. com>; Fri, 23 Apr 2004 08:09:20 +0200 Received: (from cve@localhost)by heizer5.muc.infineon.com id i3N69JlP022558 for Dominik.Strasser@infineon.com; Fri, 23 Apr 2004 08:09:19 +0200 Return-Path: <cve@mail-g.muc.infineon.com> X-OriginalArrivalTime: 23 Apr 2004 06:09:31.0929 (UTC) FILETIME=[8B1FA090:01C428F9] X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:11.22665 C:20 M:1 S:5 R:5 X-imss-settings: Baseline:5 C:3 M:4 S:4 R:4 (0.2500 0.7500) content-class: urn:content-classes:message Subject: -E- Nightly Build cve_3.98c Date: Fri, 23 Apr 2004 08:09:19 +0200 Message-ID: <200404230609.i3N69JlP022558@heizer5.muc.infineon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: -E- Nightly Build cve_3.98c Thread-Index: AcQo+YsoN0+ZSmC0T1Wd2HHhLIZi3w== From: "CVE Release Management (Raik Brinkmann)" <cve@mail-g.muc.infineon.com> To: "Strasser Dominik (CL DAT DF V)" <Dominik.Strasser@infineon.com> Tools: Compilation results for Linux -I- gateprop : BUILT Compilation results for sun4_u5 -I- gateprop : BUILT Compilation results for sun64_u5 -I- gateprop : BUILT Testbenches: FOR OS Linux -E- cve_tools_quick_check FINISHED WITH STATUS:TB_ERROR FOR OS Linux (TND-Result-Protocol: No such file exists) (TB-ResultCheck-Protocol: No such file exists) -I- faultfinder_gat FINISHED WITH STATUS:ENDED FOR OSLinux (TND-Result-Protocol: http://moebius.muc.infineon.com/~cve/.cgi/list_nb.cgi/nb_new/protocols/c ve_3.98c//Linux_heizer4_tb_faultfinder_gat_result.prot)

I could also a non-wrapped message if needed, please tell me if you need it.

The links in the message attached to this bug have already been wrapped; it is not Mozilla's fault that they are displayed as wrapped.

(In reply to comment #5) > The links in the message attached to this bug have already been wrapped; it is > not Mozilla's fault that they are displayed as wrapped. Yes. This is the state of the mail _after_ the filter has run or I manually moved it. If the message resides in the Inbox, the links aren't wrapped. Do you need an unwrapped mail ?

This is a similar mail _before_ the wrapping occurred.

Hmm. I see that your wrapped mail is coming in via a Microsoft Exchange server. Are you using IMAP to access that server? I integrated your message into my mbox; it displayed OK. Then I used Edit As New to send the message to myself; both the Sent version and the version I received (via a POP3 account) were fine. Bug 149771 describes similar problems with messages received from an Exchange server over IMAP. In fact, the wrapped message you posted/attached shows the same symptom as at that bug: any header which has been "folded" loses all the (necessary) whitespace at the beginning of each folded header; e.g.: ===== X-imss-settings: Baseline:5 C:3 M:4 S:4 R:4 (0.2500 0.7500) content-class: urn:content-classes:message ===== becomes ===== X-imss-settings: Baseline:5 C:3 M:4 S:4 R:4 (0.2500 0.7500) content-class: urn:content-classes:message ===== It's quite possible that the long lines are being forcibly wrapped in that scenario as well.

(In reply to comment #8) > Hmm. I see that your wrapped mail is coming in via a Microsoft Exchange server. > Are you using IMAP to access that server? Yes. I experimented a little bit more. The problem only occurs if I copy from an IMAP folder to another IMAP folder. If I copy to a local folder, no wrapping occurs. Even if I copy the message back from the local folder to an IMAP folder, the message remains intact. Even IMAP->Local->IMAP->IMAP works which is really astonishing as IMAP->IMAP doesn't. And yes, the headers are altered, too. There consecutive lines are _merged_. So the behavior seems to be: If header lines have to be merged, links and maybe more get wrapped. The message copied back and forth is identical to the non-copied one (modulus a deleted line in the end).

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.