92231 - problems formatting text that flows to next line

Status: RESOLVED WORKSFORME

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

Description

[Ben Ruppel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010724
BuildID:    2001072403

This is pretty hard to explain, but it's annoying and not knowing the workaround
could frustrate users.
This problem is with lines of text that are automatically wrapped down to the
next line in mozilla's text boxes (such as the Description text box I'm using to
enter this description in bugzilla).  This happens when one types or pastes long
lines from another app (like notepad).

If I go to the beginning of one of these lines that was wrapped down from the
previous line and hit the space bar to indent the text, nothing happens.  The
workaround is to hit enter to break the flow, but this isn't very intuitve and
I'm not sure that it's the correct behavior.  It looks like the textbox is
trying to be smart by not letting the spaces mess with its linebreaks, but
perhaps a "stupid" textbox would be better.

Reproducible: Always
Steps to Reproduce:
1.find a multiline textbox (such as those in
http://www.mozilla.org/quality/help/bugzilla-helper.html )
2.type in a long sentence and let your typing automatcially wrap to the next line.
3.move your cursor to the beginning of that next line
4.hit space

Actual Results:  nothing happens

Expected Results:  the text would move forward because you entered a space in
front of it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Does this actually work the way you want in any other browser?  Mozilla used to
have the "dumb" text box that you propose and bugs were getting filed on it all
the time (bug 19265 and all its duplicates).

Comment 2

[Ben Ruppel]

It works the way I want in NS4.x.   IE6 does some crazy stuff with putting the
spaces on the previous line.  The way it works now, Mozilla just ignores the
inserted spaces.  
I looked at 19265 .  I wouldn't ask for a "dumb" text box anymore, but I think
it's just a matter of the textbox counting spaces inserted on the next line as
part of the next word, and not the end of the previous word.  Should I send this
bug over their way or something?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Over to editor

Comment 4

[rubydoo123]

talked with Kin and reviewed the issue, off to layout

Comment 5

[Ben Ruppel]

Thanks for looking into this :)

Comment 6

[Marc Attinasi]

I know this problem well. It is a little worse than described because, if I type
a bunch of spaces at the beginning of a wrapped line, they do not show up, but
when I go to the line above and add more text so that the line wrap changes, the
spaces then show up in the middle of the next line.

I guess the problem is that we are collapsing the spaces when they are at the
beginning of the line, but not when they are preceeded by some characters.

I'll accept this though I do not see yet how it is a layout problem (I'm
admitedly not too familiar with the edit control), but I cannot give it much
priority at this time. Also CC'ing rods since he is into form controls in a big way.

Comment 7

[Robert Crews]

I've been encountering a similar problem for as long as I've been using Mozilla,
which is now nearly a year. The problem I'm encountering seems to manifest in
any text area throughout Mozilla. It's most noticable for me in mail
composition, but also in text areas in forms (like the one I'm typing into right
now).

The problem is that occasionally, when I hit the enter (carriage return) key,
the cursor moves down two lines rather than one. Hitting delete moved me back
one line, but then another immediate Enter will drop me down another two lines.

This is hard to reproduce, but it happens to me very often. It's most noticable
in the following situations:

 o replying to an RTF mail message sent by Microsoft Outlook
 o replying to a text message when I hit the enter key after the text
   has wrapped at least once on its own
 o when I edit text that I have cut or copied from another Windows
   text editor and then pasted into a Mozilla text area

I should mention that I compose mail in text-only mode. No RTF formatting, no
HTML formatting. I assume that I'm using the same text widget for composing mail
as most people use to edit text in form text areas.

I'll also be so bold as to provide my theory as to why this is happening:

I think Mozilla is not throuroughly assuring a consistant line-ending convention
for pasted text, entered text, and mail text. My guess is that internally,
Mozilla works with single-character line endings, but doesn't always remove one
of the <cr><lf> pairs from Windows text.

Remember that Windows ends lines with <cr><lf>. Mac OS ends lines with <cr>, and
Linux, <lf>.

(At this point, I pressed Enter and had my cursor drop two lines instead of one!)

So to support Mac OS, you simply have to replace <cr>s with <lf>s, but for
Windows, <cr>s, if they preceed a <lf>, need to be deleted. If Windows <cr>s get
replaced with <lf>s, then the text ends up containing <lf><lf>: two returns!

Anyway, that's my problem and my theory. Hope it helps.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This seems related to bug 88024 and may even be partially fixed by that fix... 
Would people retest with current (Oct 10 2001 or later) builds?

Comment 9

[Ben Ruppel]

Using October 11 builds, this problem is still there.

Comment 10

[Marc Attinasi]

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.

Comment 11

[Makoto Kato [:m_kato]]

old bug.  down to P3

Comment 12

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

I guess that was caused by layout issue. Anyway, I don't reproduce this bug anymore.