Closed Bug 414223 Opened 13 years ago Closed 9 years ago

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

Categories

(Core :: DOM: Editor, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: testcase, Whiteboard: midas [parity-webkit] [parity-IE] [parity-opera])

Attachments

(1 file, 1 obsolete file)

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=""
Attached file Testcase (obsolete) —
Whiteboard: midas
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.
Flags: blocking1.9?
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. 
No longer blocks: 322202
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.
Attachment #299572 - Attachment is obsolete: true
Whiteboard: midas → midas [parity-safari] [parity-IE] [parity-opera]
Why is this marked as a regression?
regression keyword is incorrect. I thought that bug 322202 had caused this. Removing keyword.
Keywords: regression
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
We should look at removing the <br> hack. We now have much more flexibility in positioning the caret and can possibly do without it.
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
Blocks: 237694
Blocks: contenteditable
No longer blocks: 237694
Flags: blocking1.9.2?
Whiteboard: midas [parity-safari] [parity-IE] [parity-opera] → midas [parity-safari] [parity-IE] [parity-opera] [parity-chrome]
Depends on: 240933
Depends on: 503838
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Whiteboard: midas [parity-safari] [parity-IE] [parity-opera] [parity-chrome] → midas [parity-webkit] [parity-IE] [parity-opera]
No longer depends on: 240933
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.
Whiteboard: midas [parity-webkit] [parity-IE] [parity-opera] → midas [parity-webkit] [parity-IE] [parity-opera][post-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.  :/
Whiteboard: midas [parity-webkit] [parity-IE] [parity-opera][post-2.0] → midas [parity-webkit] [parity-IE] [parity-opera]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
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?
Duplicate of this bug: 1249374
Duplicate of this bug: 1252425
You need to log in before you can comment on or make changes to this bug.