590640 - Editor loses type-in state when injecting some elements

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[(no longer active)]

STR:

1. Open the midas demo page.
2. Set the font size to 7.
3. Type something.
4. Create a list and then type something.
5. Press Enter twice and then type something.

The text entered in steps 4 and 5 is not in font size 7.  The editor is somehow losing the type-in state when injecting the list element.

This is one of the biggest pain points with the HTML editor.

The respective Thunderbird bug is bug 250539.

Comment 1

[David Ascher (:davida)]

afaik this is not mac only.

Comment 2

[(no longer active)]

Other possibly related bugs:

MailNews Core
bug 203810
bug 250539

Thunderbird
bug 514265
bug 536613

Comment 3

[(no longer active)]

Attachment: WIP 1: works for list insertions

So, here's a first stab at this.  This patch works for list element insertion, and is sort of straightforward to extend to other operations.  But it needs more testing to make sure that I'm not breaking anything.  I just ran the editor tests on this patch, and they passed successfully.

Comment 4

[David Ascher (:davida)]

Ehsan, awesome!  I realize I'm jumping the gun a bit and you're not claiming the patch is ready, but do you have any opinion yet about the technical reasonableness of backporting this to 1.9.2?  This bug affects a lot of TB 3.x users, and I'd like to understand the various parameters involved in getting this out in a TB 3.1.x build (whether the patch applies to 1.9.2; what the risk profile is for a backport; whether m-c is receptive to this as a bug-fix; etc.)

Comment 5

[(no longer active)]

(In reply to comment #4)
> Ehsan, awesome!  I realize I'm jumping the gun a bit and you're not claiming
> the patch is ready, but do you have any opinion yet about the technical
> reasonableness of backporting this to 1.9.2?  This bug affects a lot of TB 3.x
> users, and I'd like to understand the various parameters involved in getting
> this out in a TB 3.1.x build (whether the patch applies to 1.9.2; what the risk
> profile is for a backport; whether m-c is receptive to this as a bug-fix; etc.)

This will not be safe to backport to 1.9.2, because it changes the way that the HTML editor works fundamentally.  Even though I believe that this change is in a positive direction, it has the potential of breaking a lot of editor widgets (such as CKEditor).

However, I think it's possible to backport it for Thunderbird use only.  I don't know if Thunderbird's build system can apply patches to the mozilla/ directory before building, but if not, we can land a version of this patch which is #ifdef'ed out for Firefox, and enabled for Thunderbird.

Anyway, hope is on the horizon!  :-)

Comment 6

[Massimo Fidanza]

But breaking editor widgets will be a problem for who, during those days, are working in parallel on an alien editor integration. Please refer to this bug
https://bugzilla.mozilla.org/show_bug.cgi?id=539299

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> But breaking editor widgets will be a problem for who, during those days, are
> working in parallel on an alien editor integration. Please refer to this bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=539299

That is not an issue. We are working together and experimenting with different things.

Comment 8

[Massimo Fidanza]

And this is a good thing.

Thank you!
Massimo

Comment 9

[beckreck]

This bug is not just for inserting lists.  it happens in typing anything longer than a sentence or two. The font chosen in options does not "stick".  The font reverts back to variable width, then you need to backspace to the last letter typed to sort of pick up the font again.I am so glad someone is finally looking at this. It is a real problem in TB.

Comment 10

[maybe-the-one]

The bug will occur after ANY action that moves the cursor except typing a character.  The problem is that your typing point (^) is just before a hidden end-font tag
^</font>

When you move the cursor (even if you return to the same character position, say by mouse click), you are placed AFTER the end-font tag, 
</font>^
and the editor is thus switched to the default font (Variable Width) at that point.

Comment 11

[Phillip M. Jones, C.E.T.]

The above bug as described also applies to SM2.0.x has existed since SM2 came on market

Comment 12

[Massimo Fidanza]

I think that this bug will never get solved. After getting some attention back
in august and september, now everything is again sleeping.
Work Jonathan Protzenko is at a standstill since September 10
https://github.com/protz/Compose --
https://bugzilla.mozilla.org/show_bug.cgi?id=539299
And the same happen to Ehsan Akhgari
https://bugzilla.mozilla.org/show_bug.cgi?id=590640

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

Malix, as I've said in both bug 539299 and bug 250539, while your frustration may be valid as a feeling, using Bugzilla as a place to vent is not.  This is in large part because it's very demotivating for the small number of people who both have the technical skill to do the work and are generous enough to consider donating their time. 

Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before commenting further in Bugzilla bugs.

Comment 14

[Massimo Fidanza]

Dan, I don't make only negative comments. In the past I help to fix a bug https://bugzilla.mozilla.org/show_bug.cgi?id=311956. But this bug is realy annoying and got attention last time that more people are commenting, now is again sleeping. What happened to Ehsan Akhgari patch? Has someone made a test to it? How  can we test it? Is this patch breaking the CKEditor? Mark Banner https://bugzilla.mozilla.org/show_bug.cgi#c7 said that you are esperimenting togather but we have no feedback. How we can know the overall progress of the fix? I try the Jonathan Protzenko extension but this completely replace the editor and I lose all the standard functionality, for me this is not acceptable.

Comment 15

[Massimo Fidanza]

Hi,

again me, I come in Peace this time and I really like that this bug will be definiteli solved before next release of Thunderbird. Did someone did a test on this patch? If so can he post feedback to Ehsan.

Massimo

(In reply to comment #3)
> Created attachment 471667 [details] [diff] [review]
> WIP 1: works for list insertions
> 
> So, here's a first stab at this.  This patch works for list element insertion,
> and is sort of straightforward to extend to other operations.  But it needs
> more testing to make sure that I'm not breaking anything.  I just ran the
> editor tests on this patch, and they passed successfully.

Comment 16

[Jonathan Protzenko [:protz]]

I've uploaded a try-server build that should complete in at most 4 hours. For people interested in trying the fix Ehsan kindly provided, please head over to http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tryserver-builds/[e-mail]-2d43c61682d5 in a few hours and give these versions a try. We'd love to hear about your feedback!

Comment 17

[Massimo Fidanza]

Thanks a lot Jonathan,

I will try this when it's ready.

(In reply to comment #16)
> I've uploaded a try-server build that should complete in at most 4 hours. For
> people interested in trying the fix Ehsan kindly provided, please head over to
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tryserver-builds/[e-mail]-2d43c61682d5
> in a few hours and give these versions a try. We'd love to hear about your
> feedback!

Comment 18

[Massimo Fidanza]

Attachment: Shredder Test with Ehsan Akhgari patch.eml email

This email is intended to test Shredder + Ehsan Akhgari patch 471667 (https://bug590640.bugzilla.mozilla.org/attachment.cgi?id=471667)

Comment 19

[Massimo Fidanza]

Has promised I try Shredder + Ehsan patch. Now the dotted and numbered list are working good and my defult font is applied, but when I press 2 times return and leave list the Variable With font is restored :-(. The same things happen if I use a table (inside table the Variable With font is used).
Jonathan I want to try your extension https://addons.mozilla.org/en-US/thunderbird/addon/compose-for-thunderbird/, but I'm not able to install it.

In the last post I attached the email that I send to myself for testing.

Good job, but more work is needed.

PS: Jonathan if you republish the extension compatible with last version of Shredder or help me if I'm in trouble I will try if Ehsan patch introduce regession

(In reply to comment #17)
> Thanks a lot Jonathan,
> 
> I will try this when it's ready.
> 
> (In reply to comment #16)
> > I've uploaded a try-server build that should complete in at most 4 hours. For
> > people interested in trying the fix Ehsan kindly provided, please head over to
> > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tryserver-builds/[e-mail]-2d43c61682d5
> > in a few hours and give these versions a try. We'd love to hear about your
> > feedback!

Comment 20

[johnfull]

This has been very frustrating for users of SeaMonkey as well.
We had a perfectly competent mail composer up through SM 1.9x.
With version SM 2.0, we had to begin switching to Thunderbird 
code in order to stay current with security updates. This sad
event marked the beginning of the trouble for us and we see that
it has been a problem at TrdBrd almost since its inception.
Is there a way for TrdBrd to go back to SeaMonkey 1.9 and start 
anew with the code that worked there? Why did this problem slip 
into the code and get crunched with ToolKit shortcuts to the point
that it can't be teased out and addressed? I'm not technically 
competent, but I can say that you have ruined the mail composer.
We users of SeaMonkey regret throwing our lot in with you.
Which is not to be negative. My positive suggestion is to re-write
the code, based on SeaMonkey's final 1.9x iteration. It's not been
that long ago and applying security fixes to it shouldn't be a big
issue. We don't see large differences in TrdBrd from what we had 
with Netscape/Mozilla/SM1x. TrdBrd doesn't seem to have been a large
divergence away from the integrated suits as much as Firefox. Pleas
consider going back and getting it right. Thank you!

Comment 21

[Ludovic Hirlimann [:Usul]]

Ehsan is that the same bug as 250539 ?

Comment 22

[johnfull]

Seems to be -- is that significant?

Comment 23

[(no longer active)]

(In reply to Ludovic Hirlimann [:Usul] from comment #21)
> Ehsan is that the same bug as 250539 ?

Yes, except that it doesn't have hundreds of useless comments which makes it impossible for somebody who's willing to work on this bug focus on this.

Comment 24

[WOLF_THUNDER]

Nobody is willing to work on it no matter what bug number it is filed under, and all new bug reports related to this get folded into 250539.... hence the hundreds of comments on 250539 after 7.5 years.  People want the composer to actually work right, go figure.

Comment 25

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

(In reply to Ehsan Akhgari [:ehsan] from comment #5)
> This will not be safe to backport to 1.9.2, because it changes the way that
> the HTML editor works fundamentally.  Even though I believe that this change
> is in a positive direction, it has the potential of breaking a lot of editor
> widgets (such as CKEditor).

What type of breakage would you expect?  The code looks simple enough to me.  If you want me to work on this, could you tell me the sort of thing you want me to test?  I'd think some risk of breakage on nightlies is worth it, given the pain a lot of users seem to be going through . . .

FWIW, the editing spec currently says to preserve overrides (typein state) for the following commands: insert*List, justify*, formatBlock, indent, outdent.

Comment 26

[(no longer active)]

(In reply to Aryeh Gregor from comment #25)
> (In reply to Ehsan Akhgari [:ehsan] from comment #5)
> > This will not be safe to backport to 1.9.2, because it changes the way that
> > the HTML editor works fundamentally.  Even though I believe that this change
> > is in a positive direction, it has the potential of breaking a lot of editor
> > widgets (such as CKEditor).
> 
> What type of breakage would you expect?  The code looks simple enough to me.
> If you want me to work on this, could you tell me the sort of thing you want
> me to test?  I'd think some risk of breakage on nightlies is worth it, given
> the pain a lot of users seem to be going through . . .

I was specifically talking about the possibility of any patch here being backported to 1.9.2, which is soon to be dead, so this is no longer relevant.

To answer your question, I am not worried about anything in particular here, except for the usual possibility of regressions caused by changes, but that's a usual risk.  So I will happily take a patch for this on Nightly.  :-)

> FWIW, the editing spec currently says to preserve overrides (typein state)
> for the following commands: insert*List, justify*, formatBlock, indent,
> outdent.

That makes sense.

Comment 27

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Oops -- didn't notice your reply because I wasn't CC'd.  I'll work on this now.

Comment 28

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

So the patch kind of works, when I modify it a bit, but not exactly the way we want.  For one thing, it seems to be adding empty tags like <b></b> to the DOM.  But the general approach is probably right; I expect to have something ready in not too long.  The editing spec tests test for this.

Comment 29

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

So I have a patch basically working that gets rid of the problem where empty tags like <b> get inserted, and fixes a bunch of expected fails in its own right.  But it causes some regressions too, which I have to work on fixing before I can submit it.  Once that's fixed, I can go back to the actual bug in question here.  No ETA, but I'm working on it . . .

Comment 30

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 1, v1 -- Clean up some nsHTMLEditRules methods

So I have some patches ready that don't fix this bug, but should make it easier to fix without regressions.  Along the way, they fix some other bugs.  First some obligatory cleanup patches, though!

Comment 31

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 2, v1 -- Remove dead code

-#ifdef XXX_DEAD_CODE

srsly, editor/.

Comment 32

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 3, v1 -- Remove unnecessary use of NodeIsTypeString

I'm pretty sure the comment explaining this usage is bogus -- tell me if it's not!

Comment 33

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 4, v1 -- Print out testharness.js test name on fails as well as passes

This just makes debugging unexpected fails easier.

Comment 34

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 623488 [details] [diff] [review]
Patch part 4, v1 -- Print out testharness.js test name on fails as well as passes

Are we guaranteed that test.name is a string? Looks good if that's the case.

Comment 35

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 5, v1 -- Delete empty wrappers when we delete the selection

Okay, now this one is a little scarier than usual -- although as you can see, it fixes a bunch of expected fails (one isn't even in richtext/editing spec tests, too!).  The issue is that as it stands, Gecko will sometimes leave empty inline tags lying around in the DOM after doing a deletion.  E.g., if you have "foo <span>bar</span> baz" and you select "bar" and hit delete, <span></span> is left.  This is bad.

The reason for most of the complication in this patch is that in a few cases, we do want to keep empty inline wrappers when deleting -- specifically, when we're inserting new inline content right away, like text or an image.  The way I dealt with this is adding extra aStripWrappers parameters in various places.  This is ugly and horrible, because there are three different deletion-related methods that are implemented across four classes, and I have to update lots of callers and the calls are uglier.  If you can suggest a better way to do this, feel free!  Because this way is horrible.  :(

I pass aStripWrappers = false only in the insertImage case for now, because that's necessary to avoid regressions on the editing spec tests.  It should probably also be passed for text insertion.

Comment 36

[Jeff Hammel]

Comment on attachment 623488 [details] [diff] [review]
Patch part 4, v1 -- Print out testharness.js test name on fails as well as passes

What Ms2ger said, though iirc test.name *should* be defined for existing cases (though I realize this is an awfully big should, though a try run would ease my mind).  Does this need to be upstreamed?

Comment 37

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

No -- testharnessreport.js is an empty file upstream, and is specifically meant to be used only for downstream modification.  testharness.js is where the upstream code lives.

I just looked at testharness.js, and test.name is filled in by the Test constructor.  testharness.js itself uses it as a string in output: "escape_html(tests[i].name)".  In theory it looks like you could do something like

  test(function() {}, ["I'm an array instead of a string!"])

and it would wind up being test.name, since nothing specifically checks that it's a string, but that's life in a dynamically typed language.

Comment 38

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 6, v1 -- Don't create empty style tags unless we're about to insert text in them

This avoids more empty tags in the DOM.  We should only insert empty tags to reflect the type-in state when inserting text, but CreateStyleForInsertText was being called by WillInsert, which in turn is called by lots of things.  I changed it so that CreateStyleForInsertText is called only by WillInsertText, and moved the part that deals with cached styles (rather than type-in state) into WillInsert so it's still hit.  (CreateStyleForInsertText was only called by WillInsert.)

This caused one regression: DoInsertHTMLWithContext was calling RemoveAllInlineProperties, which only sets type-in state and relies on CreateStyleForInsertText to do the actual removing.  So I factored out the part of CreateStyleForInsertText that actually removes styles into a new ClearStyle method, and called it from both places.

Comment 39

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 7, v1 -- Preserve type-in state when performing block commands

With this patch, the test-case from comment #0 is fixed.  I admit I'm not totally clear on how much of the patch is actually necessary, but it works.

Previously, ReapplyCachedStyles was clearing type-in state before doing anything.  I don't know why it was doing that, but this patch calls ReapplyCachedStyles in a bunch more cases, and clearing type-in state in those cases caused regressions -- we wanted to preserve it.  So I removed those lines, and it seems to be okay.

You'll notice that there are no test updates for this patch.  The tests that I expected it to fix actually got fixed by the last patch.  I plan to update the editing spec to add some more tests that this patch actually should fix, namely preservation of style before/after insertparagraph.  When we fix bug 748306 and bug 748307 (support insertParagraph/insertText per spec), those tests should test for regressions here.

Comment 40

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Try: <https://tbpl.mozilla.org/?tree=Try&rev=5b058bd6f2ef>.  Expect debug build timeouts from the bug 751842 patches, since I haven't fixed them yet (see that bug for details).

Comment 41

[maybe-the-one]

Does this fix also fix the issue of:

1.  be typing
2. move cursor somewhere above the typing point (e.g. to insert test within previous words)
3. move cursor back to end of last line
4. Result: font changes to variable width because the replacement of cursor at the end of the line has moved it outside the [/ font ] tag.

?

Comment 42

[maybe-the-one]

/s/insert test/insert text/

Comment 43

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 623610 [details] [diff] [review]
Patch part 7, v1 -- Preserve type-in state when performing block commands

Review of attachment 623610 [details] [diff] [review]:
-----------------------------------------------------------------

::: editor/libeditor/html/nsHTMLEditRules.cpp
@@ +348,5 @@
>  
>      // remember current inline styles for deletion and normal insertion operations
> +    if (action == nsEditor::kOpInsertText ||
> +        action == nsEditor::kOpInsertIMEText ||
> +        action == nsEditor::kOpDeleteSelection ||

These three seem to be used together as well; followup patch for a helper function, maybe?

Comment 44

[(no longer active)]

Comment on attachment 623485 [details] [diff] [review]
Patch part 1, v1 -- Clean up some nsHTMLEditRules methods

Review of attachment 623485 [details] [diff] [review]:
-----------------------------------------------------------------

::: editor/libeditor/html/nsHTMLEditRules.cpp
@@ +2972,2 @@
>      itemType = *aItemType;
> +  } else if (aListType->LowerCaseEqualsLiteral("dl")) {

Please use the atom instead of string comparison here.

@@ +3150,3 @@
>            curList = curParent;
> +        } else {
> +          if (curParent != curList) {

Nit: else if!

Comment 45

[(no longer active)]

Comment on attachment 623487 [details] [diff] [review]
Patch part 3, v1 -- Remove unnecessary use of NodeIsTypeString

Review of attachment 623487 [details] [diff] [review]:
-----------------------------------------------------------------

This comment is from the bronze age, thanks for not believing it.  :-)

Comment 46

[(no longer active)]

Comment on attachment 623489 [details] [diff] [review]
Patch part 5, v1 -- Delete empty wrappers when we delete the selection

Review of attachment 623489 [details] [diff] [review]:
-----------------------------------------------------------------

The patch looks generally good.  The fact that we need to propagate aStripWrappers all around the code is unfortunate, but there is no easy way around it.  I'm clearing the review request mostly because I'd like to look at the next version of this patch.

::: editor/libeditor/base/nsEditor.cpp
@@ +624,5 @@
> +nsresult
> +nsEditor::DeleteSelection(EDirection aAction, bool aStripWrappers)
> +{
> +  return DeleteSelectionImpl(aAction, aStripWrappers);
> +}

This will change based on my comments on the header...

@@ +654,5 @@
> +  res = selPrivate->GetFrameSelection(getter_AddRefs(frameSel));
> +  NS_ENSURE_SUCCESS(res, nsnull);
> +
> +  return frameSel->GetSelection(nsISelectionController::SELECTION_NORMAL);
> +}

Hmm, I have serious doubts on this function...

::: editor/libeditor/base/nsEditor.h
@@ +206,5 @@
>                                        PRInt32 aOffset,
>                                        bool aSuppressIME = false);
> +  nsresult DeleteSelection(EDirection aAction, bool aStripWrappers);
> +  NS_IMETHOD DeleteSelectionImpl(EDirection aAction,
> +                                 bool aStripWrappers = true);

I'm not a huge fan of default arguments in these types of contexts, since it makes it very easy for the caller to assume the wrong thing when calling this function.  Please make the second arg to DeleteSelecitonImpl explicit.

Also, DeleteSelection is also defined in nsIEditor, and this masks the base class definition, and it also makes it easy for nsIEditor consumers to do the wrong thing.  Please remove DeleteSelection here, and add a bool arg to the version defined in nsIEditor, while changing its IID.

Also, using booleans for this kind of thing is bad API design.  (What does true here mean, was the arg aStripWrappers or aSkipStrippingWrappers?)  Please add an enum with two named values, and in the implementation use MOZ_ASSERT to catch callers which violate the pretty weak enum type safety guarantees of C++.  :-)

@@ +626,1 @@
>  

Hmm, nsTypedSelection is an implementation detail (and there is no nsTypedSelection.h as far as I can see).  Why do we want to use an internal class here, and how does this compile?!

::: editor/libeditor/html/nsHTMLEditRules.h
@@ +154,5 @@
>    nsresult SplitMailCites(nsISelection *aSelection, bool aPlaintext, bool *aHandled);
>    nsresult WillDeleteSelection(nsISelection *aSelection, nsIEditor::EDirection aAction, 
>                                 bool *aCancel, bool *aHandled);
> +  nsresult WillDeleteSelection(nsISelection* aSelection, nsIEditor::EDirection aAction,
> +                               bool aStripWrappers, bool* aCancel, bool* aHandled);

Please remove the version of WillDeleteSelection which does not accept aStripWrappers.

::: editor/libeditor/html/nsHTMLEditor.cpp
@@ +1761,5 @@
> +        // E.g., inserting an image.  In this case we don't need to delete any
> +        // inline wrappers before we do the insertion.  Otherwise we let
> +        // DeleteSelectionAndPrepareToCreateNode do the deletion for us, which
> +        // calls DeleteSelection with aStripWrappers defaulting to true.
> +        res = DeleteSelection(nsIEditor::eNone, /* aStripWrappers */ false);

This is a problem which you could avoid by using an enum...

@@ +3475,5 @@
> +
> +  nsRefPtr<nsTypedSelection> typedSel = GetTypedSelection();
> +  NS_ENSURE_STATE(typedSel);
> +  NS_ENSURE_STATE(typedSel->GetAnchorFocusRange());
> +  NS_ENSURE_STATE(typedSel->GetAnchorFocusRange()->Collapsed());

Hmm, I'm not sure what you're trying to do here.  Couldn't you just check to see if the selection is collapsed?

@@ +3499,5 @@
> +    nsCOMPtr<nsIContent> parent = content->GetParent();
> +    res = DeleteNode(content);
> +    NS_ENSURE_SUCCESS(res, res);
> +    content = parent;
> +  }

Hmm, why do you need to delete each node individually?  Why not find the top-most node and delete that in one go?

::: editor/libeditor/html/nsHTMLEditor.h
@@ +326,5 @@
>    NS_IMETHOD CollapseAdjacentTextNodes(nsIDOMRange *aInRange);
>  
>    virtual bool NodesSameType(nsIDOMNode *aNode1, nsIDOMNode *aNode2);
>  
> +  NS_IMETHODIMP DeleteSelectionImpl(EDirection aAction, bool aStripWrappers);

NS_IMETHODIMP is supposed to be used in the implementation files, really.  Please just use NS_IMETHOD.

::: editor/libeditor/text/nsPlaintextEditor.h
@@ +103,5 @@
>    NS_IMETHOD GetIsDocumentEditable(bool *aIsDocumentEditable);
>  
> +  NS_IMETHOD DeleteSelection(EDirection aAction) MOZ_OVERRIDE;
> +  nsresult DeleteSelection(EDirection aAction,
> +                           bool aStripWrappers) MOZ_OVERRIDE;

This will need to be changed as well.

Comment 47

[(no longer active)]

Comment on attachment 623609 [details] [diff] [review]
Patch part 6, v1 -- Don't create empty style tags unless we're about to insert text in them

Review of attachment 623609 [details] [diff] [review]:
-----------------------------------------------------------------

::: editor/libeditor/html/nsHTMLEditRules.cpp
@@ +1263,5 @@
>        NS_ENSURE_SUCCESS(res, res);
>      }
>    }
>  
> +  // if we deleted selection then also for cached styles

Nit: there seems to be a verb missing from this sentence. :-)

::: editor/libeditor/html/nsHTMLEditorStyle.cpp
@@ +634,5 @@
> +  nsresult res = SplitStyleAbovePoint(aNode, aOffset, aProperty, aAttribute,
> +                                      address_of(leftNode),
> +                                      address_of(rightNode));
> +  NS_ENSURE_SUCCESS(res, res);
> +  bool bIsEmptyNode;

Declaring the variable here is deceptive (it tricked me into thinking that it might get used before being initialized).  Please move it to right before each of the IsEmptyNode calls.

Comment 48

[(no longer active)]

Comment on attachment 623610 [details] [diff] [review]
Patch part 7, v1 -- Preserve type-in state when performing block commands

Review of attachment 623610 [details] [diff] [review]:
-----------------------------------------------------------------

::: editor/libeditor/html/nsHTMLEditRules.cpp
@@ +118,5 @@
> +         action == nsEditor::kOpIndent ||
> +         action == nsEditor::kOpOutdent ||
> +         action == nsEditor::kOpAlign ||
> +         action == nsEditor::kOpMakeBasicBlock ||
> +         action == nsEditor::kOpRemoveList;

Why exclude kOpMakeDefListItem?  What about kOpInsertQuotation or kOpInsertElement?

Comment 49

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to Ehsan Akhgari [:ehsan] from comment #46)
> @@ +626,1 @@
> >  
> 
> Hmm, nsTypedSelection is an implementation detail (and there is no
> nsTypedSelection.h as far as I can see).  Why do we want to use an internal
> class here, and how does this compile?!

Yes; bug 693933.

Comment 50

[(no longer active)]

Try build of Thunderbird with these patches: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=cfbff0d89f98

Comment 51

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

(In reply to maybe-the-one from comment #41)
> Does this fix also fix the issue of:
> 
> 1.  be typing
> 2. move cursor somewhere above the typing point (e.g. to insert test within
> previous words)
> 3. move cursor back to end of last line
> 4. Result: font changes to variable width because the replacement of cursor
> at the end of the line has moved it outside the [/ font ] tag.
> 
> ?

Nope, that's a separate bug.  Please feel free to file it, if it's not filed already.

(In reply to Ms2ger from comment #43)
> ::: editor/libeditor/html/nsHTMLEditRules.cpp
> @@ +348,5 @@
> >  
> >      // remember current inline styles for deletion and normal insertion operations
> > +    if (action == nsEditor::kOpInsertText ||
> > +        action == nsEditor::kOpInsertIMEText ||
> > +        action == nsEditor::kOpDeleteSelection ||
> 
> These three seem to be used together as well; followup patch for a helper
> function, maybe?

Feel free to write one.  :)

(In reply to Ehsan Akhgari [:ehsan] from comment #46)
> The patch looks generally good.  The fact that we need to propagate
> aStripWrappers all around the code is unfortunate, but there is no easy way
> around it.  I'm clearing the review request mostly because I'd like to look
> at the next version of this patch.

Yeah, I figured this one deserved some flak.  :)  I'll see if I can submit a new version tomorrow.  FWIW, my use of MOZ_OVERRIDE caused a build failure on Windows, since the Windows tinderboxen actually support MOZ_OVERRIDE and my local compiler doesn't (oops).

> Hmm, nsTypedSelection is an implementation detail (and there is no
> nsTypedSelection.h as far as I can see).  Why do we want to use an internal
> class here, and how does this compile?!

This is based on bug 693933, which hasn't landed yet.  Basically I use it because nsISelection is horrible, COM-style.  In fact, editor/ has a ton of methods whose sole purpose in life is to work around the terrible COM APIs.  I dunno why bug 693933 exposed nsTypedSelection instead of making some new interface or whatever that exposed the same stuff, but anyway, I use it because it doesn't make my eyes bleed, unlike nsISelection.  Much like nsINode vs. nsIDOMNode.

> @@ +3475,5 @@
> > +
> > +  nsRefPtr<nsTypedSelection> typedSel = GetTypedSelection();
> > +  NS_ENSURE_STATE(typedSel);
> > +  NS_ENSURE_STATE(typedSel->GetAnchorFocusRange());
> > +  NS_ENSURE_STATE(typedSel->GetAnchorFocusRange()->Collapsed());
> 
> Hmm, I'm not sure what you're trying to do here.  Couldn't you just check to
> see if the selection is collapsed?

An earlier version of the patch actually did that, but it turns out it does the wrong thing if there are multiple ranges in the selection (surprise!).  It caused a test regression.  I probably should have noted this in a comment; by now I forget what the test was.  It called addRange() repeatedly without removeRange() and assumed that the earlier added ranges would have no effect, something like that.  If you want, I can try changing it back and see what breaks.

(In reply to Ehsan Akhgari [:ehsan] from comment #47)
> ::: editor/libeditor/html/nsHTMLEditRules.cpp
> @@ +1263,5 @@
> >        NS_ENSURE_SUCCESS(res, res);
> >      }
> >    }
> >  
> > +  // if we deleted selection then also for cached styles
> 
> Nit: there seems to be a verb missing from this sentence. :-)

Beats me what it is -- I was just copying it from elsewhere.  I'll just delete the comment, since I'm not sure what it adds.

> ::: editor/libeditor/html/nsHTMLEditorStyle.cpp
> @@ +634,5 @@
> > +  nsresult res = SplitStyleAbovePoint(aNode, aOffset, aProperty, aAttribute,
> > +                                      address_of(leftNode),
> > +                                      address_of(rightNode));
> > +  NS_ENSURE_SUCCESS(res, res);
> > +  bool bIsEmptyNode;
> 
> Declaring the variable here is deceptive (it tricked me into thinking that
> it might get used before being initialized).  Please move it to right before
> each of the IsEmptyNode calls.

It *is* right before the first IsEmptyNode call, just not in the same block because I use it in later blocks too.  Would you prefer multiple separate variable declarations in different blocks with the same name?  (What I'd prefer is an IsEmptyNode that returns bool instead of nsresult . . .)

(FWIW, this entire block of code was just moved from elsewhere, so I didn't write it to start with.)

(In reply to Ehsan Akhgari [:ehsan] from comment #48)
> Why exclude kOpMakeDefListItem?  What about kOpInsertQuotation or
> kOpInsertElement?

Because I was basing it on the spec.  The first two of those don't exist in the spec at all, and I'm not sure what they do, or whether they're accessible from execCommand().  The last doesn't correspond to one particular command -- it's used for insertHTML plus insertImage plus insertHorizontalRule IIRC? -- but I don't think the spec says to preserve styles for them.  Maybe the spec is wrong, though.  I noticed it doesn't say to preserve styles for insertParagraph (= Enter), which is definitely wrong.

Can you give me specific webpage-runnable JavaScript that you think my patch might not behave correctly for?  I want to make sure that the spec and spec tests cover this, and that the spec is right and we match the spec.  If kOpMakeDefListItem and/or kOpInsertQuotation aren't web-accessible, then I'm happy to add them if you want them, doesn't matter to me either way.

Comment 52

[WOLF_THUNDER]

(In reply to Aryeh Gregor from comment #51)
> (In reply to maybe-the-one from comment #41)
> > Does this fix also fix the issue of:
> > 
> > 1.  be typing
> > 2. move cursor somewhere above the typing point (e.g. to insert test within
> > previous words)
> > 3. move cursor back to end of last line
> > 4. Result: font changes to variable width because the replacement of cursor
> > at the end of the line has moved it outside the [/ font ] tag.
> > 
> > ?
> 
> Nope, that's a separate bug.  Please feel free to file it, if it's not filed
> already.
> 


Actually, that is this bug.  Any bug filed regarding font switching style to variable width got sent here.  That is the biggest issue of composing HTML emails in Thunderbird.  The font will not stay the same style if you move the focus and then go back to where you were.  Is that still, after over 7 years, not getting fixed?

Comment 53

[(no longer active)]

(In reply to Aryeh Gregor from comment #51)
> (In reply to Ehsan Akhgari [:ehsan] from comment #46)
> > The patch looks generally good.  The fact that we need to propagate
> > aStripWrappers all around the code is unfortunate, but there is no easy way
> > around it.  I'm clearing the review request mostly because I'd like to look
> > at the next version of this patch.
> 
> Yeah, I figured this one deserved some flak.  :)  I'll see if I can submit a
> new version tomorrow.  FWIW, my use of MOZ_OVERRIDE caused a build failure
> on Windows, since the Windows tinderboxen actually support MOZ_OVERRIDE and
> my local compiler doesn't (oops).

What compiler do you use?  (Hint: you really wanna use clang for local development)

> > Hmm, nsTypedSelection is an implementation detail (and there is no
> > nsTypedSelection.h as far as I can see).  Why do we want to use an internal
> > class here, and how does this compile?!
> 
> This is based on bug 693933, which hasn't landed yet.  Basically I use it
> because nsISelection is horrible, COM-style.  In fact, editor/ has a ton of
> methods whose sole purpose in life is to work around the terrible COM APIs. 
> I dunno why bug 693933 exposed nsTypedSelection instead of making some new
> interface or whatever that exposed the same stuff, but anyway, I use it
> because it doesn't make my eyes bleed, unlike nsISelection.  Much like
> nsINode vs. nsIDOMNode.

Oh, OK, then this is fine.

> > @@ +3475,5 @@
> > > +
> > > +  nsRefPtr<nsTypedSelection> typedSel = GetTypedSelection();
> > > +  NS_ENSURE_STATE(typedSel);
> > > +  NS_ENSURE_STATE(typedSel->GetAnchorFocusRange());
> > > +  NS_ENSURE_STATE(typedSel->GetAnchorFocusRange()->Collapsed());
> > 
> > Hmm, I'm not sure what you're trying to do here.  Couldn't you just check to
> > see if the selection is collapsed?
> 
> An earlier version of the patch actually did that, but it turns out it does
> the wrong thing if there are multiple ranges in the selection (surprise!). 
> It caused a test regression.  I probably should have noted this in a
> comment; by now I forget what the test was.  It called addRange() repeatedly
> without removeRange() and assumed that the earlier added ranges would have
> no effect, something like that.  If you want, I can try changing it back and
> see what breaks.

No, but just add a comment to say that this is done to make sure the right thing happens with multi-range selections.

> > ::: editor/libeditor/html/nsHTMLEditorStyle.cpp
> > @@ +634,5 @@
> > > +  nsresult res = SplitStyleAbovePoint(aNode, aOffset, aProperty, aAttribute,
> > > +                                      address_of(leftNode),
> > > +                                      address_of(rightNode));
> > > +  NS_ENSURE_SUCCESS(res, res);
> > > +  bool bIsEmptyNode;
> > 
> > Declaring the variable here is deceptive (it tricked me into thinking that
> > it might get used before being initialized).  Please move it to right before
> > each of the IsEmptyNode calls.
> 
> It *is* right before the first IsEmptyNode call, just not in the same block
> because I use it in later blocks too.  Would you prefer multiple separate
> variable declarations in different blocks with the same name?

Yes, that is what I meant!

> (What I'd
> prefer is an IsEmptyNode that returns bool instead of nsresult . . .)

Yes, a thousand times!  Maybe Ms2ger would be willing to do that at some point?  :)

> (FWIW, this entire block of code was just moved from elsewhere, so I didn't
> write it to start with.)

Yeah, consider my review comments as the punishment for a good deed.  ;-)

> (In reply to Ehsan Akhgari [:ehsan] from comment #48)
> > Why exclude kOpMakeDefListItem?  What about kOpInsertQuotation or
> > kOpInsertElement?
> 
> Because I was basing it on the spec.  The first two of those don't exist in
> the spec at all, and I'm not sure what they do, or whether they're
> accessible from execCommand().

kOpMakeDefListItem gets invoked for things like formatBlock with "dt", and also for cmd_dd and cmd_dt which are used in comm-central.

kOpInsertQuotation is used in Thunderbird (see nsPasteQuotationCommand).

> The last doesn't correspond to one
> particular command -- it's used for insertHTML plus insertImage plus
> insertHorizontalRule IIRC? -- but I don't think the spec says to preserve
> styles for them.  Maybe the spec is wrong, though.  I noticed it doesn't say
> to preserve styles for insertParagraph (= Enter), which is definitely wrong.

Yes, I believe that the spec should be changed to include those commands as well.

> Can you give me specific webpage-runnable JavaScript that you think my patch
> might not behave correctly for?  I want to make sure that the spec and spec
> tests cover this, and that the spec is right and we match the spec.  If
> kOpMakeDefListItem and/or kOpInsertQuotation aren't web-accessible, then I'm
> happy to add them if you want them, doesn't matter to me either way.

Sure, use formatBlock with "dt" for kOpMakeDefListItem, and the insert commands you quoted above.  I don't think we expose kOpInsertQuotation to the web, so we might want to test that separately in a chrome test or something.

Comment 54

[(no longer active)]

(In reply to WOLF_THUNDER from comment #52)
> (In reply to Aryeh Gregor from comment #51)
> > (In reply to maybe-the-one from comment #41)
> > > Does this fix also fix the issue of:
> > > 
> > > 1.  be typing
> > > 2. move cursor somewhere above the typing point (e.g. to insert test within
> > > previous words)
> > > 3. move cursor back to end of last line
> > > 4. Result: font changes to variable width because the replacement of cursor
> > > at the end of the line has moved it outside the [/ font ] tag.
> > > 
> > > ?
> > 
> > Nope, that's a separate bug.  Please feel free to file it, if it's not filed
> > already.
> > 
> 
> 
> Actually, that is this bug.  Any bug filed regarding font switching style to
> variable width got sent here.  That is the biggest issue of composing HTML
> emails in Thunderbird.  The font will not stay the same style if you move
> the focus and then go back to where you were.  Is that still, after over 7
> years, not getting fixed?

This bug is not about fixing all of the HTML composition issues in Thunderbird.  :-)  Please file a separate bug for this problem.  Thanks!

Comment 55

[maybe-the-one]

> Actually, that is this bug.  Any bug filed regarding font switching style to
> variable width got sent here.  That is the biggest issue of composing HTML
> emails in Thunderbird.  The font will not stay the same style if you move
> the focus and then go back to where you were.  Is that still, after over 7
> years, not getting fixed?

To the best of my knowledge, it is still a valid issue.  It was submitted with many different descriptions (as I described it, inserting lists, etc). There were so many different variations, that caused confusion--and most or all were referred into a BUG number I do not remember, as I stopped following it after several years with no action.  

There is an extension QuoteAndComposeManager which inserts some tags that preserve the font; I use that so stopped tracking the BUG, but I am sure it was not being worked on as of about 6 months ago. 

It is a fundamental issue that truly does need to be fixed.

Comment 56

[WOLF_THUNDER]

(In reply to maybe-the-one from comment #55)
> > Actually, that is this bug.  Any bug filed regarding font switching style to
> > variable width got sent here.  That is the biggest issue of composing HTML
> > emails in Thunderbird.  The font will not stay the same style if you move
> > the focus and then go back to where you were.  Is that still, after over 7
> > years, not getting fixed?
> 
> To the best of my knowledge, it is still a valid issue.  It was submitted
> with many different descriptions (as I described it, inserting lists, etc).
> There were so many different variations, that caused confusion--and most or
> all were referred into a BUG number I do not remember, as I stopped
> following it after several years with no action.  
> 
> There is an extension QuoteAndComposeManager which inserts some tags that
> preserve the font; I use that so stopped tracking the BUG, but I am sure it
> was not being worked on as of about 6 months ago. 
> 
> It is a fundamental issue that truly does need to be fixed.

Yes, and at least the bug I filed on it got sent to this bug, as someone thought it was a duplicate of this bug. And QuoteAndComposerManager does not really fix it.  There is no other reason why I would be following THIS bug if it did not address that issue.  I don't just follow mozilla or thunderbird bugs.

Comment 57

[Ian Neal]

Please could all those that are commenting about TB bugs, wait for this bug to be fixed and, if there are still issues, file a new bug (assuming you have checked there is not already open for the issues). Continual commenting just distracts the developer working on this bug. Thank you.

Comment 58

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

(In reply to WOLF_THUNDER from comment #52)
> Actually, that is this bug.  Any bug filed regarding font switching style to
> variable width got sent here.  That is the biggest issue of composing HTML
> emails in Thunderbird.  The font will not stay the same style if you move
> the focus and then go back to where you were.  Is that still, after over 7
> years, not getting fixed?

I'm fixing the problem described in comment #0.  Similar-looking problems can also be fixed, and I'll look at them if Ehsan asks me to, but those need to be filed as separate bugs.  If anyone duped the bug you describe to this one, they were wrong -- reopen it, it needs a completely different fix.  When the patches I've attached to this bug land, it will be closed as FIXED, so you need to make sure that other bugs are open at that point for other issues.

This does not mean the other issues are less important.  It just means that I was fixing the problem described in comment #0.  I can also fix other problems, but one thing at a time.

(In reply to Ehsan Akhgari [:ehsan] from comment #53)
> What compiler do you use?  (Hint: you really wanna use clang for local
> development)

gcc 4.6.1.  I tried installing clang from a package just now, but it doesn't work.  Maybe I'll try installing clang from source sometime, but package managers are so much more convenient . . .

> kOpMakeDefListItem gets invoked for things like formatBlock with "dt", and
> also for cmd_dd and cmd_dt which are used in comm-central.
> 
> kOpInsertQuotation is used in Thunderbird (see nsPasteQuotationCommand).

Okay, then kOpMakeDefListItem should be on the list per spec.  I'll add kOpInsertQuotation too, but I think I'll pass on the testing if you're willing to let me get away with it.

Comment 59

[(no longer active)]

(In reply to Aryeh Gregor from comment #58)
> (In reply to Ehsan Akhgari [:ehsan] from comment #53)
> > What compiler do you use?  (Hint: you really wanna use clang for local
> > development)
> 
> gcc 4.6.1.  I tried installing clang from a package just now, but it doesn't
> work.  Maybe I'll try installing clang from source sometime, but package
> managers are so much more convenient . . .

http://ehsanakhgari.org/blog/2011-10-18/why-you-should-switch-clang-today-and-how

Investing the time needed to get your own clang trunk build will pay off.  Big time!  :-)

> > kOpMakeDefListItem gets invoked for things like formatBlock with "dt", and
> > also for cmd_dd and cmd_dt which are used in comm-central.
> > 
> > kOpInsertQuotation is used in Thunderbird (see nsPasteQuotationCommand).
> 
> Okay, then kOpMakeDefListItem should be on the list per spec.  I'll add
> kOpInsertQuotation too, but I think I'll pass on the testing if you're
> willing to let me get away with it.

Hehe, ok, but don't tell anyone!

Comment 60

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

I updated the spec (and tests) to make more commands preserve overrides:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#preserves-overrides

Now all block commands preserve overrides except insertText, since that naturally does something special with them.  There's not a clear one-to-one correspondence between the spec's block commands and our actions, but I'll see what looks like it makes sense.

With the updated tests, patch 6 causes test_runtest.html regressions that are fixed by patch 7.  Would you prefer that I not update tests at all in patch 6, so it's clear that the patchset as a whole causes no regressions but bisecting might cause spurious failures?  Or that I add the expected fails in patch 6 and then remove them in patch 7?

Comment 61

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 7, v2 -- Preserve type-in state when performing block commands

Same as last version, but with more commands affected, per new spec/tests.

Comment 62

[(no longer active)]

(In reply to Aryeh Gregor from comment #60)
> With the updated tests, patch 6 causes test_runtest.html regressions that
> are fixed by patch 7.  Would you prefer that I not update tests at all in
> patch 6, so it's clear that the patchset as a whole causes no regressions
> but bisecting might cause spurious failures?  Or that I add the expected
> fails in patch 6 and then remove them in patch 7?

If possible, we should aim to pass all of our tests on every changeset.

Comment 63

[(no longer active)]

Comment on attachment 624737 [details] [diff] [review]
Patch part 7, v2 -- Preserve type-in state when performing block commands

Review of attachment 624737 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great!

Comment 64

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Attachment: Patch part 5, v2 -- Delete empty wrappers when we delete the selection

I think this addresses all of your feedback -- but I might have overlooked some, since there was a lot!

New try push with updated versions of everything: https://tbpl.mozilla.org/?tree=Try&rev=9d208c0190d2  Still have to address comment 62, but that's easy.

Comment 65

[(no longer active)]

Comment on attachment 624810 [details] [diff] [review]
Patch part 5, v2 -- Delete empty wrappers when we delete the selection

Review of attachment 624810 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for doing this!

Comment 66

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5bf058a8fdc0
https://hg.mozilla.org/integration/mozilla-inbound/rev/8c0be42c0010
https://hg.mozilla.org/integration/mozilla-inbound/rev/d27953b09922
https://hg.mozilla.org/integration/mozilla-inbound/rev/0c5687159491
https://hg.mozilla.org/integration/mozilla-inbound/rev/62ffb052629d
https://hg.mozilla.org/integration/mozilla-inbound/rev/5161427d7c4c
https://hg.mozilla.org/integration/mozilla-inbound/rev/e8ebc8f1825e

Comment 67

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/5bf058a8fdc0
https://hg.mozilla.org/mozilla-central/rev/8c0be42c0010
https://hg.mozilla.org/mozilla-central/rev/d27953b09922
https://hg.mozilla.org/mozilla-central/rev/0c5687159491
https://hg.mozilla.org/mozilla-central/rev/62ffb052629d
https://hg.mozilla.org/mozilla-central/rev/5161427d7c4c
https://hg.mozilla.org/mozilla-central/rev/e8ebc8f1825e

Comment 68

[Mark Banner (:standard8)]

Aryeh,

Thanks for working on this, at a quick glance it does indeed seem a lot better.

(In reply to Aryeh Gregor from comment #51)
> (In reply to maybe-the-one from comment #41)
> > Does this fix also fix the issue of:
> > 
> > 1.  be typing
> > 2. move cursor somewhere above the typing point (e.g. to insert test within
> > previous words)
> > 3. move cursor back to end of last line
> > 4. Result: font changes to variable width because the replacement of cursor
> > at the end of the line has moved it outside the [/ font ] tag.
> > 
> > ?
> 
> Nope, that's a separate bug.  Please feel free to file it, if it's not filed
> already.

This is still an issue, so I filed bug 756984 with a couple of STRs on it.

Comment 69

[Joe Sabash [:JoeS1]]

Ping|
Please see resulting code generated with a typical text correction here:
https://bugzilla.mozilla.org/show_bug.cgi?id=756984#c3

Comment 70

[Charles]

I know I'm probably going to get a lot of push back on this, but I really, really think that these editor fixes should be back-ported to the ESR release, not require ESR users to wait almost a full YEAR before seeing them...

Enterprises will benefit MUCH more than home users with these fixes, as they are very frustrating for users who use HTML email, and most enterprise users do want to use HTML, like it or not...

Comment 71

[Mark Banner (:standard8)]

(In reply to Charles from comment #70)
> I know I'm probably going to get a lot of push back on this, but I really,
> really think that these editor fixes should be back-ported to the ESR
> release, not require ESR users to wait almost a full YEAR before seeing
> them...

The next ESR will be in November, so there is actually less than 6 months, enterprises may take longer to pick it up, but we can't do anything about that.

There is an interface change that would prevent a straight back-port (as it could break extensions). Even if that could be avoided, I would expect the normal soak time before backporting, which would put us right near to the next ESR anyway.

Comment 72

[(no longer active)]

FWIW, I would not recommend this for ESR.  The risk involved is just too high.

Comment 73

[Charles]

Ok, didn't realize the changes were so big... at least that gives more time for even more editor changes to make it in before the next ESR...

And by the way, thanks VERY much for working on this Aryeh! The buggy HTML composer/editor has been one of the biggest complaints from some of our power users...

Comment 74

[(no longer active)]

This was disabled on the beta branch because of bug 780035.  It remains enabled on aurora (Firefox 16).

Comment 75

[Paul Silaghi, QA [:pauly]]

(In reply to Ehsan Akhgari [:ehsan] from comment #0)
> STR:
> 
> 1. Open the midas demo page.
> 2. Set the font size to 7.
> 3. Type something.
> 4. Create a list and then type something.
> 5. Press Enter twice and then type something.
> 
> The text entered in steps 4 and 5 is not in font size 7.  The editor is
> somehow losing the type-in state when injecting the list element.
> 
> This is one of the biggest pain points with the HTML editor.
> 
> The respective Thunderbird bug is bug 250539.

Disabled on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0b2

Comment 76

[Phillip M. Jones, C.E.T.]

This is not  just a problem with Windows it affects Mac Versions even to Mountain Lion (OSX.8.x) and it been on going in SeaMonkey for at least the last 3-4 years. I posted a Bug report here right after it happened and all that was received was crickets chirping.  

My opinion: It won't get fixed. Most here would love for HTML Mail to disappear.

Comment 77

[Paul Silaghi, QA [:pauly]]

(In reply to Paul Silaghi [QA] from comment #75)
> Disabled on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101
> Firefox/15.0.1
> Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0)
> Gecko/20100101 Firefox/16.0b2

Same behavior on Ubuntu 12.04 and Mac OS X 10.8.

Comment 78

[WOLF_THUNDER]

So, I am now using Thunderbird 31 and guess what?  The HTML composition is exactly as it has always been.  It changes font / state during the middle of composition if you move the pointer.  Even though this bug is "fixed".  Ha Ha Ha!  What a joke.  How old is this bug now?  8 years or more...

Comment 79

[Charles]

@WOLF_THUNDER:

Maybe what you are now experiencing is actually a different or possibly related bug?

Do you not realize that the reason that this bug went unfixed for so long was because it was a *huge undertaking*? the code involved apparently touched many, many things, and was very painful to even attempt to fix.

What has happened now is that the editor is getting a total rewrite, so that fixing the *remaining* bugs will be much easier.

So, rather than ridicule, how about some productive assistance?

Open a new bug, identify the exact steps to reproduce your problem, and lets see if Joshua can fix it now?

Comment 80

[Charles]

Hmmm... I now see that Ehsan was working on this... now I'm confused, I though Joshua Cranmer was the one who had taken on the editor rewrite...

Oh well, than you Ehsan, Alice, and any/everyone else working on these editor bugs!

Comment 81

[WOLF_THUNDER]

(In reply to Charles from comment #79)
> @WOLF_THUNDER:
> 
> Maybe what you are now experiencing is actually a different or possibly
> related bug?
> 
> Do you not realize that the reason that this bug went unfixed for so long
> was because it was a *huge undertaking*? the code involved apparently
> touched many, many things, and was very painful to even attempt to fix.
> 
> What has happened now is that the editor is getting a total rewrite, so that
> fixing the *remaining* bugs will be much easier.
> 
> So, rather than ridicule, how about some productive assistance?
> 
> Open a new bug, identify the exact steps to reproduce your problem, and lets
> see if Joshua can fix it now?

Nice how my comment was hidden.  Calling out an outstanding bug is abusive.  LOL.

Look, I reported this bug several times, under several tickets, at least 8 years ago, probably even longer ago if I look at the history of Thunderbird.  It was always either "oh, that is part of another bug - file it over there", or "it will be fixed in an upcoming release" over and over and over and over...  and now, here we are at version 31, and ever since version 1, this bug has persisted.

If I was a coder, I would offer to help.  But I am not, so I offered to help by filing bug reports, and provided detailed steps to the issues.  And guess what, this is the SAME bug.  I have used Thunderbird long enough to know it is not "a new bug"  But thanks.

Comment 82

[maybe-the-one]

(In reply to WOLF_THUNDER from comment #81)
> (In reply to Charles from comment #79)
> > @WOLF_THUNDER...
> > What has happened now is that the editor is getting a total rewrite, so that
> > fixing the *remaining* bugs will be much easier.

Well, that is great news.  I don't know whether it is Ehsan or Joshus doing it (maybe they could collaborate?), but it is welcome news after all these years.

And I agree with the other poster who said the bug(s) has been reported over and over--and they have been cancelled as duplicates, or otherwise shoved under the rug--for YEARS. 

But, t least now, we have the hope the problem is getting attention.

Comment 83

[WOLF_THUNDER]

If it is "actually" getting fixed, _this_ time, that is great news.  

Not to be suspect of yet another dubious claim, But it is the same news as we have heard before, and before.  New editor, total rewrite, etc.  So, I will believe when (if) I see it.  

There was recently some write up about version 26 or 28 would have the new fixes in, and "they work, bug is fixed", the fix was in the nightly builds and it would be out soon...  Well, here is 31 and it is still the same.  

So, if it is really, really, for real being fixed, great.  But I am suspect due to the many, many, many times of hearing these promises.

And I know what will happen next.  "Comments like these make us less interested in fixing it, because we feel like you don't care."  I wouldn't be here complaining, if I did not care.

Just look at the status of this bug "Status: 	VERIFIED FIXED "  LOL.

Comment 84

[johnfull]

SeaMonkey used to have decent Mail code, but switched to TB and inherited all the problems.
I wish we could go back to the code before the merger with FF/TB and go from there.
Of course, there are years worth of security apparatus built up meantime, plus the switch
to the ToolKit shortcut language.  Not being a developer, I have to just take what I get.
I would add that the problem has not stayed exactly the same and is now worse in some ways.
It used to be that you would SEE the break with typeface preference as you typed, but now
it's hidden until the mail is sent and then it's too late; WYSIWYG is no longer the rule...