77492 - Forms problems: bugzilla text entry widgets have line flow, text vanishing, trash on screen problems

Status: VERIFIED DUPLICATE of bug 48543

(Core :: Layout: Form Controls, defect, P1)

Description

[Kent Paul Dolan]

See my additional comment to bug 77284.

In the process of entering that comment into the bugzilla "additional comments"
widget, I had lines sometimes word wrap, other times not, had whole lines of
text disappear from the box (but remain accessible after some blundering around)
when I deleted a space by backspacing between lines, had trash appear at the
bottom of the widget when lines had vanished from the middle of the widget, and
dozens of other problems too fury provoking to let remain long enough to report
them using the same tool.

For example, though, doing an up-arrow through this box when the top line was
offscreen did not return me to the top line, but to the bottom two pixels of
the top line, when typing this "Description", so the problem is with text entry
widgets in general, not just the "Additional comment" one.

Having the bug reporting facility be itself buggy during beta testing is a
failure of software development prioritization.

Oh, and I just managed for a moment to get trash characters to appear in the
middle of this widget as well.  Turning off "bug reporters" at this stage in
Mozilla's development is a possible-to-likely source of product failure.

Gak! This isn't the new bug entry form into which I can type all my release
information.  Why are there two incompatible forms to accomplish one task?  Oh,
well, release is 2001041804 for win32, autoinstall version, Environment is
Windows 98b, situation is newly launched Mozilla browser only so far used to
access Mozilla.org pages, Windows 98b reboot is at least three hours stale.
Talkback not available in this build.

This should have whatever priority is above "critical", see above comments.

Comment 1

[Stephen P. Morse]

Not form manager.  Reassigning.

Comment 2

[hirata masakazu]

I think I have been experiencing similar problem in recent Mac trunk builds.
In some occasion, only a fraction of what I type is actually entered in TEXTAREA
of this bugzilla form. When this happens, you have to type pretty rapidly to get
something into the box. Sometimes, double clicking in an input area brings up an
old text that had existed in the same input box of another bug, even though I do
not have any form values saved for the form in the preferences.
Reloading does not usually correct it, but opening it in a new window does.
Confirming in 2001050314 trunk for Mac, and changing to All/All.

Comment 3

[hirata masakazu]

Seemingly related bugs are: bug 78341, bug 78562, bug 25538. Also, I am
wondering if it has anything to do with other recent focus problems like bug
75752, bug 76992.

Comment 4

[rods (gone)]

reassigning

Comment 5

[kinmoz]

I'll take a look at this.

Question for [e-mail] ... you mention that sometimes text disappears 
and garbage renders, do you know if the actual content inside the textwidget is 
correct? That is, did you notice if the problem was just a rendering problem. 
You can tell by forcing a redraw, by drag selecting the content to hilite it, or 
by obscuring the textwidget with some other window and then re-exposing it.

Comment 6

[Kent Paul Dolan]

The text is at least not destroyed, in that a few keystrokes, such as spaces
inserted at the beginning of the paragraph, can restore it. I don't know without
reinvoking the problem, not always easy to do, whether causing a repaint of the
text widget would suffice to show the correct text.

Right now I'm seeing a different symptom, but perhaps of the same general problem;
as this text sits, attempting to use the up-arrow along the left margin shows an
artifact at the word "reinvoking", where the cursor ends up between the "r" and
the "e" instead of to the left of the "r".  The same happens at the word "Right"
that begins this paragraph.  Aha!  Things just went all weird when I added the
first line beyond one full window's worth, spaces got moved from the ends of
lines to the beginnings of the next lines, the bottom line is sitting at the
text baseline instead of the text character box lower limit, so that descenders
are being cut off.  I'd say the problems I saw are related to having more than
the displayable widget's worth of text, and at least for the problems described,
obscuring the text widget with another window and then re-exposing it does
nothing to help.

Because the word "reinvoking" got pushed away from the left hand edge in this
mispainting, the cursor no longer jumps to the right passing that word, but as
it still occurs for the word "Right" at the head of the second paragraph, I'm
going to save this for example text, in case you have a means to stick it back
into the "Additional Comments" requestor for a trail run.

Sorry this is so incoherent, but it is a bit challenging to describe problems as
they occur in the text you are typing: the observer changes the observed.

Comment 7

[Kent Paul Dolan]

Some junk text in which to try to reinvoke this bug.  The quick brown fox jumped
over the lazy dog.  Mairsy Doats and Lambsy Doats and Liddle Lambsy Divy. 
Fiddley Di Deativytoo, Wooden Shoe?  T'was brillig and the slithy toves, Did
gyre and gimble in the wabe  All mimsey were the borogoves, And the mome raths
outgrabe.  "Beware the Jabberwock, my son!  The jaws that bite, the claws that
catch.  Beware the Jub Jub bird, and shun The frumious bandersnatch.  He took
his vorpal sword in hand, Long time the manxome foe he sought.  Then rested he
'neath the Tum Tum tree, and stood a while in thought.  And as in uffish thought
he stood, The Jabberwock, with eyes of flame, Came whuffling through the tulgy
wood, And burbled as it came.  One, two, one, two!  And through, and through!
The vorpal blade went "snicker, snack".  He left it dead and with its head, He
went gallumphing back.  "And hast thou slain the Jabberwock?" "Come to my arms,
my beamish boy!"  "Oh frabjous day!  Callooh, Callay!" he cried, and chortled in
his joy.  Twas brillig, and the slithy toves, Did gyre and gimble in the wabe. 
All mimsey were the borogoves, And the mome raths outgrabe.

OK, I managed to lose the cursor by inserting and then removing a hard carriage
return between tulgy and wood, and obscuring and reexposing the widget did not
repaint the cursor, nor did using the down arrow to put it on a new line make it
visible, in fact it seemed not to have a location, since typing enough down
arrows to scroll the text up in the window had no effect.  Typing the first
paragraph, which extends beyond the height of the text widget, did not re-invoke
the clipped descenders problem, but with the introduction of a couple of hard
carriage returns to make this new paragraph, the descenders started getting
clipped again.  When I up arrowed to scroll the text down, and then down arrowed
to the bottom, the descenders became visible on the bottom line, but adding more
text finds them clipped off by the bottom of the text widget again.

Mostly, the maintainer is going to have to be the one doing the experimenting,
but things that don't work well including shifting back and forth between flowed
and hard carriage returns for the line breaks, extending the text beyond the
height of the text entry widget with multiple paragraphs, and cursor placement
with respect to the left border.  None of the erroroneous depictions are cured
by causing an expose event to the text.  I wasn't able to find the right
combination of keystrokes to reinvoke the garbage or disappearing text, but
there are plenty of other artifacts to fix that become obvious when the text
widget is heavily used, and I'm sure in testing fixes on those, more problems
will surface
.

Comment 8

[kinmoz]

Moving to mozilla0.9.2 for now.

Comment 9

[kinmoz]

There are actually *several* bugs reported in this one report. There are bugs 
filed against some of them already.

The bug about not scrolling the first/last line in the textarea entirely into 
view while arrowing around is bug 48543.

The bug about garbage appearing and text disappearing sounds an awful like bug 
74383 which has to do with the fact that some layout box code is preventing the 
contents of the textarea from reflowing, in certain situations, so the layout 
frame tree gets out of sync with the content model. As you noticed sometimes 
typing a new character in a paragraph is enough to correct things because a 
reflow was triggered.

I was unable to reproduce the caret jumping around while in the left margin, 
though it could've been due to some BIDI code (bug 80793) which was enabled 
around 05/14/01, which is when you made that comment. 

The bug about spaces rendering at the beginning of wrapped lines is bug 19265.

So, I'm not sure what's left of this bug report that hasn't already been filed 
as another bug ... did I miss anything?

Comment 10

[rubydoo123]

over to 1.0, waiting on final resolution decision

Comment 11

[Kent Paul Dolan]

I'm not sure if there is anything left to call a separate bug, but the current
workings of the multiline text entry widget are so buggy, there needs to be
something of the flavor "fix this until it works acceptably at all", and this is
as close a bug report as might be found.  I think you make those "meta" bugs,
but I don't quite know if I have that concept correct.

I don't think micromanaging problems at this level of severity into subproblems
is useful until there is some limit on the number of subproblems to be fixed.

I reported the problem with respect to the Bugzilla description and Additional
Comments windows, since that's where I first saw them, but now I notice them
with every form I use under Mozilla, as other circumstances moved my usual data
entry mechanism for Usenet news from email to forms filling at groups.google.com
(or posting.google.com), and many other forms fill-in tasks.  It is bad enough
that I turn from Mozilla to other browsers now by choice, so I've added
nsCatFood to the keywords.

That's just opinion, I can no longer be involved with Mozilla testing, so do as
you like, but thanks for the chance to try to help.

Comment 12

[rubydoo123]

am marking this bug a dup of the first bug Kin mentions in his 5/29 entry,
didn't feel right marking this fixed since the referenced bugs are still open

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

Comment 13

[Vladimir Ermakov]

verifying