Closed Bug 92686 Opened 23 years ago Closed 20 years ago

Return inserts line break, should insert paragraph break

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: hsivonen, Assigned: glazou)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: relnote, Whiteboard: [rules])

Attachments

(2 files, 3 obsolete files)

fix #3, in answer to brade's and akkana's comments
16.15 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review
Same as above with some additional cleanup.
24.50 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
When the text entry point is inside a paragraph, pressing return inserts a line
break and not a paragraph break.

In a normal situation, there is no reason to insert line breaks inside
paragraphs. Also, one expects Mozilla to behave consistently with word
processors and other HTML editors (including but not limited to Word,
AppleWorks, Dreamweaver and Amaya).

For me, this is *the* most annyoing bug/feature in Editor.

Web pages describing the problem
In English: http://www.hut.fi/u/hsivonen/moz-editor#paragraphs
In Nynorsk:
http://home.no.net/huftis/nynorsk-programvare/mozilla/nettsideutvikling.html

This has been discussed in n.p.m.editor a few times, but no changes were made. I
address some of the counter arguments that have been made:

Counter argument: Word processor insert a line break when pressing return. The
users of Editor expect word-processor-like behavior.
Counter counter argument: Popular word processors (including Word) do not insert
a line break when pressing return. They insert a paragraph break.

Counter argument: Users expect return to insert a line break.
Counter counter argument: Not all of us do. I expected the editor to work like
word processors and other HTML editors.

Counter argument: In mail composition, the return is expected to work the way it
does in plain text.
Counter counter argument: Even if it was desirable behavior there, why couldn't
it work the word processing way in the Web page editor? It used to be a pref.

-----

If inserting a paragraph break by default is unacceptable, could at least the
pref, please, be put back?
Whiteboard: [Word-p][AppleWorks-p][Dreamweaver-p][Amaya-p]
removing the status whiteboard noise:

[Word-p][AppleWorks-p][Dreamweaver-p][Amaya-p]

assigning to jfrancis, and placing in [rules] bucket
Assignee: beppe → jfrancis
Whiteboard: [Word-p][AppleWorks-p][Dreamweaver-p][Amaya-p] → [rules]
1.0
Severity: major → normal
Priority: -- → P3
Target Milestone: --- → mozilla1.0
rules breakouts for seperate clients are in the works.  097
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 121106 has been marked as a duplicate of this bug. ***
A new argument for inserting paragraph breaks by default:
This would be much better for CSS.

The optima behaviour would be the one as seen in MS Word, StarWriter,
Dreamweaver etc., that is, ENTER breaks the paragraph, Shift-ENTER breaks line.
the swami says: things that will not land in 099!
Target Milestone: mozilla0.9.9 → mozilla1.0
Moving bugs to Mozilla1.1 that are not EDITORBASE+.
Target Milestone: mozilla1.0 → mozilla1.1
removing myself from the cc list
The trunk is the wave of the future!
Target Milestone: mozilla1.1alpha → mozilla1.1beta
The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.
Target Milestone: mozilla1.1beta → mozilla1.2beta
Target Milestone: mozilla1.2beta → M1
differentiating bug severity of my most critical bugs vai abuse of milestone field
M2: severe
M1: very severe and/or fix in hand
Target Milestone: M1 → M2
Another solution would be to insert a new paragraph when the user presses 'Enter' twice (i.e., presses 'Enter' when there already *is* a linebreak). Then everything will (seemingly) work as before, but the resulting documents will have a proper, meaningful structure.
> Another solution would be to insert a new paragraph when the user 
> presses 'Enter' twice

This bug is exactly about *not* doing it that way. That's how Composer behaved
when I reported this bug.

Considering
http://www.huftis.org/nynorsk-programvare/mozilla/nettsideutvikling.html I
though you agreed with this change request.
>> Another solution would be to insert a new paragraph when the user 
>> presses 'Enter' twice
>
> This bug is exactly about *not* doing it that way.
> That's how Composer behaved when I reported this bug.

I agree that this is not a *perfect* solution, but it's clearly better than the ways things are *currently* handled. Now you can write a 20 page long document containg many visual 'paragraphs', but where all the text is in fact one *very long* paragraph.
*** Bug 192282 has been marked as a duplicate of this bug. ***
futuring for now.  no consensus.  for every person who wants a paragraph, there
are two who never use any block formats other than list and who get confused if
they can't click on a blank line (think paragraph vertical margins).
Target Milestone: M2 → Future
Even FrontPage inserts paragraph instead of line breaks when [Enter] is
pressed. But it also - like most other word processors - inserts line
break when [Shift] + [Enter] is pressed.

This is the correct behavior of a word processor, and my opinion is that
any counter-argument to this is based on the fact that the user either
doesn't know how a word processor is used, or he/she uses it in a wrong
way.

The link between word processors and an HTML composer is much closer than
between an e-mail client and an HTML composer, since an e-mail client
usually composes clear text. If the e-mail client composes HTML, it
should of course act as a word processor as well, and create correct
HTML: With paragraphs -- and not line breaks -- as paragraphs.

There is a difference between clear text and rich text editing, imho.
Pressing Return should insert a paragraph, not a line break. This is how each of
the following act: Dreamweaver, FrontPage, GoLive, the RealObject Java applet
WYSIWYG, and, last but not least, Microsoft DHTML WYSIWYG control. If I went and
did more research, I could find others. 

The convention in WYSIWYG editors is that pressing return inserts a paragraph.
Mozilla's Editor is the only WYSIWYG that I'm familiar with that does not
respect this convention. It is annoying to everyone else who uses those
programs, and for newbies switching over from MSFT's control to the future
Mozilla textarea WYSIWYG, it will be a disaster. 

At the least, this should be a preference. 

Until this is fixed, the idea behind Midas (using Mozilla Editor to edit a
textarea) is flawed.
JFrancis, I've got an impression that overwhelming majority of people here
(judging from the comments) are for the industry standard of Enter (Return)
inserting a paragraph break and Shift-Enter (Shift-Return) inserting a line break.

Anybody who thinks otherwise please, speak up!

Otherwise, we've reached a consensus and work can start on a patch.
What's the status? I noticed that Midas, which is in 1.3, still does it the
"wrong" way.
Yes, I think this should block bug 171034. The ability to mark up proper
paragraphs is a fundamental need for good content management systems.

The issue mentioned in comment #16 could be solved by not leaving a margin of
1em that looks like a blank line between paragraphs. OTOH, if a margin of 0.5em
was used, the question would obviously be, whether the standards mode UA style
sheet could always have that as the default margin or whether the editor could
have a different default style sheet.
Blocks: oscom
I tend to agree with reporter here. I am insulting Composer each time I have to
end a paragraph and start a new one... Enter for paragraph breaking and
shift-enter for line breaking seems the industrial common practice.
In response to comment #16: I think the key to this bug (and my duplicate bug)
is whether you are thinking of the output of composer as marked up structured
text or not. Most markup languages used for prose text are oriented around a p
or para paragraph element. This is analogous to the way real-world texts are
structured: as sequences of paragraphs. A line break element (br in HTML) is
appropriate primarily when one is dealing with line by line texts (for instance,
verse, or addresses), where the line break does not signify a change in thought.
I think that the overwhelming majority of times someone types a return in
plaintext their intention is to mark a change in thought, i.e., a paragraph
break.  Anyway, that's my argument on this. I'd welcome any argument against
that keeps in mind the purpose of structured markup, which is what HTML was
designed to provide - a no-frills structured markup language.
Blocks: 200546
My comments are regarding Midas, as I don't use Composer, but it's my
understanding that Midas is just an instance of Composer's back end embedded in
an iframe; please correct me if that's wrong.

I'm throwing my hat into the "enter should create a paragraph" ring. It's the
most reasonable thing to do when writing HTML. How often do you want a line
break vs. a new paragraph? The latter is far, far more common and therefore
should be the default behavior.

It's also what people expect. I don't mean developers, now; I mean end users.
I'm doing early testing with Midas as editor in my CMS (and let me just say that
an iframe based editor is supremely unsuited to this use, but that's a rant for
another time) and almost without exception when people hit the enter key and
just get a line break, they hit it again to get a paragraph. I have had one
single instance of someone actually wanting a line break, and she tried to get
it by hitting Shift+Enter first.

Another factor to consider is that most of Midas' potential usefulness requires
it to output good, valid, structural markup. I do some post processing to ensure
valid XHTML, but breaks instead of paragraphs is going to kill me. Whether or
not it's valid HTML is not the point here; it's not structurally correct, and
I'm positive I'm not the only one that's going to cause major problems for.
Millions of people are used to the WORD or OpenOffice way of ENTER action:

- ENTER inserts a new paragraph
- ENTER+SHIFT inserts a line break

So what's up? How long should users wait until this ugly bug is resolved? Up 
to now this bug is more than two years old. And since two years all of my and 
many others users web pages include myriads of useless <br> tags. And I don't 
think that this is W3C compliant. 

PLEASE RESOLVE THIS BUG AND MAKE MANY USERS HAPPIER!!!!!!

I'm showing my support for fixind this bug by voting for it, I recommend others
to do so too.
*** Bug 143794 has been marked as a duplicate of this bug. ***
Is there any movement on this bug? 

I wish to use the htmlarea tool: 

http://www.interactivetools.com/products/htmlarea/

in a cms i use but since i can't customise the differences between the output
from midas and the component in ie its something i can't deploy.

Having <br /> tags appearing instead of paragraph breaks is a show stopper.



From
http://lxr.mozilla.org/seamonkey/source/editor/libeditor/html/nsHTMLEditRules.cpp#6269
it appears that making return split a paragraph would be easy. Making
shift-return insert a forced break is probably harder.
Attached patch make return split paragraph (obsolete) — — Splinter Review 
Here's a patch that makes return split the paragraph. It appears that
shift-return already inserts a forced line break.
Attachment #135128 - Flags: review?(mozeditor)
Comment on attachment 135128 [details] [diff] [review]
make return split paragraph

At a minimum this would have to be turned off for mailnews.  I'm also havnig a
tough time seeing why this is a "showstopper" for anything, since if you simply
hit return twice you get the paragraph split.  Finally, why did the signature
of SplitParagraph() change?
Attachment #135128 - Flags: review?(mozeditor) → review-
Regarding comments about the overwhelming majority preferring behavior foo...
that is the nature of bug reports.  Those who prefer the other behavior aren't
here and don't even know this bug exists.  Also, those who prefer the other
behavior are largely "mom&pop" types who don't understand html and just expect
their editor to behave naturally.  By and large they aren't bugzilla types.  The
bugzilla crowd is a tilted representation of the user base.

As the person who got hammered every time someone couldn't get a cursor to
appear in an apprently blank line (really vertical margin of paragraph) early on
in the editor development, I can assure you this "majority" is much more tenuous
than any of you realize.

There is no way we do this at all if it's not disabled for mail.  
> At a minimum this would have to be turned off for mailnews.  

Why? The patch doesn't affect the "body text" case where the user is writing
directly to the body. (Which is deprecated but that's the initial state of the
editor.) That is, if someone wants to use editor as a linebreak-based text
editor which just does fonts and colors, it is still possible.

> I'm also havnig a tough time seeing why this is a "showstopper" for 
> anything, since if you simply hit return twice you get the paragraph split.  

1) In an editor that has the concepts of paragraphs and headings, legitimate
forced line breaks are rare. The editor should not cause forced line breaks to
be inserted without an explicit request.
2) The general convention is that in apps that have the concepts of paragraphs,
headings etc. pressing return causes a block break--not a forced line break.
Mozilla violates this convention. The convention is followed by Dreamweaver,
FrontPage, Word and OpenOffice to name a few.
3) Properly marked up paragraphs are essential for useful styling. This bug
makes it harder to get properly marked up paragraphs.
4) This bug makes the behavior of Midas inconsistent with the editor widget of MSIE.

> Finally, why did the signature of SplitParagraph() change?

When the paragraph is split in any case, there's no need to pass a pointer to a
br node which is currently introduced by the first return. It would also be
possible to retain the signature and add a null check so that the br parameter
would be ignored if null.
> Also, those who prefer the other behavior are largely "mom&pop" types who 
> don't understand html and just expect their editor to behave naturally.

Is the mission of Composer to be a graphical HTML editor or a text editor with
colors and fonts which approximates the presentation with tag soup? The current
behavior is very unnatural for an app that is dealing with a stuctured document
as opposed to a long string with some styles bound to the characters.

> As the person who got hammered every time someone couldn't get a cursor to
> appear in an apprently blank line (really vertical margin of paragraph) 
> early on in the editor development

Does Composer have a UA style sheet of its own? Let's make that margin 0.5em so
it doesn't look like a blank line.
Actually, what I would do is have it return a linebreak only when the format is plaintext. If the mail 
format is HTML, the return should be a paragraph element, not a line break element. However, in 
mail/news, you could always have a default stylesheet with no spacing between paragraphs. 
It must be disabled for mail because novice users (heck, even non-novice users)
copy content from another page and paste it into mail without realizing that
paragraphs are being used in the underying markup.  Then they try to edit it.
Having different margin heights in Composer defeeats wysiwyg.
The purpose of Composer was to allow mom&pop to make a web page without having
to understand html.  The same html editing engine is used in mail compose, which
is designed to let people have rich content that does wysiwyg copy/paste with
web content (to the extent possible).  

Having the html weenies (myslef included) simply hit return twice seemed a small
price to pay.
Joe: Regarding comments about the overwhelming majority preferring behavior
foo... You are right that the opinions represented in bugzilla comments are
certainly not representative of the whole user base - that's exactly the reason
I filed bug 196264. Perhaps we should make this one depend on that. ;-)

But, I fail to see why inserting a paragraph break would be a problem for
anybody, especially considering that that's exactly what any word processor
does, and also considering that Outlook uses Word for message composition. Of
course, Word defaults to having no margins between paragraphs, so even naive
users don't have the problem of "getting a cursor to appear in an apparently
blank line". I think that's the way we should go, too, at least for MailNews.

Also, could you please elaborate on what the problem is when someone pastes
something from a web page and tries to edit it? Again, I fail to see any problem.

To be honest, I never used HTML composition (whether for emails or for a web
page) and don't know how exactly it works - does it provide user-friendly
editation of the stylesheet (like paragraph margins)? Does it include the
stylesheet in the composed message? And does hitting Enter two times really
insert a paragraph break, as you seem to be suggesting, or does it just insert
two line breaks, as would be expected behaviour? I tried to turn on HTML mail
composition to verify this, but for some reason it doesn't really send or save
an HTML mail, although it does let me compose one. I probably need to set some
more options that I just can't seem to find. (I tried to compose a page and two
Enters simply insert two BR's, not a P.)
Answer to henri:

> The current
> behavior is very unnatural for an app that is dealing with a stuctured document
> as opposed to a long string with some styles bound to the characters.

Do not even think again of a structured editor, Henri. We're not working on
DocZilla but on Composer... Structured editing is out of scope for 99% of 
our target users and only geeks like us have ever heard or read anything about
"structured documents".

Answer to Joe: 

> The purpose of Composer was to allow mom&pop to make a web page without having
> to understand html.  The same html editing engine is used in mail compose, which

The purpose of Composer **is** to allow anyone, including mom&pop, to make
a web page w/o knowledge of underlying technologies like HTML and CSS.
Vaclav:  In mail the issue only comes up if the user explicitly creates a
paragraph, or if they copy and paste one from elsewhere into their mail compose
window.  In either case, if the user types return in that para they will
experience the issues discussed previously.

Making para's have no margins in mail breaks wysiwyg between mail and the
browser, and even between mail and composer.

Mom and pop, plus anyone used to plaintext editing (like me) would find it
frustrating to suddenly discover that there was no obvious way to end a line
without an extra blank line appearing (as happens for paragraphs) on which you
can't even place the caret to delete it (see below).

Having a "return breaks paragraph" mode is cool (I doubt anyone would oppose
it), but making that the only behavior would lead to tons of bug reports
regarding mail editing.

Re Joe's comment 33:
> As the person who got hammered every time someone couldn't get a cursor to
> appear in an apprently blank line (really vertical margin of paragraph)

commenters to this bug may not be aware of the serious issue in bug 85505.  If
that layout bug could be fixed, then paragraph mode in composer could be a lot
less confusing and it would be easier to argue for making it the default at
least for web composition.
> It must be disabled for mail because

Is there a way to see whether the editor instance is in Composer, Midas or Mail
from within nsHTMLEditRules.cpp?

> Of course, Word defaults to having no margins between paragraphs, 
> so even naive users don't have the problem of "getting a cursor 
> to appear in an apparently blank line". I think that's the way 
> we should go, too, at least for MailNews.


Then there would be empty paragraphs between real paragraphs instead of forced
line breaks here and there. I think the way to go is to reveal the truth about
paragraphs and forced linebreaks to the user instead of trying to make things
look different from what they are.

> Do not even think again of a structured editor, Henri. We're 
> not working on DocZilla but on Composer... Structured editing 
> is out of scope for 99% of our target users and only geeks 
> like us have ever heard or read anything about "structured 
> documents".

I still want a structured editor even if only 1% cares. The question is, should
I expect to get a structured editor from the Mozilla codebase. Would any patches
working toward a structured editor be rejected even if their effect was toggled
with hidden prefs?

> The purpose of Composer **is** to allow anyone, including 
> mom&pop, to make a web page w/o knowledge of underlying 
> technologies like HTML and CSS.

I'd prefer the goal of allowing a person who understands the basic concepts to
make *quality* Web pages.

> commenters to this bug may not be aware of the serious issue 
> in bug 85505.  If that layout bug could be fixed, then 
> paragraph mode in composer could be a lot less confusing 
> and it would be easier to argue for making it the default at
> least for web composition.

I think bug 85505 (yes, I was aware of the problem) makes it even more important
to fix this bug. Since the HTML editor inserts unrequested <br>s all over the
document, content management systems that get content from Midas need to be able
to safely remove all <br>s in order to enforce markup quality and stylablity.
The paragraphs had better be marked up as real paragraphs in order survive the
<br> removal.
Im agree with Henri here. I would like to see Midas produce more structured code. 

Shouldnt Midas follow web standards like xhtml? Proper paragraphing is a step
towards this support.

I mentioned 'show stopper' in my comment because it is. We build many sites that
include a cms for editing. We can only provide an IE editor because the
differences with Midas are too great. 

Yes, i could probably write some code to some re-formatting to replace <b>,
<span ...> with my preferred xhtml <strong>, and to try to sense with <br> is
being used for a paragraph break. But this defeats the whole point of using the
editor. 





>I'd prefer the goal of allowing a person who understands the 
>basic concepts to make *quality* Web pages.

You can.  You can still use strong instead of bold if you want.  You can still
get paragraphs if you want.  Nothing talked about in this bug report is stopping
you.

I don't really understand the person who wants <strong> anyway.  That's really
no more structured than <b>.  When the user says "make bold" they aren't
thinking structure, they are thinking appearance.  Put Midas in css mode and get
<span style="font-weight: bold">.  That's the *real* standards weenie way to
interpret that user gesture.

To answer the question of what has a chance of making it in:
I will resist making these changes to mail at all.  Walk a mile in my shoes and
all that :-)
As for Composer, I'd prefer it to stay the way it is now so that it works the
same as mail, but I'm open to having return split paragraphs.  I still think it
is a bad idea, though.  You have that functionality already right now, and in a
way that doesn't confuse the novices.
As for Midas, I'd like for it to stay the same as composer.  I am interested in
maintaining compatibilty with IE, though.  It would be nice if webmasters could
serve up html edit widgets with minimal hastles over the different UA's.  I must
admit that I don't really understand why anything here is a problem though.  The
user can make <br>s in IE's widget too.  You have to be able to handle the same
html you would get from Midas right now, either way.
*** Bug 225544 has been marked as a duplicate of this bug. ***
How about we start with a compromise, and implement this feature so that there
is a pref to turn it on? Then, post to MozillaZine or something to advertise the
pref and ask people to test it out.
> You can still get paragraphs if you want.  

In practice it is too hard to be useful. Marking up stuff that logically
constitues a paragraph as a paragraphs should be as straight-forward as
possible. The user shouldn't have to explicitly want to have paragraphs marked
up as paragraphs or exert effort to get paragraphs marked up as paragraphs.

> Nothing talked about in this bug report is stopping you.

Actually, it is, but I tried to stay away from the the bug tactic #1 as numbered
by Hyatt (http://weblogs.mozillazine.org/hyatt/archives/2003_11.html#004358).

> Put Midas in css mode and get <span style="font-weight: bold">.  
> That's the *real* standards weenie way to interpret that user gesture.

No, **real** standards weenies don't use the style attribute *at all*. <span
style="..."> is just <font> in new clothing and on streroids. Putting
style="..." all over is another thing that bothers me, but that's off-topic for
this bug. If <b> is not wanted, the UI should not have a command "make bold".

> I will resist making these changes to mail at all.
...
> As for Composer, I'd prefer it to stay the way it is now so that it 
> works the same as mail, but I'm open to having return split paragraphs.
...
> As for Midas, I'd like for it to stay the same as composer.  I am 
> interested in maintaining compatibilty with IE, though.

So a patch that kept the current behavior in mail and made return split
paragraph in Midas and Composer would get in? Is it possible to check whether
the editor is in mail from with in editor? (How?) Or is it necessary to
introduce a way for mail to inform the editor after instantiation that the
editor instance in in mail?

> in a way that doesn't confuse the novices.

I think the situation where one return means <br> but two returns don't mean
<br><br> is confusing to pretty much everyone including novices.

> It would be nice if webmasters could serve up html edit widgets with 
> minimal hastles over the different UA's.  I must admit that I don't 
> really understand why anything here is a problem though.  

A content management system that is designed for structured and stylable output
and maintainable internal storage needs to enforce the use of real paragraphs.
The way real paragraphs are currently made in Midas is so strange that makers of
such CMSs can't trust the user entering content to make real paragraphs with Midas.

(Yes, banning <br> can work in practice. Since early 2001, the CMS of
macsanomat.com has not allowed <br> except in headings, address and inside
<code>, <samp> and <kbd>. The markup is always consistently stylable, because
everyone who inserts content in the database has to make proper paragraphs or
the CMS doesn't allow the content to get in. Our CMS also does not let any
element with the style attribute or any deprecated element enter the database.
Also, forms and scrips can't be entered in content.)

> The user can make <br>s in IE's widget too. You have to be able to 
> handle the same html you would get from Midas right now, either way.

With IE, the user has to do something knowingly in order to insert a <br>. If it
is documented that "forced line breaks (<br>) are prohibited" and there's a
preview of the entry with <br>s removed, the user can grasp what is going on.
However, if you take content from Midas and remove <br>s, chances are the result
confuses the user, because the default behavior didn't guide the user to use
real paragraphs.

> How about we start with a compromise, and implement this feature so that 
> there is a pref to turn it on? 

If it was a pref, CMS makers still couldn't count on getting real paragraphs
from Midas.
> No, **real** standards weenies don't use the style attribute *at all*. <span
> style="..."> is just <font> in new clothing and on streroids.

That's a joke I presume ? The cool thing with span is that you can apply multiple
styles to the selection without having to nest multiple elements. And span does
not add any kind of semantics to the selection.
So let me correct your assertion above: only *fanatic* standards weenies don't use
the style attribute. In the real world, in the real life, the style attribute
cannot be dropped.

> So a patch that kept the current behavior in mail and made return split
> paragraph in Midas and Composer would get in? Is it possible to check whether
> the editor is in mail from with in editor? (How?)

Check the flags that are passed to the nsHTMLEditor instance on Init() or
on SetFlags().

> I think the situation where one return means <br> but two returns don't mean
> <br><br> is confusing to pretty much everyone including novices.

Well, Netscape and AOL happened to disagree with that, with a lot of good
reasons. I also asked a few friends, including members of W3C Working Groups,
what they think about this. Most of them said "keep the current behavior".
So for the moment, I don't want to see this change in Composer.

<div module_owner_hat="on">
  I propose the following solution : add a new scriptable boolean attribute
  to nsIHTMLEditor. If false, then the editor follows the current behavior.
  If true, then one return key in a P creates a new P in Composer and Midas,
  BUT NOT IN MAIL CLIENT.
  I could even live with a pref, and to my own surprise, I can live with
  a visible pref, not necessarily hidden.
</div>


No, real standards weenies don't use the style attribute at all: they use the class attribute or id 
attribute and assign the styles in the style sheet so they can have different styles for different user 
agents.  

The suggestion for a pref is simply saving the phenomenon. The problem is with the default style 
for the paragraph element having a margin > 0.  If the mail editor's default style sheet had a 
margin of 0 for paragraph elements, there'd be no problems.  And if like all standards weenies the 
newbies used plaintext email and only used html mail when they knew what the effects would be, 
there'd be no problem. Like that would ever happen. 

Most word processors (and in a way an HTML composer/page editor is in the same genus as the 
word processor) have a default style with a margin of 0 for paragraph elments. But traditionally 
browsers have assigned a default margin greater than 0 to paragraph elements, and the default 
margin for the page editor has to reflect the traditional one for browsers. 

The only question is whether the compromise should be to force the MUA to follow the browser 
standards, or write bad markup for the browser to preserve the mail standards, or to split the two. 
It seems to me that the most reasonable compromise is to split the behaviors by having a different 
style sheet value for paragraph margin on the mail editor than you have on the HTML editor: the 
resulting effect, of the paragraph margin on text changing when the text is copied from mail to 
page editor, would be the easiest behavior to learn which would be consistent with standards.
> No, real standards weenies don't use the style attribute at all: they use the
> class attribute or id attribute and assign the styles in the style sheet so they
> can have different styles for different user agents.

At least one this point Microsoft's representative in the CSS WG, Tantek Çelik,
and I agree : we need the style attribute. And none of us can be suspected of
NOT being a standards weenie.
Using a class or ID (a) reduces the name space of classes or IDs (b) adds
semantics. <span style="font-weight: bold"> and <span class="foo"> with .foo {
font-weight: bold } are NOT the same in terms of semantics. The former adds no
semantics and one may want to annotate visually a document, for instance using
a bold font, without adding ANY kind of semantics to a doc.

Joe, you said: "Making para's have no margins in mail breaks wysiwyg between
mail and the browser, and even between mail and composer." Can you elaborate on
that? I assume that you mean that copying content from the browser to mail
wouldn't preserve formatting exactly, right?

But if that's what you mean, then that's already happening now! The problem is
that Mozilla won't copy the style sheet that is associated with the original
document (even if it's just the default stylesheet). That's a completely
different bug. Just try copying something from www.mozilla.org to the composer -
you'll get different fonts, different layout, different colours...

I don't see how this can even be a point of controversy. For Christ's sake, the
Enter key has always ended paragraphs since a line-wrapping text editor was
invented! Even with plain-text mail editing, you use Enter to end a paragraph:
until you hit Enter, you are writing a single paragraph that gets properly
re-wrapped as you add or delete text. If the problem is that users are confused
by the margin, then simply remove it - what can be simpler? The "wysiwyg
problem" (if I understand what you mean by that) is already occuring now, so
that will not be a major change. Is there any other problem?
regarding the side discussion of what is the super cool neato look at me way to
do bold:

I was referring to authoring tools when I said span/style was the way.  Of
course if you are hand rolling your own html/css you will likely have a
stylesheet rule in mind for your bold text, and will use that.  But if you are
writing an authoring tool, and all you know is that the user wants it bold, and
that they put your tool in css mode, then span/style is of course what you do. 
Let's just end that discussion right there, shall we?
Daniel:
>   I propose the following solution : add a new scriptable boolean attribute
>   to nsIHTMLEditor. If false, then the editor follows the current behavior.
>   If true, then one return key in a P creates a new P in Composer and Midas,
>   BUT NOT IN MAIL CLIENT.

I like Daniel's suggestion except for the last line.  

I agree we shouldn't use the <p> behavior in our own mailer, but let's leave the
editor flexible enough that people can use it as they choose.  It's not that
hard to add a separate flag with a clear name, rather than grouping lots of
disparate behaviors under a flag named "mail" (we don't even document which
behaviors are different when "mail" is set).

I propose just making it an attribute, period, set on each editor instance; and
that our mail client invokes the editor with the attribute set to br mode. 
Those embedding Midas get full control over which mode they want.

Vaclav:
> Joe, you said: "Making para's have no margins in mail breaks wysiwyg between
> mail and the browser, and even between mail and composer." Can you elaborate on
> that? 

I can answer that: not all mail readers (or browsers, for that matter) support
CSS reliably.  If we use <p> plus a stylesheet to make it look different from
the normal browser default, then what the sender thinks he's sending (using the
nonstandard stylesheet) may not match what the recipient sees (without the
stylesheet, or with it wrongly interpreted).
> I propose just making it an attribute, period, set on each editor instance; and
> that our mail client invokes the editor with the attribute set to br mode. 
> Those embedding Midas get full control over which mode they want.

Deal. That's in fact exactly what I proposed and why I wanted the attribute
to be scriptable and present on nsIHTMLEditor.
Akkana:
>> Joe, you said: "Making para's have no margins in mail breaks wysiwyg between
>> mail and the browser, and even between mail and composer." Can you elaborate on
>> that? 
> I can answer that: not all mail readers (or browsers, for that matter) support
> CSS reliably.  If we use <p> plus a stylesheet to make it look different from
> the normal browser default, then what the sender thinks he's sending (using the
> nonstandard stylesheet) may not match what the recipient sees (without the
> stylesheet, or with it wrongly interpreted).

Well, you could also say that not all mail readers support HTML reliably (or at
all, for that matter), and so we shouldn't allow sending HTML mails.

I suppose that anyone who uses a mail reader without CSS support must already be
used to seeing emails that are weirdly formatted, no? I just checked and it
seems that most HTML-formatted email that I receive are using CSS, so this would
be no new and unseen thing.

Anyway, obviously I can't change Daniel's and Joe's opinions, but I still would
like to see an argument that I can identify with, or that at least makes sense
to me.
> Well, you could also say that not all mail readers support HTML reliably (or at
> all, for that matter), and so we shouldn't allow sending HTML mails.

!!!

And we could answer that such an argument is completely ridiculous. Only geeks
use plaintext email, the vast majority of other users use richtext (html) email.
Anyway, for those w/o HTML email support, multipart/alternative is here.

We are trying to think of the future, not to go back to prehistorical tools.
Please, no more pre-1995 arguments like that one, I have the feeling to be back
in a 1993 IETF mailing-list's thread.

>> Well, you could also say that not all mail readers support HTML reliably (or at
>> all, for that matter), and so we shouldn't allow sending HTML mails.
> And we could answer that such an argument is completely ridiculous. Only geeks
> use plaintext email, the vast majority of other users use richtext (html) email.

But that was exactly my point! (Perhaps I should have explicitly said, "...but
such an argument would be ridiculous.") How many mail readers are there really
in use that aren't able to interpret <P>'s margin style? And if the answer is
"not a significant percentage", what's holding us from doing it the right way,
i.e. using Enter to mean end-of-paragraph as it does everywhere else, and
styling the paragraph to have zero margins to prevent problems with clueless users?

If you are going to do that why you <p> at all?  Use <div>, which already has a
default verical margin of 0px.  This is what most modern MS mail clients do, btw.
Using <div> for a paragraph break defeats the whole purpose of the bug. 
> If you are going to do that why you <p> at all?  Use <div>, which already has a
> default verical margin of 0px.

<p> means "paragraph". <div> doesn't. Using <div> when meaning paragraph is
wrong. (BTW, I don't think the default top and bottom margins of <p> should be
zero unless there's a non-zero text-indent. A margin of 0.5 em could help, though.)
There has been a lot of discussion on this topic, why not just grasp the metal 
and do what every body else does. ie if you press return you carry on with the 
same style eg if in <h1> press return adds </h1> then <h1> for new line. If you 
want a break <br> you do a shift return. Any idea when it may be implemeted?
nobody wants headers to split into headers.  that's why we went thru the trouble
to get u out if headers when u hit return.
I think the point I was making was missed. I have two niggles with Composer 
which from the previous discussions on this topic seem to have caused debate. 

The first is the fact that when in paragraph mode every return adds a <br> 
marker rather than a </p><p>. If you wish to do a <br> then the convention 
seems to be to type shift return.

Another issue is that the default paragraph style is body text, so when you 
exit any other style <br>s are added, whereas the more logical to me would seem 
to be paragraph style.

My reference to <h1> style was that it would seem to me to be good that once 
you select a style eg h1, h2 etc, you carry on in that style until you change 
your mind, as per Dreamweaver, and when you press return the appropriate 
terminator and same style opener are added. I often at the head of a page have 
the same paragraph style for perhaps the first two lines.

Hope that calarifies my comments.
Actually, I am wondering, after 2 years of staying open, after being "assigned"
(current status), will this bug be fixed, or would _I_ have to do it? ;-)  By
"fix" I mean, use the damn Word approach, it's known by more people that will
ever use Mozilla.

Oh, yes, I hate Word too; yes, I like starting a new paragraph with two
consecutive ENTER-s; yes, I don't like writing 2 headlines next to each other. 
But most people are not accustomed to these wonderful things and they prefer the
bad ol' Word behavior that they have learnt in highschool.
> will this bug be fixed, or would _I_ have to do it? ;-)

This is a weird comment, to say the least. If you _can_ do it, do it. If you
can't, that's not very funny. Even with a trailing smiley.
> This is a weird comment, to say the least. If you _can_ do it, do it. If you
> can't, that's not very funny. Even with a trailing smiley.

I know.. sorry, I meant no offense.  I'm sure I can "fix" it, but it'll take for
me 20 times more than it would for a Composer hacker.  But hey, I'll try ;-)

What I find funny is that this bug was discussed for about 2 years and a fix
isn't there yet.

PS.  I'm the developer of HTMLArea-3.0.  Many people complained that ENTER
inserts BR instead of P.  This is, as some call it, a "show stopper", meaning,
it prevents them from using HTMLArea-3.0 and--horror--many prefer to use
HTMLArea 2.x which only works with IE!  Now, I tried several times to manipulate
this whole thing using DOM (catch ENTER and doing crazy things there) but
without any luck (yep, it's hard) so I came to think that it would be much
better to have it in Composer directly.
I would like to see [Enter] insert </p><p> and [Shift]+[Enter] insert <br>.  I
understand how this might confuse novice users since I have observed their
confusion myself.  However, I don't think that we have to "throw the baby out
with the bath water" in order to solve the problem.  With the hope on
encouraging the exploration of other possibilities, I'd like to suggest the
following.

Create a special caret position after the end of a paragraph.  For left-to-right
pages, this position would visually place the caret such that its center aligned
with the intersection of the paragraph's left and bottom margins.  With this
special position available, the following behaviour would be observed:

1) pressing [Shift]+[Enter] inserts a <br>.

2) pressing [Enter] within a paragraph, including the position immediately after
the last visible entity in a paragraph, would insert </p><p> and place the caret
in this special position

3) ) from this special position, pressing [Enter] would insert <p></p> and place
the caret within the new paragraph

4) a mouse click over the bottom margin of a paragraph or the top margin of
whatever entity follows would place the caret in this special position

5) cursor forward from immediately after the last visible entity in a paragraph
would place the caret in this special position

6) from this special position, cursor back would place the caret immediately
after the last visible entity in the paragraph

7) from this special position, cursor forward would place the caret immediately
before the first visible entity after the paragraph if any exists or at the
beginning of a new line if none exists

8) from this special position, adding text would first insert a new paragraph,
placing the text within the new paragraph

9) from this special position or the position immediately after the last visible
entity in a paragraph, [Delete] would: a) destroy any following display:block
entity (except tables and div's) and incorporate the contents into the paragraph
leaving the caret at the point of merger. b) incorporate all following
display:inline entity, up till but not including the next display:block entity,
into the proceeding paragraph leaving the caret at the point of merger {i.e.
<p>paragraph</p><h1>header1</h1>text becomes <p>paragraphheader1</p>text and
<p>paragraph</p>text<h1>header1</h1> becomes <p>paragraphtext</p><h1>header1</h1>}

10) from this special position or the position immediately before the first
visible entity after the paragraph, [Backspace] would behave the like [Delete]
as described in 9 above

I think this might provide even the most novice user the visual clue needed to
allow them to understand the behaviour regardless of whether paragraphs have a
margin equal to or greater than zero.
Ok, I even tried to solve this problem using dom-Methods and htmlArea 3 - but 
without any Achievement. Hey, but there are some guys who solved it: Take a 
look at the mozile-Project! By using eDom they have exactly that behaviour 
everyone here wants....
Even those guys developing a striktly-mozilla program think it is the right 
way. 
The Problem: Mozile is a solution working only in Mozilla - but I need 
something working in both worlds (ie and moz) - so htmlArea from Mihai Bazon is 
a good solution for me. So please help to fix it - even directly in Mozilla or 
writing a workaround using dom.....
Blocks: 47544
Just another note that our company and all of our users fall STRONGLY on the
side of at least having <p></p> as an option. This bug is in fact a show stopper
for us and we are forced back to using IE-only solutions. :-(  Someone on the
HTMLArea3 forums has posted a complicated patch using DOM manipulation, but man,
why can't we just have this as an "option" in the core? I don't even care if it
is not the default option, but we simply can't use the Moz editor until there is
a way to provide proper <p></p> tags. 
Taking. Joe, I presume you don't mind...
Assignee: mozeditor → daniel
Status: ASSIGNED → NEW
fix pending
Status: NEW → ASSIGNED
Attached patch full fix (obsolete) — — Splinter Review 
Nah. Happy now ? Seeking reviews.
Attachment #135128 - Attachment is obsolete: true
Attached patch full fix #2 (obsolete) — — Splinter Review 
forgot to deal with one case... Still seeking r/sr from whoever.
Attachment #141535 - Attachment is obsolete: true
(In reply to comment #76)
> Created an attachment (id=141537)
> full fix #2

I've tested this patch with CVS head. After setting editor.CR_creates_new_p I
get <p> with enter in Composer. However, with Midas (at least with
http://www.mozilla.org/editor/midasdemo/) i still get <br />.

Is there something additional that has to be done to change the Midas behaviour,
or is a separate patch reqired to get the <p> behaviour for Midas?
Comment on attachment 141537 [details] [diff] [review]
full fix #2

Please forgive my lack of familiarity with this code, and questions that might
be obvious ... I thought I'd give the review a try if Joe is busy, since this
fix is in demand.

I tested it and it seems to work fine, and doesn't affect plaintext (which it
shouldn't) or text inside pre (which I hope means it won't affect plaintext
mail compose, though I didn't test that explicitly -- I hope someone has).

>+      result = prefBranch->GetBoolPref("editor.CR_creates_new_p", aReturn);

I was going to ask that this be tied to an observer, so it will pick up changes
that happen at runtime ... but it looks like we don't have observers for other
editor prefs either. :-(  (I thought we did?)

>+        offset++;

Why does the offset get incremented in the end-of-text-node case, but not in
other cases, and not in the old code?

>+        nsCOMPtr<nsIDOMNode> tmp;
>+        res = mEditor->SplitNode(aNode, aOffset, getter_AddRefs(tmp));
>+        if (NS_FAILED(res)) return res;
>+        aNode = tmp;
>       }

We don't need to return even though we've just split the node?	Won't we end up
calling SplitParagraph at the end after we've already split this node?
(In reply to comment #78)

> (From update of attachment 141537 [details] [diff] [review])
> Please forgive my lack of familiarity with this code, and questions that might
> be obvious ... I thought I'd give the review a try if Joe is busy, since this
> fix is in demand.

No problem Akkana! And thanks for jumping on that!

> I tested it and it seems to work fine, and doesn't affect plaintext (which it
> shouldn't) or text inside pre (which I hope means it won't affect plaintext
> mail compose, though I didn't test that explicitly -- I hope someone has).
> 
> >+      result = prefBranch->GetBoolPref("editor.CR_creates_new_p", aReturn);
> 
> I was going to ask that this be tied to an observer, so it will pick up changes
> that happen at runtime ... but it looks like we don't have observers for other
> editor prefs either. :-(  (I thought we did?)

We have a few in JS code (see editor.js) but I don't think we have in c++ code.

> >+        offset++;
> 
> Why does the offset get incremented in the end-of-text-node case, but not in
> other cases, and not in the old code?

Because the old code was stopping there. We don't. We continue and hope to 
SplitParagraph(). That method takes a BR node as argument and splits at that
BR's location. I did not want to change that since we may have to use it
elsewhere. So my code splits the node in two if it's a text node, inserting
a BR and then defaults to SplitParagraph. If the node is already a BR then
we just have to position right after it for the purpose of SplitParagraph.

> >+        nsCOMPtr<nsIDOMNode> tmp;
> >+        res = mEditor->SplitNode(aNode, aOffset, getter_AddRefs(tmp));
> >+        if (NS_FAILED(res)) return res;
> >+        aNode = tmp;
> >       }
> 
> We don't need to return even though we've just split the node?	Won't we end up
> calling SplitParagraph at the end after we've already split this node?

We need to split the text node and insert a BR prior to calling SplitParagraph.
Just a quick question. Daniel, is it true from Håvard's comment that this fix
doesn't apply to midas?
There has been a long discussion on this topic and my understanding is it has 
been decided to add a fix so you can have <p> instead of <br>.

I have just downloaded version 1.7b and Composer still works the same as ever. 
I also notice below here the status says FIXED.

Has it been fixed?

If so how can a non-expert activate the fix. Hope somebody can help.
In Midas it should be an option like
document.contentWindow.handleReturn = "P";
or if the P-tag will be used by default in future
document.contentWindow.handleReturn = "BR";
(In reply to comment #82)
> In Midas it should be an option like
> document.contentWindow.handleReturn = "P";
> or if the P-tag will be used by default in future
> document.contentWindow.handleReturn = "BR";

Conceptually, this is more a boolean called  returnInBlockSplitsBlock.
Comment on attachment 141537 [details] [diff] [review]
full fix #2

brade, can you r= please ? Thanks.
Attachment #141537 - Flags: review?(brade)
Comment on attachment 141537 [details] [diff] [review]
full fix #2

in general:
 * I'm concerned how this will impact Midas (rich text editing).  For the time
being I'd like Midas  behavior to not be affected.  Ideally we'd also have a
command that would allow the behavior to toggle (similar to the useCSS
command); this part is a separate bug (can be assigned to me).

in nsHTMLEditor.cpp:
 * Rename mForceCRdoesNotCreateNewP; it's confusing with the "Not"
 * Fix "\ No newline at end of file"

in nsHTMLEditRules.cpp:
 * Remove extra blank line around line 6287.

more later...
I've been contemplating the preference related code and I don't like how it is
set up.  I'd prefer to see the pref tied to a particular application (Composer,
Firebird, NVu, etc) rather than the core library.  The application can use a
pref to determine which flags it sets on the editor.  The core library shouldn't
need preferences.

Daniel--thoughts?
I haven't looked at the patch in much detail, but could it be done the way we do
things like line length for plaintext mail output, or other wrap settings: offer
an API for an app to set one mode or another, with a reasonable default in case
the app doesn't specify it, and then each caller can choose to have a pref if it
chooses?  That way it would be possible to have different settings for several
different editors active simultaneously, rather than having one app-wide setting
that might not be appropriate for all.

It looks like the API is already there in Daniel's patch, so the only issue is
that instead of the code in
nsHTMLEditor::GetReturnInParagraphCreatesNewParagraph which rechecks whenever
!mForceCRdoesNotCreateNewP (why does it only recheck in that case?), perhaps it
could have something composer-specific (perhaps in the JS) which checks when a
new composer window is open (and it should check regardless of the current
initial value of the pref), and then no check would be needed there in the
backend code?
Comment on attachment 141537 [details] [diff] [review]
full fix #2

Obsoleting to answer brade's and akkana's comments
Attachment #141537 - Attachment is obsolete: true
brade, akkana: I am factorizing pref listeners in editor.js, will add a new one
for the pref mentioned above, and will change the core so it does not have to deal
with a pref.
This new patch adds the UI for the pref's control in Seamonkey :-)
Comment on attachment 156598 [details] [diff] [review]
fix #3, in answer to brade's and akkana's comments

brade, can you r= please ?
Attachment #156598 - Flags: review?(brade)
*** Bug 256867 has been marked as a duplicate of this bug. ***
Comment on attachment 156598 [details] [diff] [review]
fix #3, in answer to brade's and akkana's comments

in Index: editor/libeditor/html/nsHTMLEditor.h, can you add the boolean to be
next to another boolean so packing might occur (or is that the only logical
place in the structure)?
Attachment #141537 - Flags: review?(brade)
Attachment #156598 - Flags: superreview?(jst)
Comment on attachment 156598 [details] [diff] [review]
fix #3, in answer to brade's and akkana's comments

r=brade if you fix the issue in comment 93

(jst hopefully can sr= this soon)
Keywords: relnote
Comment on attachment 156598 [details] [diff] [review]
fix #3, in answer to brade's and akkana's comments

sr=jst (and marking brade's r+ too, I'll attach a patch  that fixes the issue
she commented about, and removes 10 unused variables (!) while I'm at it).
Attachment #156598 - Flags: superreview?(jst)
Attachment #156598 - Flags: superreview+
Attachment #156598 - Flags: review?(brade)
Attachment #156598 - Flags: review+
Make that "10 unused member variables", even.
Carryying forward r=brade and sr=jst
Attachment #170503 - Flags: superreview+
Attachment #170503 - Flags: review+
Fix landed on the trunk. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
jst asked me to have this re-opened. I tested it in Mozilla 1.8 beta, and it is 
*almost* fixed. There are numerous problems with the current fix:

- There is an option so you can choose if you want buggy behaviour (br) or
correct behavior (p) in the prefs (which I can live with)
 
- Problem is, the buggy behaviour is the default (it inserts <br> instead of <p>
 
- To add insult to injury, the checkbox for buggy behavior (<br>) can't be
switched off on the Mac build of Moz because of widget rendering issues.

I'm not looking forward to telling people "oh, btw - all Mozilla users have to
go to their prefs dialog and switch off the checkbox to use
$WEB_BASED_CMS_SYSTEM_X properly". 
 
There are numerous standards and accessibility reasons to having <p> be the 
default too, if you need references to this, I can dig them up. I believe this 
point has been flogged to death in this thread already, so I won't repeat the 
arguments.

Can we let the default be <p>, and then the <br> guys can adjust their prefs if 
they like linebreaks instead? Being consistent with every other browser and word 
processing app on the planet sounds like a sane default to me.

Disclaimer: I have a special interest in this bug since we produce an open 
source CMS system, and we still can't recommend Mozilla/Firefox as the preferred 
browsers in large enterprise CMS deployments because of this tiny issue. If 
Mozilla could insert <p> by default, we could. I have been tracking this bug for 
over 2 years, and when it's this close to being fixed, I believe it should be 
done properly.

Sorry if this comes across as a rant, but it is very important to all the web-
based CMS vendors out there that this behaviour is corrected.

I couldn't have put it better myself.

"<p>" must be the default, or otherwise allow changing this through
JavaScript--please don't make me tell users to dig about:config about that.. :(

OTOH, as I was saying in a previous comment, the wait was too long :-(  I did it
myself--but in my JS code.  Therefore, HTMLArea works pretty well around this
issue even with older Gecko-s.
Blocks: 285873
Alexander/Mihai, I've added a new bug 285873 to track the change of the default
pref.
Is this fix in 1.8b2?  I've downloaded the beta and set the pref, but Midas
still appears to be inserting <br>s everywhere.
Blocks: 294164
(In reply to comment #102)
> Is this fix in 1.8b2?  I've downloaded the beta and set the pref, but Midas
> still appears to be inserting <br>s everywhere.

See bug 322202


Not fixed in SeaMonkey 1.0 running on MacOS 10.4.4

1. Open SM
2. Check Composer prefs: "Return in a paragraph always creates a new paragrah" is already checked on.
3. Open new Composer window.
4. Type in this:
This is a test.
This is the second paragraph.

The third paragraph has an extra newline between it and the second
paragraph.

5. The result in the source is this:
This is a test.<br>
This is the second paragraph.<br>
<br>
The third paragraph has an extra newline between it and the second
paragraph.<br>
<br>

(In reply to comment #104)
> Not fixed in SeaMonkey 1.0 running on MacOS 10.4.4

Similarly in Thunderbird 1.5 (20051201) on Windows. The editor.CR_creates_new_p pref is present but has no effect -- I still get <br>s.
Bug 330891 is about the failure of the HTML mail composer (Seamonkey and TB) to 
abide by this bug's pref.
I see the status is "FIXED" but Return still creates <br> and not <p>. I tried "editor.CR_creates_new_p" variable but it has no effect. (Is it the proper name?) 

Am I missing something? Could anyone enlighten me please?

Also I don't think user should be forced to dig this preference in about:config; Return->P and Shift+Return->BR is how this usually works.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: