Last Comment Bug 449243 - contenteditable stuck inserting <br> instead of <p> in some cases
: contenteditable stuck inserting <br> instead of <p> in some cases
Status: RESOLVED FIXED
: dev-doc-complete, testcase
Product: Core
Classification: Components
Component: Editor (show other bugs)
: unspecified
: All All
: -- normal with 4 votes (vote)
: mozilla8
Assigned To: Fabien Cazenave [:kaze]
:
:
Mentors:
: 510663 662034 (view as bug list)
Depends on: 772332 672709
Blocks: 330891
  Show dependency treegraph
 
Reported: 2008-08-05 09:59 PDT by Alexander Staubo
Modified: 2014-04-09 03:49 PDT (History)
15 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch proposal (3.08 KB, patch)
2011-07-20 07:45 PDT, Fabien Cazenave [:kaze]
no flags Details | Diff | Splinter Review
patch proposal (3.97 KB, patch)
2011-07-20 16:04 PDT, Fabien Cazenave [:kaze]
no flags Details | Diff | Splinter Review
patch proposal (8.36 KB, patch)
2011-07-20 16:13 PDT, Fabien Cazenave [:kaze]
ehsan: review+
Details | Diff | Splinter Review
patch proposal (8.41 KB, patch)
2011-07-20 19:17 PDT, Fabien Cazenave [:kaze]
no flags Details | Diff | Splinter Review

Description Alexander Staubo 2008-08-05 09:59:56 PDT
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 2009-08-12 18:55:21 PDT
This behavior makes it very difficult to properly apply block-level changes to editable content.
Comment 2 Tyler Downer [:Tyler] 2010-11-13 13:06:56 PST
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 [:Tyler] 2010-12-02 12:59:55 PST
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 2011-06-04 03:24:54 PDT
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 5 Boris Zbarsky [:bz] (still a bit busy) 2011-06-06 13:33:30 PDT
*** Bug 662034 has been marked as a duplicate of this bug. ***
Comment 6 :Ehsan Akhgari 2011-06-14 15:18:39 PDT
Does anybody have a test case which shows how to reproduce this bug?
Comment 7 gurdiga 2011-06-14 23:50:08 PDT
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] 2011-07-20 07:45:16 PDT
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?
Comment 9 gurdiga 2011-07-20 07:57:37 PDT
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 :Ehsan Akhgari 2011-07-20 08:43:41 PDT
(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 2011-07-20 13:34:23 PDT
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] 2011-07-20 16:04:52 PDT
Created attachment 547281 [details] [diff] [review]
patch proposal

Same patch, now including a unit test.
Comment 13 Fabien Cazenave [:kaze] 2011-07-20 16:13:33 PDT
Created attachment 547283 [details] [diff] [review]
patch proposal

Now *really* including the unit test.
Comment 14 :Ehsan Akhgari 2011-07-20 16:15:34 PDT
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?
Comment 15 :Ehsan Akhgari 2011-07-20 16:19:25 PDT
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] 2011-07-20 19:17:20 PDT
Created attachment 547312 [details] [diff] [review]
patch proposal

fixed the patch description + removed the commented line.

Thanks for your help!
Comment 17 :Ehsan Akhgari 2011-07-22 09:19:55 PDT
Pushed to mozilla-inbound.
Comment 19 Eric Shepherd [:sheppy] 2011-08-23 13:39:06 PDT
Listed on Firefox 8 for developers.
Comment 20 Peter Lairo 2011-09-06 03:22:07 PDT
Does this bug affect Thunderbird's compose behavior?
Comment 21 Peter Lairo 2011-09-06 04:11:26 PDT
(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] 2011-09-06 07:20:25 PDT
(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 2011-09-06 12:31:39 PDT
(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!
Comment 24 Ian Neal 2011-09-17 14:58:02 PDT
*** Bug 510663 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.