124763 - initial blank char typed following text after horizontal line is not tracked by insertion point

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Dave Lentz]

In the mail composer window, if a horizontal line is inserted into the body of
the message, subsequent text entered following that line the cursor insertion
point tracks the text for spaces typed in strange manner, with the insertion
point being updated every other space that is typed.  For example, if I were to
type a string of 6 spaces, the insertion point would not move to follow the 1st
space, but upon typing the second space, would jump to be correctly positioned.
 Similarly, the 3rd space would not move the cursor, but upon typing the 4th
space, the insertion point would jump to be correctly positioned.  This does not
occur in a text-only  subject area, but only in the text that follows the
insertion of a horizontal rule/line.  Text prior to the horizontal line does not
display this behavior.  Observed on Mozilla for MacOS X build 2002020516 and
MacOS 9 build 2002010405.  Appears to be fixed in MacOS X nightly build
2002020903.  Did not see any report of anything like this, so I'm reporting it
just to be sure it gets nailed and won't reappear in the next milestone build.

Comment 1

[Christopher Whitt]

I saw something similar on win98 2002020520, though it was in Composer, not in
Mail/News -> Compose New Message.  Add a HR, after it the insertion point only
moved on every second space character.  In Composer for the 2002020811
mathml-svg build this seems to be gone; the insertion point updates as expected
immediatly following a HR in a new page.

I think I'm just stupid, but I don't know how to add a HR in a new mail
messages.  Reporter, are you able to clarify where you saw this problem? 
(Perhaps the same component is used in both places)

Comment 2

[Dave Lentz]

When composing the email message (and it probably occurs in 
exactly the same way in the web page composer window), just select the 
 "Horizontal Line" item in the "Insert" menu, and a horizontal line gets 
inserted into the message text at the insertion point.  It's with the 
text following this HR element that the behavior occurs.

Comment 3

[Jean-Francois Ducarroz]

Reassign to editor

Comment 4

[Greg K.]

WorksForMe using Mac/2002052305 (1.0). Dave, is this problem still reproducible using a current build?

Comment 5

[Dave Lentz]

Not too sure what constitutes a "current build" nowadays, but in the 1.0 release
code (Build ID:2002052917), it's still there.  If I create a new mail doc, type
some text, insert a horizontal line (the <HR> html tag), enter some more text
after the horizontal line, the cursor tracks only every other space character,
resulting in a peculiar jumping of the cursor while typing.  The text is
properly entered, just the cursor position is a little flakey while typing.

Comment 6

[Greg K.]

Still WorksForMe using Mac/2002071608. Dave, can you reproduce this problem using a new 
Mozilla user profile?

Comment 7

[Dave Lentz]

Completely removed all traces (Mozilla in Documents folder, Mozilla Registry &
Versions files from Preferences folder, and Mozilla app folder) from a test
volume on a Jaz cartridge, downloaded the latest NB (2002071708), and tried to
reproduce the problem.  Could not reproduce it.  I then updated the Mozilla on
my main system to the latest NB (previously was at 2002061103), and (without any
changes to the profile) tried to reproduce the problem -- and could not.  Then
started up the 2002061103 NB and tried to reproduce the problem (using the same
profile, prefs, etc as the 0717 NB) and succeeded.  

It appears that something between the 2002061103 and 2002071708 Nightly Builds
has fixed this one.  Never did modify the user profile on the main system,
although a new one was created on the system running on the Jaz drive.

Comment 8

[Greg K.]

Dave, since it appears whatever was causing this problem for you has been fixed, I'm resolving 
this bug as WorksForMe. If you start to encounter it again, please feel free to reopen this bug.

Comment 9

[sujay]

verified.