Reply to message with text in floated <div> mishandles insertion of reply into quoted text

NEW
Unassigned

Status

MailNews Core
Composition
--
minor
12 years ago
3 years ago

People

(Reporter: Harlan Harris, Unassigned)

Tracking

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

Yahoo Groups updated their system a couple of months ago. Now, messages come formatted heavily in modern HTML, complete with DIVs and styles. Looks great, but it causes a problem when replying. If I put the cursor in the quoted text and press Enter, as if to add an in-line reply (splitting the quoted next), then start typing, my new text ends up in the righthand column, above the "new message search" box. That is, it appears that my new text is ending up in the wrong DIV. Top-posting and bottom-posting both work fine.

View... Message Body As... Simple HTML works around the problem.


Reproducible: Always

Steps to Reproduce:
1. Receive a message from a Yahoo Groups group, with full HTML whiz-bang enabled.
2. Reply, put the cursor in the middle of the quoted text, press Enter (critical to reproduce!), then start typing.
3.

Actual Results:  
Text ends up in a column to the right.

Expected Results:  
Quoted text should be split, and new typing should be in between the quoted text.

Comment 1

12 years ago
Can you provide a sample message?  Save it as a .EML file and attach it to this bug, using the Create New Attachment link above.
(Reporter)

Comment 2

12 years ago
Created attachment 238513 [details]
sample message to test this

Per mcow@well.com's request.

Comment 3

12 years ago
Definitely something wrong here.  Here's a rough schematic of the message from Yahoo:
  <body>
   <div id="ygrp-mlmsg" style="[...] position:relative;">
    <div id="ygrp-msg" style="[...] float:left;">

     <div id="ygrp-text">
       ACTUAL MESSAGE TEXT HERE
     </div>

     <span >__._,_.___</span>   <!-- OPENING SPAN -->

     <!-- BOILERPLATE: FOOTER:  well formed stuff, no floats -->
    </div>

    <div id="ygrp-sponsor" style="float: left; position:absolute; [...]">
     <!-- BOILERPLATE: RIGHT-HAND DIV: nothing special within -->
    </div>

   </div>
   <span >__._,_.___</span>     <!-- CLOSING SPAN -->
  </body>
  <head><style>[...]</style></head>

The two <span>s shown seem to be intended as points where all the boilerplate could be stripped out (like a sig-separator in plain-text mail); unfortunately, their placement within the document doesn't allow a straightforward cut, as it would remove the closing tags for those two outermost <div>s.

When we reply, the HTML structure of the reply wraps everything within a <blockquote> tag, and strips the <body>, </body>, <head> and </head> tags (leaving the <style> within the <blockquote> immediately following that closing <span>).

But the problem reported here is unrelated to any of that.  The problem is that 'float:left' on the 'ygrp-msg' <div> -- if that's removed, typing a line-break in the middle of the quoted paragraph behaves correctly.  Testcase coming up.
Status: UNCONFIRMED → NEW
Component: Message Compose Window → MailNews: Composition
Ever confirmed: true
OS: Linux → All
Product: Thunderbird → Core
Hardware: PC → All
Version: unspecified → Trunk

Comment 4

12 years ago
Created attachment 238690 [details]
Stripped down sample showing bug

Reproduced with TB 1.0.6, 1.5.0.7, 3a1-0912, and Seamonkey 1.5a-0817.

This a much easier set of data to deal with.  I've left the <span>s in place, but colored them green so they're visible, just to show how they fall within the layout.

Steps to reproduce:
1) Save this attachment to disk.
2) From the 3-pane, open it.
3) Cause a reply (as HTML; use Shift+Reply if default account normally plain).
3a) observe quote-bar next to message
4) Place caret at some point in the quoted text; type <Enter>
4a) observe location of caret now

If using Seamonkey, the following interesting extra test can be made:
5) Dismiss reply window; open another one
6) Select Insert|HTML; select all text within HTML edit window; copy
7) Open Composer window
8) Go to HTML Source tab; select the <br> within the <body> tags; paste
9) Switch back to Normal tab
10) Place cursor at point within the text; type <Enter>
10a) observe location of caret

Actual results:
3a) quote bar extends only as far as the second <span> (which appears to the right; the message body is floated to the left)
4a) caret jumps out of the message <div> to the right-hand side; the <span> shifts downward and caret is placed above it
10a) Caret remains where it's expected, within the quote text.

Expected results:
3a) quote bars run the length of the message
4a) Caret remains within quote text

Comment 5

12 years ago
The reason for the cursor shift is, when the <Enter> is typed, the blockquote gets split into two blockquotes:

<blockquote>
  <div style="float:left;">
     message text
  </div>
</blockquote>
 **** caret here ****
<blockquote>
  <div style="float:left;">
     message text
  </div>
  <span></span>
</blockquote>

Composer doesn't try to split the blockquote, it simply edits the message-text in place.  That's why this is mail-specific.

I don't know what can be done with this, other than stripping the 'float': generally, mail *should* be splitting the <blockquote>, and when it does so, the floated <div>s are going to look just as they do.
Summary: Reply to Yahoo Groups email (complex HTML) doesn't allow insertion of reply text into quoted text → Reply to message with text in floated <div> mishandles insertion of reply into quoted text
Assignee: mscott → nobody
QA Contact: message-compose → composition
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core

Comment 6

3 years ago
[Tracking Requested - why for this release]:
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.