User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 Steps to reproduce: The worst case: editing a reply mail in html mode. The worser than worst case: when me or the sender is in mode "text+html" The typical agravating situation is erasing the first character or space or newline of a text portion in a given attribute (text vs html, bold, fontsize), or deleting a range of lines of different attributes. Actual results: - Huge part of text change of attribute mode (sometime also suppressing all newlines which is horrible on item lists). - Some old memory of attribute mode popup when typing a character after a <- ou -> motion. - the levels of reply bars become incoherents (especially when trying to delete multiple newlines starting a section) - looking at the html source, dozens of useless <thing></thing> accumulates. Expected results: - delete a char or a range should delete and have no side effect on attributes before and after - typing a char and using <- or -> should not change the current attribute mode - deleting blancks should not change the indentation level of a reply bar

Sometime, even copy or paste is impossible at some locations (at the limit between paragraphs of different attributes or reply level.

you might check to see which of these issues still exists in beta from http://www.mozilla.org/en-US/thunderbird/channel/ Note, we typically only entertain one issue per bug report. Your comment 0 covers at least 3 issues. But if you put in a bug title that accurately describes one issue these a good chance it will recommend a matching existing bug report

Well, I'm not sure how to split in 3 independent issues. BTW I suspect they might have very near causes. Anyway if the html editor is fixed in the next update, it is cool !

fabrice, thanks for your bug report. However, as Wayne hinted, there's nothing much we can do about this unless you provide more details and restrict yourself to one item per bug. Right now, nobody can reproduce your problem because your steps to reproduce are not providing enough detail. We need step by step instructions: 1 type this... 2 press this movement key... 3 use ... key to delete this... > dozens of useless <thing></thing> accumulates. For a start, could you specify the name of those "<thing>" tags which you see accumulate in your source code? I suspect this is a duplicate of bug 812638. Fabrice, does bug 812638 cover your scenario?

no, there are no incorrect html tag, "just" wrong behavior especially when deleting portions of message, and useless accumulation of tags such as <big><big><big></big></big></big></big> or fonts (often nested).

Step by step desription of one case: 1: I reply with html composer to an plein text message. I see variable-fonted "MrX wrote" follown by its plain text quotation. ok. 2: I clic lect to the 1st quoted character and left delete. -> the whole quoted text with returns and 2bl lines breaks now become a unique wrapped variable-fonted text with no line break. I suspect the <pre wrap=""> that appeard in the source at this occasion. Also, <blockquote is still there but seems to have no effect.

Step by step description of case 2: 1: I reply with html composer to a text/html multipart message. (html: Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable) I see variable-fonted "MrX wrote" follown by its hst text quotation. ok. 2: I clic left to "Mr X" and select text (including part of the quote). 3: I copy-past elsewhere using CtrlV - CtrlC or right clic. NOTHING is copied. 4: Ctrl-X do delete the "mrX wrote" + part of select quotation. But the copy-past bug persists as long as the selection includes a quote begin or end. Here is a source exerp at the begining: <div class="moz-cite-prefix">Le 01/07/2013 15:33, MrX wrote :<br> </div> <blockquote cite="mid:1264690989.4407424.1372685591389.JavaMail.root@inria.fr" type="cite"> <style type="text/css">p { margin: 0; }</style> <div style="font-family: arial,helvetica,sans-serif; font-size: 12pt; color: #000000">Bonjour, <br> <br> - <i> text </i> text ..... and at the end: ...quoted text <span name="x"></span><br> </div> </div> </blockquote> <br> Thanks for your remark, X.

fabrice, thanks for providing more detail, that's helpful. Composition is a can of worms that nobody wants to touch, and it's not even fully in the realm of TB as it involves Editor component which I suspect might be another somewhat orphaned stepchild of Mozilla. At least some, perhaps all of what you report has already been filed in existing bug reports that are waiting for volunteers to fix them. (In reply to fabrice.neyret from comment #5) > no, there are no incorrect html tag, "just" wrong behavior especially when > deleting portions of message, and useless accumulation of tags such as > <big><big><big></big></big></big></big> or fonts (often nested). Good news: Bug 812638 has been fixed for the next release coming soon, TB24.

for problem of "failing to copy-paste involving partial quotes" we have a number of similar bugs that need consolidation: Bug 373374, bug 770895, bug 789569

(In reply to fabrice.neyret from comment #6) > Step by step desription of one case: > > 1: I reply with html composer to an plein text message. > I see variable-fonted "MrX wrote" follown by its plain text quotation. ok. > > 2: I clic lect to the 1st quoted character and left delete. > -> the whole quoted text with returns and 2bl lines breaks now become a > unique wrapped variable-fonted text with no line break. Example 1: When I place the cursor at the (*) in this text: | |(*) | | Old quoted text and press backspace once, it removes the line (as expected): |(*) | | Old quoted text When I press backspace again, nothing happens (though the cursor seems to move a pixel or so left and down). Press it a third time, and the line disappears as expected: | | Old quoted text Example 2: Placing the cursor at the (*) again in the following text: | blah blah :) | |(*) | | | | | Bar blah blah Pressing backspace does nothing but move the cursor down: | blah blah :) | | | |(*) | | | Bar blah blah Pressing backspace from there yields this, as expected: | blah blah :) | |(*) | | | Bar blah blah Pressing it again however: | blah blah | :)(*) | | Bar blah blah Note that the indentation of lower quote has decreased. Generally this happens when removing leading empty quoted text from this: | | | | | | | foo which will turn it into | | foo