Closed Bug 449243 Opened 16 years ago Closed 13 years ago

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

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: alex, Assigned: kaze)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-complete, testcase)

Attachments

(1 file, 3 obsolete files)

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.
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
Closed: 14 years ago
Resolution: --- → INCOMPLETE
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]
Does anybody have a test case which shows how to reproduce this bug?
Keywords: testcase-wanted
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
Whiteboard: [post-2.0]
Depends on: 672709
Attached patch patch proposal (obsolete) — Splinter Review
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
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.
Alright! I've filed bug 672929 regarding the generation of <br>s instead of <p>s in empty contenteditable block elements.
Attached patch patch proposal (obsolete) — Splinter Review
Same patch, now including a unit test.
Attachment #547091 - Attachment is obsolete: true
Attachment #547281 - Flags: review?(ehsan)
Attached patch patch proposal (obsolete) — Splinter Review
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
Attached patch patch proposalSplinter Review
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
Closed: 14 years ago13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Listed on Firefox 8 for developers.
Does this bug affect Thunderbird's compose behavior?
(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>.
(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.
(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!
Depends on: 772332
You need to log in before you can comment on or make changes to this bug.