322454 - When typing e-mail in colour, text reverts to black if earlier characters are corrected.

Status: RESOLVED DUPLICATE of bug 250539

(Core :: DOM: Editor, defect)

Description

[Michael Graubart]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a

If a non-black text colour is selected and one starts typing text into a new e-mail, then goes back to correct something earlier in the same coloured text and then puts the insertion point back where one had previously left off and starts typing again, the text is now in black. Moreover, even if one now selects the new (black) text and changes its colour, further text is still black. One has to go back at least one character into the original, correctly coloured text, delete it and everything after it and retype in order to be able to carry on in the chosen colour.

Reproducible: Always

Steps to Reproduce:
1. In a new e-mail, choose, say, red as text colour and start typing.

2. Stop, e.g., after you have typed 'X', move the insertion point back to an earlier place in the text and make a correction.

3. Move the insertion point to immediately after the 'X' and continue typing.

4. Select everything after the 'X' and change its colour to red. Continue typing.

5. Select everything back to and including the 'X' (NB: the 'X' is red from the initial typing), delete and start typing with 'X' and continue.

Actual Results:  
At 3., the new text is black.

At 4., the selected text changes to red, but all new text is black.

At 5., the 'X' and subsequent text are red (as desired).

Expected Results:  
At 3. and 4. the new text should be red.

eMac G4, OS X 10.3.9, Classic theme.

Comment 1

[Michael Graubart]

This bug does not exist in Mozilla 1.7.12.

Comment 2

[Michael Graubart]

I have narrowed the timing down: 

The last trunk build that was OK (i.e. no bug) was 2005120709.

The first trunk build to display the bug was 2005120809.

Comment 3

[Michael Graubart]

Other formatting behaves similarly. E.g. if one types some bold, italic and/or underlined text and goes back to correct something, text from the end of the initial text is unformatted.

Comment 4

[Michael Graubart]

A further observation: if, after making a correction in an earlier part of the text (or just placing the insertion point earlier in the text) one moves the insertion back to where one had left off typing by using the arrow key, when one continues typing the chosen colour or style continues. It is only if one moves the insertion point back to where one had previously left off by clicking at that point that the colour or styling reverts to black or unstyled. It does not matter whether the initial move of the insertion point back to where one wants to make a correction is done by clicking or with the arrow key; it is only the way the subsequent move forward again is accomplished (arrow key or clicking) that affects the colour or style of the following text.

I realize that in the great scheme of things this bug is a minor irritant, but it is an irritant nevertheless.

Comment 5

[Michael Graubart]

SeaMonkey 1.0: This bug appears to have been fixed as far as my equipment (eMac G4, OS X 10.3.9, Classic theme) is concerned. Thank you.

Comment 6

[Michael Graubart]

This bug is still present in SeaMonkey 1.5a (20 April), though not in SeaMonkey 1.0.1 or 1.0.2.

Comment 7

[Michael Graubart]

After not testing the Trunk builds for a long time, I have just tried SeaMonkey 1.5a, Build 2006072206, and this bug is still present, making typing some e-mails very frustrating.

Comment 8

[Michael Graubart]

Build 2006080504

Here are some refinements of my observations:

1.One does not have to go back in the styled text. Merely clicking anywhere in the pane makes style revert to black and plain text.

2.If one has had to move the insertion point a long way back (making subsequently using the 'forward' arrow-key impracticable), holding 'Shift' down, clicking at the end of the previously typed text (which selects all the text from where the insertion point was moved back to up to where typing is to resume) and clicking again allows typing while retaining the colour or style.

Perhaps these observations may help to identify the cause of this irritating misbehaviour. Or is there perhaps something in 'about:config' that could be used to change it?

Comment 9

[Michael Graubart]

A final observation: I am no longer sure of Comment #8 (2). I cannot reliably reproduce it. But what I can reproduce is that if one clicks very close indeed to the last styled or coloured character, the style or colour is retained. (In SeaMonkey 1.0.4 one does not have to click close to the last character.)

Comment 10

[Michael Graubart]

An update: this bug is still present in SM 1.5a (20070124), but not in SM 1.1 or 1.0.7.

Comment 11

[Michael Graubart]

Still exactly as described in the various notes above in the latest trunk build. OK in 1.1.2.

Comment 12

[Wayne Mery (:wsmwk)]

I can't test on MAC, but comment 0 is WFM on windows

Comment 13

[Wayne Mery (:wsmwk)]

Can Michaels report be confirmed with Mac in newest version?

Comment 14

[Michael Graubart]

Yes, the original bug is still there in v. 2.0.9pre, auto-updated yesterday (or today; I can't remember which). (My system is a Mac G4 - PPC - with OS X 10.4.11, in case that is relevant to this bug.)

Comment 15

[Wayne Mery (:wsmwk)]

Joe(s), can either of you confirm this behavior on windows or Mac?  NB comment 8

I still can't reproduce on vista trunk.

Comment 16

[Joe Sabash [:JoeS1]]

xref bug 250539
This seems to be just another instance where if the caret is moved out of the composition, then re-focused, you end up with the insertion point outside of your current point.
I think we should dup to 250539, but a fix (if any) will happen in bug 590640
Not an answer by any means, but if you always position the cursor just to the left of the last typed character and resume typing from there, you should avoid the bug.

Comment 17

[Michael Graubart]

Thanks very much.That helps a lot.

Comment 18

[Joe Sewell]

For the record, tried it with the latest release builds of Thunderbird & SeaMonkey. WFM in both. (PowerMac G4)

Comment 19

[Michael Graubart]

Re Comment #18: I have just tried it with the latest SM (2.0.12pre). WFM now, unless the last character typed before going back to make a correction was a space. In that case, if one then resumes typing after the space, colour (and, by the way, point-size, etc.) still revert to black and standard point-size. (eMac G4, OS X 10.4.11).