contenteditable stuck inserting <br> instead of <p> in some cases

RESOLVED FIXED in mozilla8

Status

()

Core
Editor
RESOLVED FIXED
9 years ago
2 months ago

People

(Reporter: Alexander Staubo, Assigned: kaze)

Tracking

(Depends on: 1 bug, {dev-doc-complete, testcase})

unspecified
mozilla8
dev-doc-complete, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

If you run execCommand("insertunorderedlist"), then type a few lines and hit enter twice, any subsequent lines you make by hitting enter will be terminated with a <br> rather than being wrapped in <p>. The only way to get back into paragraph mode is to delete the text and get back into a <p> tag somewhere else in the document. (Better workarounds would be appreciated!)

Reproducible: Always

Steps to Reproduce:
1. Run execCommand("insertunorderedlist") on contenteditable.
2. Type a few lines
3. Hit enter twice to escape bullet mode.
Actual Results:  
Any subsequent lines, when you hit enter, will be terminated with a <br>.

Expected Results:  
When you hit enter, new lines should be wrapped by <p> tags.

Comment 1

8 years ago
This behavior makes it very difficult to properly apply block-level changes to editable content.
Reporter, please retest with Firefox 3.6.12 or later in a fresh profile (http://support.mozilla.com/kb/Managing+profiles). Also update your plugins (flash, adobe reader, java, quicktime, silverlight, etc.) Go to the developer's website and download the latest version from there. If you no longer see this issue, please close this bug as RESOLVED, WORKSFORME. If you do see the bug, please post a comment.
Whiteboard: [CLOSEME 2010-12-01]
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE

Comment 4

6 years ago
The problem still happens in the latest Firefox 4.0.1 (Ubuntu).

I'd be glad bring a test-case, or anything that could help get this right.

Thank you!
Status: RESOLVED → REOPENED
Component: General → Editor
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → editor
Resolution: INCOMPLETE → ---
Whiteboard: [CLOSEME 2010-12-01]
Duplicate of this bug: 662034
Does anybody have a test case which shows how to reproduce this bug?
Keywords: testcase-wanted

Comment 7

6 years ago
http://html5demos.com/contenteditable

There is a contenteditable area on that page, which has an ordered list. Now:

- go to the last item of the list, press <End>, and then press <Enter> two times in a row (first <Enter> creates a new list item, the second one, exits the “list mode” and enters “paragraph text mode”).
- type in a couple of lines of text, then inspect the markup of those lines (with Firebug, or select them and click “View Selection Source” from the selection's context menu)

The problem is that the lines of text are encoded as “text nodes separated by <br>s” when they should be encoded as “<p>s”.
Assignee: nobody → ehsan
Keywords: testcase-wanted → testcase
Whiteboard: [post-2.0]
Depends on: 672709
(Assignee)

Comment 8

6 years ago
Created attachment 547091 [details] [diff] [review]
patch proposal

This patch creates a paragraph instead of a <br> node when [Return] is pressed:
 • once in a <h[1…6]> node;
 • twice in a <li> node.

Works in most cases but raises another issue when the whole document is in design mode. I’ll write a test ASAP.

Are there other “br-instead-of-p” situations?
Assignee: ehsan → kaze

Comment 9

6 years ago
Thanks a bunch man!

Another case is when you're right inside the contenteditable element.

For example, on this page: http://html5demos.com/contenteditable, this would be when you're in section#editable and it is empty, whether it was empty in the first place or you just delete everything. If you press [Return], you get <br>s.
(In reply to comment #9)
> Thanks a bunch man!
> 
> Another case is when you're right inside the contenteditable element.
> 
> For example, on this page: http://html5demos.com/contenteditable, this would
> be when you're in section#editable and it is empty, whether it was empty in
> the first place or you just delete everything. If you press [Return], you
> get <br>s.

Please file a new bug about that.  We don't want this bug to fix all of these types of issues.  The patch in this but focuses on what happens after pressing Enter at the end of a heading or a list.

Comment 11

6 years ago
Alright! I've filed bug 672929 regarding the generation of <br>s instead of <p>s in empty contenteditable block elements.
(Assignee)

Comment 12

6 years ago
Created attachment 547281 [details] [diff] [review]
patch proposal

Same patch, now including a unit test.
Attachment #547091 - Attachment is obsolete: true
Attachment #547281 - Flags: review?(ehsan)
(Assignee)

Comment 13

6 years ago
Created attachment 547283 [details] [diff] [review]
patch proposal

Now *really* including the unit test.
Attachment #547281 - Attachment is obsolete: true
Attachment #547281 - Flags: review?(ehsan)
Comment on attachment 547281 [details] [diff] [review]
patch proposal

># HG changeset patch
># Parent 819a2ffc4f0e022d1660e8804f41a74c6548e04b
># User Fabien Cazenave <kaze@kompozer.net>
>This patch creates a paragraph instead of a <br> node when [Return] is pressed:
> • once in a <h[1…6]> node;
> • twice in a <li> node.

It's probably a good idea to add a first line of description in the following form:

Bug 123456 - Short description of the patch

The longer description can follow.


The patch itself looks good, but you've forgotten to hg add the test file itself, so it's missing from the patch.  Can you please attach a new version containing the test file?
Attachment #547281 - Attachment is obsolete: false
Comment on attachment 547283 [details] [diff] [review]
patch proposal

>+  // simulates a [Return] keypress
>+  for (var i = 0; i < nbKeyPresses; i++)
>+    synthesizeKey("VK_RETURN", {});
>+  //synthesizeKey("*", {});

Remove the comment please?

Everything else looks great, r=me.  Thanks!
Attachment #547283 - Flags: review+
Whiteboard: [post-2.0]
Attachment #547281 - Attachment is obsolete: true
Keywords: dev-doc-needed
(Assignee)

Comment 16

6 years ago
Created attachment 547312 [details] [diff] [review]
patch proposal

fixed the patch description + removed the commented line.

Thanks for your help!
Attachment #547283 - Attachment is obsolete: true
Blocks: 330891
Pushed to mozilla-inbound.
http://hg.mozilla.org/mozilla-central/rev/e21430d2b2cb
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Listed on Firefox 8 for developers.
Keywords: dev-doc-needed → dev-doc-complete

Comment 20

6 years ago
Does this bug affect Thunderbird's compose behavior?

Comment 21

6 years ago
(In reply to Peter Lairo from comment #20)
> Does this bug affect Thunderbird's compose behavior?

The reason I ask is:

In Thunderbird, it is sometimes necessary to have a <br> instead of a <p>. For instance for addresses.

Legitimate paragraph:

bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla.

bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla .

Legitimate need for <br>:

     Joe Shmo
     Any Street 1
     12345 MyCity

Is there a key combo to force a <br>? I think CTRL+ENTER should force a <br>.
(Assignee)

Comment 22

6 years ago
(In reply to Peter Lairo from comment #20)
> Does this bug affect Thunderbird's compose behavior?

Yes it does. FWIW, Thunderbird’s QA lead (:usul) and I have spent a couple hours on this subject. We came to the conclusion that this patch won’t cause any regression in Thunderbird (and that a few front-end changes could be done to take advantage of this improvement). 

If any regression is found in Thunderbird, it should be filed as a new bug imho.

(In reply to Peter Lairo from comment #21)
> In Thunderbird, it is sometimes necessary to have a <br> instead of a <p>.
> For instance for addresses.

Bad example:
 • you can (should) use the “address” block format in this case;
 • with Thunderbird’s default settings, you have to press [Enter] *twice* to get a paragraph.

> Is there a key combo to force a <br>? I think CTRL+ENTER should force a <br>.

AFAIK, [Shift+Enter] is a rather standard shortcut on most apps. And it works on Thunderbird, too.

Comment 23

6 years ago
(In reply to Fabien Cazenave (:kaze) from comment #22)
> > For instance for addresses.
> Bad example:
>  • you can (should) use the “address” block format in this case;

I don't think anyone uses that style. It makes the text italics, and the user cannot not make it italics. So what's the (non-discoverable) benefit? Some obscure unix-based mail reader can identify it as an "address"? It should be trivial to create an algorithm that auto-identifies most addresses.

>  • with Thunderbird’s default settings, you have to press [Enter] *twice* to
> get a paragraph.

Cool!

Updated

6 years ago
Duplicate of this bug: 510663

Updated

5 years ago
Depends on: 772332
Comment hidden (spam)
You need to log in before you can comment on or make changes to this bug.