In Chromium (25.0.1364.160 Ubuntu 13.04) not logged in, the same step 3 adds blank line above (not styled as a heading) and moves the caret to the second character in the existing heading.

brassratgirl wrote:

I'm getting a similar bug while trying to edit a userpage subpage, with the addition that it's blanking out the existing text. See https://en.wikipedia.org/wiki/User:Phoebe/chopo

1. edit existing text, all is fine.
2. move cursor below existing paragraph, attempt to type new heading
3. cursor jumps to above existing paragraph, types up there
4. this results in uneditable blank spaces
5. and, on save, all text below blank spaces is gone.

My conclusion is that editing user pages is, for whatever reason, totally haywire. I have screenshots if needed.

Firefox 20.0 on Ubuntu 12.04

These days the behavior on mediwiki.org (with Firefox 21.0 Ubuntu 13.04) is different and a little better.

• If you press Enter with the caret at start of heading, you get a plain paragraph before (maybe OK but not what I'd expect and not how most WYSIWYG editors work)
• The caret moves between the first and second character of the heading (definitely wrong).

But the document doesn't get out of order, your typing always appears at the caret, and what you see is what is saved. Progress!

(In reply to comment #3)

These days the behavior on mediwiki.org (with Firefox 21.0 Ubuntu 13.04) is
different and a little better.

• If you press Enter with the caret at start of heading, you get a plain

paragraph before (maybe OK but not what I'd expect and not how most WYSIWYG
editors work)

This is intentional - if you have header 1\nheader 2\nheader 3\n and click before header 3 and press return, you should be able to type content (paragraph) by default. WYSIWYG editors often get this wrong, thinking that context is the most important thing, because they don't know what style "normal" content is. We do, and so we should do this right. (Also, VE isn't intending to be a WYSIWYG editor, just a visual one that is more and WYSIWYM editor at times.)

• The caret moves between the first and second character of the heading

(definitely wrong).

Yeah, sorry about that; we should get that fixed soon.

(In reply to comment #4)

(In reply to comment #3)

• If you press Enter with the caret at start of heading, you get a plain

paragraph before (maybe OK but not what I'd expect and not how most WYSIWYG
editors work)

This is intentional - if you have header 1\nheader 2\nheader 3\n and click
before header 3 and press return, you should be able to type content
(paragraph) by default.

Sounds good, though I note it's different than e.g. pressing Enter at the start of the first of a set of bullet points, which adds another bullet rather than a plain paragraph. A foolish consistency is the Hobnobs of little minds :)

(In reply to comment #5)

Sounds good, though I note it's different than e.g. pressing Enter at the
start of the first of a set of bullet points, which adds another bullet rather
than a plain paragraph. A foolish consistency is the Hobnobs of little minds :)

Yeah, I've been wondering whether to make these consistent for a little bit.

Change 70864 had a related patch set uploaded by Robmoen:
Don't advance cursor when adding new line at start of node

https://gerrit.wikimedia.org/r/70864

Change 70918 had a related patch set uploaded by Robmoen:
If cursor is obscured by toolbar, on keypress scroll to cursor.

https://gerrit.wikimedia.org/r/70918

Change 70918 merged by jenkins-bot:
If cursor is obscured by toolbar, on keypress scroll to cursor.

https://gerrit.wikimedia.org/r/70918

Change 70864 merged by jenkins-bot:
Don't advance cursor when adding new line at start of node

https://gerrit.wikimedia.org/r/70864

This should now be fixed; we will push this to production this afternoon.