Closed Bug 670884 Opened 13 years ago Closed 6 years ago

forward inline of invalid HTML forwards only part of message (if HTML tag such as <p> for HTML body text is placed before <html> tag by mail sender, elements before <html> tag is discarded by Forward inline)

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 394322

People

(Reporter: lionel, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Anonymized / minimized testcase reproducing the problem
(deleted), text/plain
Details
User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110701 Iceweasel/3.5.16 (like Firefox/3.5.16) Build ID: 20110701103042 Steps to reproduce: Got multipart message with text/plain part and text/html part. Viewing as HTML (either original or simplified). Forward inline. Actual results: Forward inline includes only part of the message displayed when reading. In the attached example, only "PART 2". Expected results: Forward the whole message as displayed when reading. Root cause is probably that the HTML is invalid, being something like (yes, the first font tag never gets closed): <font> <p>FIRST PART</p> <html> <head> <title>bar</title> </head> <body> SECOND PART </body> </html> "Be liberal in what you accept". It is good that the broken HTML is displayed as intended by the author, although not conformant. However, to a naive user, a message that displays "correctly" but does not forward correctly is a bug in Thunderbird, however much you try to explain that the HTML is "invalid". Especially since a "reply" to the message _does_ include the whole message!
Attachment #545346 - Attachment mime type: application/octet-stream → message/rfc822
Blocks: multipartfailtracker
Keywords: testcase
Summary: forward inline of invalid HTML forwards only part of message → forward inline of invalid HTML forwards only part of message multipart/alternative;
Attachment #545346 - Attachment filename: 1310393559.14879_1.blitz:2,Sbc → 1310393559.14879_1.blitz2_Sbc.eml
For testcase1 of attachment 545346 [details], confirming this bug in TB: - HTML markup outside <HTML> tag "correctly" shown in msg reader (good) - However, same markup lost when forward inline - but preserved when reply -> Whatever we show in msg reader should not differ from what is forwarded inline or replied! -> ux-consistency
attachment 646549 [details] has a slightly different malformed testcase showing same symptoms
atm I can't find more dupes of this (not easy to search) -> confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Other → All
similar to / dupe of Bug 496723?
(In reply to Thomas D. from comment #5) HTML structure of ths bug's case is identical to following. HTML tags for <body> is added before <html> tag. So, <HTML>, <BODY> is complemented. <HTML> (complemented) <BODY> (complemented) <font> <p>FIRST PART</p> <html> <= changed to 2nd <html> tag <head><title>bar</title></head> <body>SECOND PART</body> </html> I think same problem as Bug 496723.
(In addition to comment #6) Above HTML/BODY complement is from perspective of html parser. This bug's case is; - tags like <p> before first <html ...> tag - first <html ...> tag is <html>(no attribute) Bug 496723 case is; - first <html ...> is <html xmlns...> or <html id="xxx"> (attribute is used) - additional <html> tag is written, and is <html>(no attribute) Problem may be "Forward inline searchs first <html>(no attriute)" and "Forward inline ignores elements before the first string of <html>(no attribute)", because following is observed in Bug 496723. - first html tag : <html xmls...> or <html id="xxx"> - second string of <html> is placed in HTML comment like <!-- AAA <html> BBB --> - even though the second string of <html> is comment string, body text of first <html ...> is ignored and "BBB -->" is shown by Forward. Setting dependency to bug 496723 instead of duping to avoid loss of "body elements before first <html>" case, although I think same cause.
Depends on: 496723
Summary: forward inline of invalid HTML forwards only part of message multipart/alternative; → forward inline of invalid HTML forwards only part of message (if HTML tag such as <p> for HTML body text is placed before <html> tag by mail sender, elements before <html> tag is discarded by Forward inline)
Attachment #545346 - Attachment mime type: message/rfc822 → text/plain
Comment #7 is mostly right. The system copies everything following the <html> tag into the forwarded message, so everything that goes before it is lost. OK, let's fix this in bug 394322.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: