414223 - [MIDAS] contenteditable adds a phantom <br> (goes away when pressing enter)

Status: RESOLVED WONTFIX

(Core :: DOM: Editor, defect)

Description

[José Jeria]

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=""

Comment 1

[José Jeria]

Attachment: Testcase

Comment 2

[Loune]

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?

Comment 3

[José Jeria]

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

Comment 4

[José Jeria]

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. 

Comment 5

[José Jeria]

Attachment: Testcase 2 (no paragraph used)

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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why is this marked as a regression?

Comment 7

[José Jeria]

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

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 9

[(no longer active)]

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.

Comment 10

[José Jeria]

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

Comment 11

[(no longer active)]

See comment 9, please!

Comment 12

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

(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.

Comment 13

[(no longer active)]

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

Comment 14

[Nelson Pecora]

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).

Comment 15

[cyril.auburtin]

just posted a related issue https://bugzilla.mozilla.org/show_bug.cgi?id=1249374

Are there plans to change this <br> placeholder?