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.
This bug does not exist in Mozilla 1.7.12.
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.
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.
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.
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.
This bug is still present in SeaMonkey 1.5a (20 April), though not in SeaMonkey 1.0.1 or 1.0.2.
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.
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?
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.)
An update: this bug is still present in SM 1.5a (20070124), but not in SM 1.1 or 1.0.7.
Still exactly as described in the various notes above in the latest trunk build. OK in 1.1.2.
I can't test on MAC, but comment 0 is WFM on windows
Can Michaels report be confirmed with Mac in newest version?
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.)
Joe(s), can either of you confirm this behavior on windows or Mac? NB comment 8 I still can't reproduce on vista trunk.
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.
Thanks very much.That helps a lot.
For the record, tried it with the latest release builds of Thunderbird & SeaMonkey. WFM in both. (PowerMac G4)
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).