Closed Bug 348149 Opened 18 years ago Closed 12 years ago

designMode editor: newline after a Heading or lists should result in a new <p>

Categories

(Core :: DOM: Editor, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: apratt, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

There is a behavior problem in FireFox when using most WYSIWYG editors for wikis and such. If your caret is at the end of a paragraph that is formatted as a heading (<h1>) and you press Enter and type more text, the text you type should be in a paragraph (<P>) instead of just sitting at the top level of the HTML.

In addition, when you are in a list (UL or OL) and you press Enter twice to exit list mode, the same thing happens: the text you type is at the top level of the HTML, not in a <P> tag. That is the wrong behavior.

By contrast, the same designMode editing widget does create a paragraph in these two situations if you use IE instead of FireFox.

I am not describing the same issue that led to the CR_creates_new_p preference and bug 285873 and bug 92686. That logic controls what happens when you press Enter while typing in a paragraph. I'm talking about what happens when you press Enter while in a heading or when you press it twice while in a list.

I would like the editor to land in <p> mode when exiting headings and lists. It is bad HTML form to have text outside of all paragraphs, at the top level of <body>. I believe this also impacts accessibility: HTML readers for the blind might rely on <P> tags.


Reproducible: Always

Steps to Reproduce:
1. Enable JavaScript and go to http://www.kevinroth.com/rte/demo.htm which is a demo of a designMode editor widget.

2. Click on the text in the edit box, then select "Heading 1" from the "Style" drop-down list.

3. Place your cursor at the end of the line and press Enter.

4. Type something; press Enter and type some more. You'll see that there is no blank line between the two lines after the heading, as there would be if this were in a <P> paragraph.

5. Click on the "View source" checkbox. Examine the HTML. Notice that there is no <p> following </h1>. This isn't the fault of the JavaScript that's driving the editor; it's the fault of the implementation of the designMode rich-text edit region.



Actual Results:  
The editor does not create a paragraph when you press Enter at the end of a heading line, or when you press Enter twice to exit list modes.

Expected Results:  
The editor should create a paragraph when you press Enter at the end of a heading line, and when you press Enter twice to exit list modes.


You can see the same thing if you create a ordered or unordered list, then press Enter twice to exit list mode. There is no <p> tag after </ol> (or </ul>).

If follow the same steps using IE you will find that the text you enter after the heading or list does appear in a paragraph.
Component: General → Editor
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.8 Branch
I'd accept hitting Enter creating a new block level element of the same kind (if I am in H1, and hitting enter creates a new H1 for example) rather than the system guessing what I want to do next, although 75% of the time I probably do want a new paragraph.  There are usually controls to change the current block level element to something else, and I'd notice if I was still typing H1 or a list element.  But if it creates text outside of a block level element, I most likely won't notice - if I'm using a RTE then I don't expect to view the source.  Most people using RTEs wouldn't even know how to.

So I totally agree that the current behaviour is bad practice.  RTEs exist so people don't need to worry about creating correct markup.  If an RTE creates bad semantic markup, then it isn't doing its job.  If it does this in such a way that the average user doesn't realise it then those RTEs become a source of much bad markup on the web.
Daniel is the module owner.  He would need to approve this behavior change.

I thought we had planned that we would offer two modes (current behavior and "standards" behavior which did <p> instead of <br> in various situations including the scenarios presented in this bug) but I don't recall the final decisions.  Looking at the source code (trunk / FF3), it looks like that should be the behavior but perhaps the behavior is only for <p> after <p> and not supposed to handle lists and headings.

Daniel--could you clarify if the expectation for the command "insertBrOnReturn" is supposed to affect lists and headings or only paragraphs?
Regarding Comment #2: in 2005 there was some discussion about CR behavior while in a paragraph, and the new behavior was implemented in nsHTMLEditRules::ReturnInParagraph. But the methods ReturnInListItem and ReturnInHeader have no such logic. I just think nobody ever mentioned it.

I want to say again that IE's designMode editor component does insert paragraphs after headings and lists.

Regarding Comment #1, I think pressing CR while in the *middle* of an <h1> tag should break the existing text into two <h1> tags, as it does now. Pressing CR while at the *end* of a line formatted as <h1> should end the heading, also as it does now. I have no beef with that part of the current behavior. But in exiting the heading and list modes, the editor does *not* insert a <p> for the new text, and that's what I think is wrong. Without a <p> tag, subsequent input from the user appears at the top level of the HTML, outside all tags. That is the problem.
QA Contact: editor
Blocks: 424615
Self-contained test-case:

data:text/html,<!doctype html>
<body>
<script>
setTimeout(function() {
document.body.innerHTML = "<div contenteditable><h1>Press Enter</h1></div>";
document.body.firstChild.focus();
var text = document.querySelector("h1").firstChild;
getSelection().collapse(text, text.length);
document.body.firstChild.onkeyup = function(e) {
  if (e.keyCode == 13) {
    document.body.textContent =
    document.body.firstChild.innerHTML;
  }
}
}, 100);
</script>

Result in mozilla-central: <h1>Press Enter</h1><p><br></p>

Opera Next 12.00 alpha is the same.  Chrome 19 dev uses <div> instead of <p>, and IE 10 Developer Preview uses &nbsp; instead of <br>.  The spec matches Gecko/Opera.

(In reply to Allan Pratt from comment #0)
> Steps to Reproduce:
> 1. Enable JavaScript and go to http://www.kevinroth.com/rte/demo.htm which
> is a demo of a designMode editor widget.
> 
> 2. Click on the text in the edit box, then select "Heading 1" from the
> "Style" drop-down list.
> 
> 3. Place your cursor at the end of the line and press Enter.
> 
> 4. Type something; press Enter and type some more. You'll see that there is
> no blank line between the two lines after the heading, as there would be if
> this were in a <P> paragraph.
> 
> 5. Click on the "View source" checkbox. Examine the HTML. Notice that there
> is no <p> following </h1>. This isn't the fault of the JavaScript that's
> driving the editor; it's the fault of the implementation of the designMode
> rich-text edit region.
> 
> 
> 
> Actual Results:  
> The editor does not create a paragraph when you press Enter at the end of a
> heading line, or when you press Enter twice to exit list modes.
> 
> Expected Results:  
> The editor should create a paragraph when you press Enter at the end of a
> heading line, and when you press Enter twice to exit list modes.

In a mozilla-central build, I see the expected results.  This bug was probably fixed sometime in the last several years.  Please reopen if I'm mistaken.  Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.