148749 - return in heading broken

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[manojd]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2)
Gecko/20020510
BuildID:    2002051006

Type some text into composer on a new line. Change its style to "Heading 3". Now
press ENTER.

Cursor jumps far down. When you start typing text, it actually comes above
cursor - at the right place. Only visual feedback of where the text will go is
wrong after above ENTER.

Reproducible: Always
Steps to Reproduce:
1. See description above.

Comment 1

[Kathleen :Brade]

Joe--is this your bug or should it go to selection/mjudge?

Comment 2

[Joe Francis]

Neither.  It's layout.  There is supposed to be a margin after the heading.  The 
cursor is actually correct; it's the location of the typing that is wrong.  If 
you go to show all tags view and then back to normal, it will get laid out 
correctly.

Over to kin for disposition.

Comment 3

[manojd]

jfrancis: "The cursor is actually correct; it's the location of the typing that
is wrong.": If I take that as true, the margin is just tooooo much.

It still exists in Mozilla/1.1 Beta (build 2002072104).

Comment 4

[Kathleen :Brade]

I see this on Netscape 7 on Macintosh.

nominate for editorbase; the caret stuff here is very funky

Comment 5

[Kevin McCluskey (gone)]

EDITORBASE+. nsbeta1+

Comment 6

[rubydoo123]

testing on current trunk: can still reproduce the error

Comment 7

[kinmoz]

This is really an editor problem, when I hit return, I actually get this in the
content:

==============  Content Tree: ================
body@04955CF0 refcount=30<
  h3@04D3AD80 _moz_dirty="" refcount=4<
    Text@04BE2CD8 refcount=36<Heading Text>
  >
  br@04D5F490 _moz_dirty="" type="_moz" refcount=5<>
  br@04D5FD38 _moz_dirty="" type="_moz" refcount=5<>
>


with the caret placed between the 2 brs. When I type the editor inserts a *new*
text node before the 1st br. Everytime I click on the 3rd line (before the 2nd
br) and type something a new text node is added.

Comment 8

[kinmoz]

Ok, more details on this:

When you hit return in the header, nsHTMLEditRules::ReturnInHeader() inserts a
MozBR (not a normal BR) into the content and then leaves the caret after this
newly inserted MozBR.

When nsHTMLEditRules::AdjustSelection() is triggered it notices that the caret
is after the MozBR, so it thinks it needs to add another one because it assumes
the user wanted another blank line.

Now when you type a character after hitting the return key, there is code in
nsHTMLEditRules::WillInsert() that specifically checks to see if the caret is
collapsed and *after* a MozBR ... if it is, it moves the caret to the point
underneath the br's parent, with an offset that is before the br and then
proceeds with the insert.

Note that the moving of the caret leaves the selection in the br's parent so a
new text node is created for the character you just typed, even if there is text
node immediately before the br already.

So to fix this, perhaps all we need to do is make sure that the selection gets
placed before the 1st MozBR inserted ... also do we really need a MozBR here
instead of a regular BR?

Comment 9

[kinmoz]

... we also need to fix the fact that the bottom margin of the header isn't
being applied after the br is inserted.

Comment 10

[Joe Francis]

Changing summary so that I can find this bug.

Comment 11

[Jorg K (CEST = GMT+2)]

Attachment: Testpage showing the bug in Firefox.

There is no Netscape composer any more, that died long ago. But the bug from 2002 still persists in today's Firefox, 14 years later.

Comment 12

[Jorg K (CEST = GMT+2)]

Test page works OK in Chrome.

Comment 13

[Makoto Kato [:m_kato]]

old bug.  down to P3