Build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012704 Minefield/3.0b3pre Steps to reproduce: 1. load testcase (and notice the extra space above the paragraph) 2. click somewhere on the paragraph and press enter 3. note that the extra space above is gone DOM Inspector says that the extra br tag inserted has the following nodeName and nodeValue: _moz_editor_bogus_node="TRUE" _moz_dirty=""

As far as I know when I last looked at this, in the case of Midas, the extra <br> is needed because if the <p> element is empty, then the whole element is collapsed, making the caret at a weird position. The dummy <br> makes it so there's always something in the new elements. And I think this existed before the bug 322202 patch. Has this changed recently?

Yes, it changed after bug 322202 was checked in. Also note that the br tag is added before the paragraph.

Note that, this issue has nothing to do with the paragraph, it will still insert a brake tag even though there are no paragraphs present.

Sorry for the confusion. This behavior existed before bug 322202 was checked in. Note that this testcase has no paragraph and it will still insert a brake tag. Internet Explorer, Safari and Opera does _not_ add this extra brake tag.

Why is this marked as a regression?

regression keyword is incorrect. I thought that bug 322202 had caused this. Removing keyword.

We should look at removing the <br> hack. We now have much more flexibility in positioning the caret and can possibly do without it.

I think the only remaining dependency to fix this bug is to make sure that empty contenteditable block elements have the same height as if they contained a BR node when reflown. I'll look at this once we branch for 2.0.

This bug is WFM using Firefox 4.0.1. Testcase works fine. Should this bug be closed or should bug 503838 be fixed first?

See comment 9, please!

(In reply to Ehsan Akhgari [:ehsan] from comment #9) > I think the only remaining dependency to fix this bug is to make sure that > empty contenteditable block elements have the same height as if they > contained a BR node when reflown. I'll look at this once we branch for 2.0. We can't make display change based on whether elements are editable. That would make contenteditable not WYSIWYG -- the paragraphs don't collapse, then when you publish your blog post or whatever and it's not editable, suddenly they collapse and it looks different. The <br> hacks are terrible, but I see no better solution -- thus something like Gecko's behavior is required by the editing spec.

Yeah, as much as this sucks, this is WONTFIX I think. :/

ContentEditable is not, by definition, WYSIWYG. Consider the case of inline text styling. There is almost never a 1:1 parity between the visual representation of the nodes and the underlying markup. Please consider reopening this? No other major browsers add these BR tags, and it tends to mess with actual WYSIWYG libraries and frameworks (since a line break, in many circumstances, counts as "content" when calculating whether a field/node/area of text is empty or not).

just posted a related issue https://bugzilla.mozilla.org/show_bug.cgi?id=1249374 Are there plans to change this <br> placeholder?