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

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Alexander Staubo]

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

[Tim]

This behavior makes it very difficult to properly apply block-level changes to editable content.

Comment 2

[Tyler Downer [He/Him]]

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.

Comment 3

[Tyler Downer [He/Him]]

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.

Comment 4

[gurdiga]

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!

Comment 6

[(no longer active)]

Does anybody have a test case which shows how to reproduce this bug?

Comment 7

[gurdiga]

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

Comment 8

[Fabien Cazenave [:kaze]]

Attachment: 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?

Comment 9

[gurdiga]

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.

Comment 10

[(no longer active)]

(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

[gurdiga]

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

Comment 12

[Fabien Cazenave [:kaze]]

Attachment: patch proposal

Same patch, now including a unit test.

Comment 13

[Fabien Cazenave [:kaze]]

Attachment: patch proposal

Now *really* including the unit test.

Comment 14

[(no longer active)]

Comment on attachment 547281 [details] [diff] [review]
patch proposal

># HG changeset patch
># Parent 819a2ffc4f0e022d1660e8804f41a74c6548e04b
># User Fabien Cazenave <[e-mail]>
>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?

Comment 15

[(no longer active)]

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!

Comment 16

[Fabien Cazenave [:kaze]]

Attachment: patch proposal

fixed the patch description + removed the commented line.

Thanks for your help!

Comment 17

[(no longer active)]

Pushed to mozilla-inbound.

Comment 18

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/e21430d2b2cb

Comment 19

[Eric Shepherd [:sheppy]]

Listed on Firefox 8 for developers.

Comment 20

[Peter Lairo]

Does this bug affect Thunderbird's compose behavior?

Comment 21

[Peter Lairo]

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

Comment 22

[Fabien Cazenave [:kaze]]

(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

[Peter Lairo]

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