202444 - preformatted is painful

Status: RESOLVED DUPLICATE of bug 92921

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

Description

[Akkana Peck]

I've been trying to work with preformatted blocks lately -- writing documents
containing preformatted code or pseudocode -- and it's very painful with
composer, because of the <br> vs. newline munging.  I understand the reason for
the munging, but it makes the editor incredibly difficult to use -- even not
being able to select blank lines, while annoying, would be far less painful.

Two main problems:

1. Changing non-pre into pre (creating the block in the first place). Type:

one<return>
two<return>
three

Highlight all three lines and make preformatted.  You end up with three separate
preformatted blocks separated by whitespace.  Not right at all.  And I've never
managed to clean up one of these messes without going into source mode.  This
also happens on copy/paste or drag/drop from a non-preformatted block into a
preformatted block.

Is there a workaround?  I've ended up exporting the text to plaintext and
opening it in some other app, typing some bogus characters into the editor,
making them preformatted, copying from the plaintext app and pasting into the
middle of the bogus chars, then deleting the bogus chars at the beginning and
end of the block I just made.  Is there an easier way?

2. Line length.  There are no newlines anywhere in the html source in a
preformatted block.  Not only does that make the source impossible to read and
maintain, but more important, it means that a lot of mail and news servers will
refuse to send it because the line length is too long.  I've tried going into
source mode and adding newlines, but editor stomps them later.  The only
solution I've found is to split the pre into several different pre blocks (in
source mode) and put newlines between them.  But in this document I was using a
visible style on <pre> so it was obvious where the blocks behan and ended, so
splitting the pre had a visible effect, not what I wanted.

I can't remember -- have we ever talked about having a serializer mode to always
map <br> to NS_LINEBREAK at output time?  (Hmm, if NS_LINEBREAK is \r\n will
that show up as two lines, or just one?)  That would be a hackaround for problem
2 though it wouldn't fix problem 1.

Compare bug 92921, which says we should stop doing the br substitution: fixing
that bug would also fix this one, but I'm filing this separately because if we
don't stop using br, then these user-visible bugs should be fixed.

Comment 1

[sairuh (rarely reading bugmail)]

akkana, do you remember the last build ID/time when this wasn't as problematic?
just wondering if it's a regression.

Comment 2

[Akkana Peck]

Nom editorbase.

Comment 3

[Akkana Peck]

Sorry, I don't know whether this is a regression or not.

Comment 4

[Joe Francis]

It's not a regression.  Mozilla has been this way from very early on.

Comment 5

[Joe Francis]

plussing per eb+ meeting

Comment 6

[Alex Stewart]

Main problem #1 is bug 195089. The workaround is to make the paragraph
preformatted before you paste.

This bug should only address problem #2.

Comment 7

[Makoto Kato [:m_kato]]

old bug

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Let's manage this issue in bug 92921.