109935 - Mozilla message quoting should be like Netscape 4.x

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Felix Miata]

Preferences set to automatically quote and start message after quoted material,
automatically append .sig from existing file, and text format composition. Modern.

When I use PgUp to strip unnecessary portions of quoted material prior to
beginning message insertion via keyboard, the screen scrolls up only to the
extent multiples of whole windows are available above the viewable portion.
Unlike in Netscape 4, which will place the cursor at the very start of the
composition window if the PgUp key is help down long enough, Mozilla will stop
before the top of the composition window is reached. Then, when any cursor key
is struck after the PgUp key is released, and without any mouse intervention,
the cursor and view window return to the previous position, following the last
of quoted text.

This is not the only cursor location problem in composition, but I don't have a
firm handle on how to describe further. Suffice to say that it involves CR/LF
handling/display, resulting in missing or extra blank lines in messages sent. I
try to delineate paragraphs with single "blank" lines, but with Mozilla, sent
messages typically have too many, too few, or misplaced "blank" lines.

Comment 1

[Dimitrios]

Reporter, "Fubar Cursor - Returns to Bottom after PgUp" is covered by bug 4302.
Other problems must be filed in separate bugs (along with essential information
like the build ID you are using).

Comment 2

[Felix Miata]

Who would have guessed that a search on the single word "cursor" would have 
returned "zaaro boogs"?

I thought that the input form correctly telling me I was using the build to 
which the bug applied meant it had automatically included it: OS/2 2001110911. 
Why does it bother if it doesn't intend to include it?

The problem of mishandling CR/LF remains. Can we change summary line to "fubar 
cursor - mismatch to actual (CR/)LF instances".

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Why does it bother if it doesn't intend to include it?

Because it initializes your platform and operating system from that string. 
Assuming that the build you report with is the one the problem was in is bad,
however...

This is your bug.  You can change the summary as you see fit.  :)

Comment 4

[Felix Miata]

Maybe the form show ask if the build recognized is the one that should be 
reported, a check box to autofill a build field?

It wasn't obvious to me that the summary field was intended to be editable. Are 
previous comments removable?

Comment 5

[Kathleen :Brade]

The blinking line where you type is called a "caret"
The graphic that moves around on the screen based on mouse movement is called
"cursor".  Bugzilla uses these terms pretty consistently.

If you are seeing problems when pressing an arrow key and not having the caret
do what you expect, you should query for "arrow"

I hope that helps.

Comment 6

[Felix Miata]

Maybe there are two different things on a Mac, but on a every IBM PC compatible
with every OS I have used, the cursor is the blinking thingie that pinpoints
point of focus where the next keyboard action would follow, and that thingie
does not look like any caret I have ever seen. A caret is "^", but a cursor in
text mode is usually a "_", sometimes a solid box, or in a Wintel PC GUI, a
vertical bar.

A mouse pointer is a mouse pointer, not a cursor.

On an IBM compatible PC with focus in a text entry field, PgUp/PgDn normally
cause both screen and focal point (cursor position) to change. This should not
be different in Wintel Mozilla than other apps. When focus is a text entry
field, hands are on keyboard. They should not need to reach for a pointing
device to achieve massive pointer movement, or anything else until the text
entry is no longer the wanted focus.

The "arrow" keys work fine. Arrow keys (and PgUp/PgDn keys) are for moving the
cursor. The PgUp/PgDn keys are fubar. Query on "arrow" makes no sense.

If you want plenty more bug dupes because most of the world's IBM PC compatible
users are seeing blinking cursors rather than blinking carets, by all means
strip the keyword "cursor" from the summary line. Programmers can use whatever
names they want taking to each other, but if they want usable input from the
rest of the world, they need to understand the language the rest of the world uses.

Comment 7

[Kathleen :Brade]

Reference:
 page 268 of Charles Petzold's "Programming Windows 95" contains the subheading
"The Caret (Not the Cursor)"

This is a duplicate of #4302

*** This bug has been marked as a duplicate of 4302 ***

Comment 8

[Felix Miata]

This bug was a multipart bug when I originally filed it. The portion matching
bug 4302 is no longer at issue in this bug.

This bug is about mishandling of (carriage return/)line feed pair(s) when
composing email replies. While composing reply email/news post, some line feeds
are duped, while others are ignored. Until you hit send and look at your file
copy, there's no way to know if you got what you wanted. Apparent wrap during
composition does not necessarily indicate the wrap to be applied during send,
even though composing full screen with auto wrap in prefs set to 72.

The meaning of cursor predates Petzold's windoze 95 book by at least 10 years.
It was taught to me in college in 1973. Try reading Peter Norton's 1986 book
"Inside the IBM PC" on page 190 in his sidebar "The Cursor": "Normally the
cursor blinks at the bottom of a character on the last two scan lines."

Comment 9

[Mike Kaply [:mkaply]]

We need a specific sequence to type into composer to see the problem or we can't 
reproduce it.

Comment 10

[Felix Miata]

I went with 2001113019 to news:netscape.public.mozilla.os2 with fixed font 12
point system monospaced, automatically quote, and reply on bottom, set in prefs
and chose my first 2001113019 message from among the available message headers
displayed. Display of message body is fubar (still using 2001113019), but I hit
reply anyway.

Composition cursor drops to sixth row in composition window, with a blank line
above, a blank line below, the "--" starting .sig under that, and four nonblank
rows above the first blank row, having stripped the .sig from the parent
message, and *not* including a blank row following the "Felix Miata wrote:".

This is quite unlike 4.61, which leaves one blank line above, but no blank line
before the "--" at start of sig below, includes the whole .sig from the parent,
plus a blank line below "Felix Miata wrote:"

Goals are 1-to eliminate the blank row trailing the cursor, 2-eliminate the row
beginning with ">" that contains nothing visibly else, and 3-insert a blank row
following  "Felix Miata wrote:", and have these changes faithfully reproduced in
the final result by viewing the file copy and seeing that the added and deleted
lines have been in fact added and deleted as intended; all in addition to 4-the
composition of new text body.

Overall intention composing is to have single blank rows designate paragraphs.
Mozilla makes this rather difficult in practice. The results aren't very
predictable as regards row deletion with the BS or DEL keys and replying to
larger more paragraphed messages.

I tried to actually do as written above, but Mozilla claimed to have failed to
successfully send the message to the newsgroup, and closed the composition
window on failure instead of leaving it open for retry.

Comment 11

[Felix Miata]

The (Modern) Mozilla mailnews message send failure just reported applied only to
the newsgroup component of the send. The CC to myself received with Netscape
2.02 mail came through with an extra blank line above the new text, two blank
lines separating the paragraphs rather than the desired single blank line.

Comment 12

[Mike Kaply [:mkaply]]

To summarize (cursor indicated with vertical bar)

Here is a 4.61 reply:

-- Begin 4.61 reply --
Felix Miata wrote:
> 
> News. Message body pane mostly displays just jibberish, mostly one
> character per every other or third line. Default pane layout. Modern.
> --
> "Those who would give up essential liberty to purchase a little
> temporary safety deserve neither liberty nor safety." Benjamin Franklin
> 
>  Team OS/2 ** Reg. Linux User #211409
> 
> Felix Miata  ***  http://mrmazda.members.atlantic.net/

|
-- 
Michael Kaply
IBM Mozilla Advocate
Platform Owner - Warpzilla

-- End 4.61 reply --

Here is a Mozilla reply:

-- Begin Mozilla reply --
Felix Miata wrote:
> News. Message body pane mostly displays just jibberish, mostly one
> character per every other or third line. Default pane layout. Modern.
> 

|

-- 
Michael Kaply
IBM Mozilla Advocate
Platform Owner - Warpzilla

-- End Mozilla reply --

The issues are:

1. Why do we remove the poster's signature?
2. Why do we add an additional blank quoted line?
3. Why do we add an extra line before the signature?
4. We should add a line after the poster's name (Felix Miata wrote)

These are all cross platform issues.

Comment 13

[Felix Miata]

Since this is cross platform, reference to 4.61 in subject seems too narrow.

Comment 14

[Jon Roland]

This may be a place to suggest my preference that the user have the option of
selecting a "bracketed" quote, surrounded by lines of preselected bracket
characters, instead of an indented quote, and be enabled to pre-select the
bracket or indent characters. Bracketing preserves the nested quote structure
while enabling readers to more easily copy and paste quoted material without
having to remove the indent characters, and avoids the wrapping of deeply nested
quoted lines.

Comment 15

[Felix Miata]

Why does Mozilla put all the extra blank lines that N4 never did? Mozilla
message quoting looks terrible.

Date:  Tue, 09 Sep 2003 03:01:27 -0400
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

third poster wrote:

>second poster wrote:
> 
>  
>
>>first poster wrote:
>>    
>>
>>>Surely someone must know. Why does the X tool even exist if it can only
>>>get the job done for the person who wrote it, if even then? I don't mind
>>>using cli at all, but my goal was to figure out the X tool. I've gotten
>>>nowhere with that?
>>>
>>This tool is not meant for cooker use.  It is meant for keeping a
>>    
>>
>
>So how does it get tested during cooker/beta/rc to ensure that it works
>with GA?
>

I agree with you on this.  I've asked myself the same thing.

>>released version up-to-date.  It is assumed (possibly incorrectly) that
>>if you are using a cooker version of Mandrake that you are aware of this
>>and know how to keep the machine up-to-date.
>>    
>>
>
>Everyone who does had to get there somehow. Unless I'm missing
>something, no one is born knowing how.
>

My child will. ;-)

>>Are you new to Linux or Mandrake?  If so, you're diving in pretty deep
>>    
>>
>
>Define new? My first Linux install was RedHat 5.2. My first Mandrake
>install, 7.1. My first Mandrake beta testing, 8.0. My first cooker, last
>Friday, after rc1 wouldn't install except as upgrade from 9.1.
>

Unless I'm reading it wrong, and every version of Linux in the paragraph 
above reads "Mandrake Linux 9.1", we both know what "new" is.

>>by running a test version of anything Linux.  It may be better to run
>>something that is ready for those that are experiencing Linux or
>>Mandrake Linux for the first time.  If not, knock yourself out. :-)
>>    
>>
>
>I cobbled the box purely for testing Mandrake cooker/beta/rcx. I learned
>over the past several Mandrake beta versions that if I want to actually
>use Mandrake for normal things, to only use releases, and to experiment
>with something else. So, I have this box running OS/2 24/7; a box with
>W98, OS/2, & RedHat 9 used mostly for W98; a box with W98, OS/2 & RedHat
>6.2, used for little more than my EPROM burner; a box with DOS, W2K,
>OS/2, Mdk 7.1, Corel 1.1, RedHat 7.3 & Mdk 9.1, used mostly for Mdk; and
>the new (slow, 200 MHz) box for cooker.
>

Lots of info, yet no answer.  So are you new or not? ;-)

Comment 16

[Mike Cowperthwaite]

(In reply to comment #12)
> The issues are:
> 
> 1. Why do we remove the poster's signature?

I thought this was done by design (but it's not done when replying to HTML 
messages); whether or not this is true, this is bug 120644.


> 2. Why do we add an additional blank quoted line?

See bug 70728, bug 144998, bug 178899 -- but I don't think any of those apply 
directly.  Maybe bug 105456 would help here.  See also bug 165077, bug 178899.

For the case of a plain text message with a sig, the number of blank quoted 
lines at the end of the quote match the number of blank lines between the end of 
the message and the beginning of the sig.  But for messages without a sig, even 
messages which appear to end immediately after the last message line, show an 
empty quoted line in reply.

This seems to be the only issue raised in this bug that isn't addressed 
elsewhere; but this bug is such a mess, I would recommend opening a new one and 
duping this over.


> 3. Why do we add an extra line before the signature?

Bug 180558.


> 4. We should add a line after the poster's name (Felix Miata wrote)

Bug 91576, bug 211768.


Incidentally, the feature suggested in comment 14 is bug 194785, opened by the 
same person.