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

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
11 years ago
3 years ago

People

(Reporter: bugzilla, Unassigned)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
x86
Windows XP
testcase
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9.2 -
wanted1.9.2 -
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 1 obsolete attachment)

145 bytes, text/html
Details
(Reporter)

Description

11 years ago
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=""
(Reporter)

Comment 1

11 years ago
Created attachment 299572 [details]
Testcase
(Reporter)

Updated

11 years ago
Whiteboard: midas

Comment 2

11 years ago
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?
(Reporter)

Comment 3

11 years ago
Yes, it changed after bug 322202 was checked in. Also note that the br tag is added before the paragraph.
Flags: blocking1.9?
(Reporter)

Comment 4

11 years ago
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. 
(Reporter)

Updated

11 years ago
No longer blocks: 322202
(Reporter)

Comment 5

11 years ago
Created attachment 299709 [details]
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.
Attachment #299572 - Attachment is obsolete: true
(Reporter)

Updated

11 years ago
Whiteboard: midas → midas [parity-safari] [parity-IE] [parity-opera]
Why is this marked as a regression?
(Reporter)

Comment 7

11 years ago
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+
(Reporter)

Updated

10 years ago
Blocks: 237694
(Reporter)

Updated

10 years ago
Blocks: 237964
No longer blocks: 237694
(Reporter)

Updated

10 years ago
Flags: blocking1.9.2?
(Reporter)

Updated

10 years ago
Whiteboard: midas [parity-safari] [parity-IE] [parity-opera] → midas [parity-safari] [parity-IE] [parity-opera] [parity-chrome]

Updated

10 years ago
Depends on: 240933
Depends on: 503838

Updated

9 years ago
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-

Updated

9 years ago
Whiteboard: midas [parity-safari] [parity-IE] [parity-opera] [parity-chrome] → midas [parity-webkit] [parity-IE] [parity-opera]

Updated

8 years ago
No longer depends on: 240933

Comment 9

8 years ago
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]
(Reporter)

Comment 10

7 years ago
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

7 years ago
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.

Comment 13

7 years ago
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]

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX

Comment 14

3 years ago
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

3 years ago
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.