74383 - nsBoxToBlockAdaptor::Reflow() prevents TextArea contents from being reflowed

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Michael Schwendt]

During longer editing (*) of a textarea input form I suddenly got garbage in the
text box (garbage = something which looked like a dump of random memory instead
of a human-readable ASCII/ISO-string) and large parts of my text were screwed.
My attempts to fix this by cutting out the garbage ended first with a series of
very slow responses from Mozilla and then with a complete lock-up.

  (*) a few minutes of editing with del/backspace and cut'n'paste with either
mouse-select or shift-up/down/del/insert

I'm using the Red Hat Linux 7.0 compiled Mozilla 0.8:
http://people.redhat.com/blizzard/software/RH7/RPMS/i386/

Comment 1

[Michael Schwendt]

Same with Mozilla 0.8.1-0 from the site mentioned earlier. I have not yet
managed to find a way to reproduce that bug. It just happens now and then.

This time, mouse cut'n'paste was _not_ involved. All of a sudden I got two lines
of garbage at the end of the text area when I cut off the last two lines and
inserted them at the top. Interestingly, this time I managed to work-around the
garbage by scrolling carefully and copying the whole text into an editor's
window. It seemed to me that the text box widget and the internal text strings
were out-of-sync.

Comment 2

[Michael Schwendt]

Attachment: screen shot garbage excerpt

Comment 3

[rods (gone)]

reassigning

Comment 4

[rubydoo123]

could this be related to 22684

Comment 5

[Akkana Peck]

I've never seen this, using daily builds on RH7.  I use mozilla or netscape 
internal builds, though, not the RPM builds.  Is it possible that something got 
corrupted in the rpm builds?  Reporter, can you try a build downloaded from 
mozilla (I use the net installer builds, myself) and see if you still see this?

It would help greatly to have a reproducible case.

Comment 6

[Michael Schwendt]

Well, I'd try Mozilla's own tar.gz releases, provided that they would work on RH
7.0 at all. Previous releases (0.7, 0.8) simply segfaulted on startup. That's
why I've been pointed to Christopher Blizzard's builds for RH 7.0. So far, these
have worked satisfactory.

A few minutes ago I've downloaded the 0.8.1 "x86 tar.gz format" release. When
running "mozilla" it prints the environment variables, but doesn't start:

./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/var/tmp/mozilla
  LD_LIBRARY_PATH=/var/tmp/mozilla:/home/ms/.kde/lib:/usr/lib
     LIBRARY_PATH=/var/tmp/mozilla:/var/tmp/mozilla/components
       SHLIB_PATH=/var/tmp/mozilla
          LIBPATH=/var/tmp/mozilla
       ADDON_PATH=/var/tmp/mozilla
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=

ms        1769  0.3  0.8  2092 1032 pts/3    S    12:41   0:00 sh
/var/tmp/mozilla/run-mozilla.sh ./mozilla-bin
ms        1774  7.5 10.5 31016 13480 pts/3   R    12:41   0:00 ./mozilla-bin
ms        1776  0.0 10.5 31016 13480 pts/3   S    12:41   0:00 ./mozilla-bin
ms        1777  0.0 10.5 31016 13480 pts/3   S    12:41   0:00 ./mozilla-bin
ms        1778  0.0 10.5 31016 13480 pts/3   S    12:41   0:00 ./mozilla-bin
ms        1779  0.0 10.5 31016 13480 pts/3   S    12:41   0:00 ./mozilla-bin

...
rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_0], 8) = 0
rt_sigaction(SIGINT, {0x806f120, [], 0x4000000}, {SIG_DFL}, 8) = 0
wait4(-1, 

Any suggestions?

Reading bug #22684, I can only repeat that the symptoms of this bug look as if
the text box widget is updated with an out-of-date list of text strings after
the cut'n'paste operation. Scrolling a bit carefully using the scrollbar at the
right or the cursor keys seems to fix the text box contents. But not always (see
initial bug report). Hence I have the feeling that more than just a display bug
is involved.

Comment 7

[Michael Schwendt]

With a different user and a "chown MYUSER.MYGROUP * -R" on all files I've got
0.8.1 "x86 tar.gz format" to run. ;-)

Comment 8

[Michael Schwendt]

It seems it must be a special text box (see attachment). With that test page,
the bug is 100% reproducable at my end. When I modify the first line of the HTML
source, the bug can no longer be reproduced.

Starting with an empty text area, I use the mouse to copy text from an editor.
Lines get wrapped since they don't match the line width of the box
(step2_1.png). Hence I move the cursor to the end of the first line and press
backspace to delete the linefeed and append the second line (this is something I
do often when I know that the submitted text is likely to be formatted, e.g. to
block-text). Immediately, the two first lines disappear and sometimes also the
cursor disappears (step2_2.png). When the cursor has disappeared, I need to
click the text area to reactivate it. The "empty" area where once the first two
lines of text have been is not clickable. I cannot get back the original text
unless I press space which pops up the "hidden" text again. However, subsequent
cut'n'paste operations manage to mess up the text area more and more
(step2_4.png -- took a 2nd try, hence no step2_3.png).

Comment 9

[Michael Schwendt]

Attachment: test page

Comment 10

[Michael Schwendt]

Attachment: screenshot #1

Comment 11

[Michael Schwendt]

Attachment: screenshot #2

Comment 12

[Michael Schwendt]

Attachment: screenshot #4

Comment 13

[rubydoo123]

this is not linux only, I can reproduce this on win98, to reproduce try this:
1. save the testcase locally, and edit the file to include the close bracket for 
the body start tag, save it.
2. Open 4.x or another 6.x browser window and scroll to this set of comments 
------- Additional Comments From Michael Schwendt 2001-04-10 04:47 -------

2. highlight the first para in that comment and past into the textarea, when I 
paste it in, it appears on five lines, like this:

It seems it must be a special text box (see attachment).
With that test page,
the bug is 100% reproducable at my end. When I modify 
the first line of the HTML
source, the bug can no longer be reproduced.

3. set your caret at the end of the second line, hit the spacebar and then hit 
delete -- you should see the text disappear as Michael mentions. If I go to the 
end of the pasted text and begin to paste more of the blocks of text, the other 
paste issues and rendering issues that he mentions are also evident.

assigning to Kin, cc simon and mike

Comment 14

[Michael Schwendt]

I'm using the first two paragraphs from my message at 2001-04-10 03:53. The bug
cannot be reproduced with every text.

Comment 15

[Akkana Peck]

Michael: no longer an issue for this specific bug, but I download daily builds
nearly every day and run them on RH 7.0.  I use the net installer builds (e.g.
mozilla-i686-pc-linux-gnu-installer.tar.gz).  Yesterday's net installer was
broken (didn't actually download any files), so I used the .sea installer
instead, which did work. 

Comment 16

[rubydoo123]

I just tried this again and I am still able to reproduce this on win98 using the 
10 May build

Comment 17

[kinmoz]

Hmmmm I can see this bug in OPT builds on WinNt4 and Win98, but not in my debug 
build. Time to fire up Purify and see if I can spot something ...

Comment 18

[kinmoz]

I was able to reproduce this problem on WinNt with a MOZ_PROFILE build, which 
basically builds with debug symbols and Optimizations turned on.

While in the debugger, I was seeing strange things, like the "this" pointer of 
nsTextFrame methods turning NULL when calling other nsTextFrame methods. For 
example if I was in an nsTextFrame method called foo(), this would be valid, but 
when code in foo() called this->bar() ... the "this" pointer in bar() would be 
null leading to strange results and garbage on the screen.

Comment 19

[kinmoz]

Attachment: Simple test case that merges original test case with beppe's example.

Comment 20

[kinmoz]

Attachment: Smaller test case.

Comment 21

[kinmoz]

After debugging this a bit, there seems to be a difference between the number of 
reflows that happens in a Win32 debug build versus an OPT build. It seems that 
nsBoxToBlockAdaptor::Reflow() thinks that a reflow, which is neccessary to 
create some continuing frames and to reset the data in an existing text frame 
who's textnode contents has changed, is not neccessary because it's mLastSize == 
(aWidth, aHeight) ... so we end up painting frames with bad values in them.

I just wanted to give an update in case this rings any bells.

Comment 22

[Chris Waterson]

It doesn't for me, but maybe hyatt or evaughan could comment. It looks like
nsBoxToBlockAdaptor is stifling reflows?

Comment 23

[kinmoz]

Ok, I think I have a handle on what's going on here, but I may have a little 
trouble explaining it.

Note: My Debug and OPT builds were built with VC++ 6.0 ServicePack 3 on Windows 
NT 4 Service Pack 5 ... I mention this, because I can't seem to repro the 
problem on my Home machine running VC++ 6.0 Sp3 and Windows NT 4 Sp6.

To reproduce the problem I used the 05/22/01 15:10 (Smaller test case). I copied 
the entire line below the text area ("is 100% reproducable at my end. When I"), 
then pasted it into the textarea, I then placed the caret before the first 'r' 
character in the word "reproducable" and pasted again. You should then see 
garbage.

There seems to be 2 problems:

  1. nsBoxFrame::Reflow() triggers a call to
     nsGfxTextControlFrame2::ReflowStandard(), which calls

         dx->GetScrollBarDimensions(sbWidth, sbHeight);

     which seems to return an sbWidth of 239.999985 in
     debug builds, and 240.000000 in OPT builds. This value is
     then multiplied by a scale variable (1.0000) and cast to
     a PRInt32, so we get a difference of one twip between
     debug (239) and OPT (240) builds.

     Knowing this fact, you can modify nsGfxTextControlFrame2::ReflowStandard()
     so that sbWidth is manually set to 240 to reproduce the garbage
     problem in a debug build.

     This difference of 1 twip is enough to change the outcome
     of nsTextFrame::MeasureText() during the first paste in my
     test case, and invoke the 2nd problem below.

     It's important to note that this scrollbar width is used in the
     calculation of the block (which is a div inside the textarea)
     frame width. This block frame width is also used in MeasureText()
     which is called when reflowing textframes.

  2. It seems that in debug builds, the first paste I do
     causes MeasureText to return a width that is less than
     the preferred size of the textarea, so nsBoxToBlockAdaptor::Reflow()
     saves this width (the one returned from MeasureText) as
     it's mLastSize.width, so the next paste i do results
     in nsBoxToBlockAdaptor::Reflow() calling mFrame->Reflow()
     because aWidth (the current block width) is not equal to
     mLastSize.width.

     In opt builds, the first paste I do causes MeasureText to return
     a width that is the same as the containing block frame, so
     nsBoxToBlockAdaptor::Reflow() stores this as it's mLastSize.width,
     so the next time I paste, nsBoxToBlockAdaptor::Reflow() compares
     aWidth (which is basically the current block frame width) with
     it's mLastSize.width and since they are equal, it thinks it does
     not need to call mFrame->Reflow(). This results in continuing
     frames not being created and stale data in text frames that existed
     prior to the 2nd paste.

So #2 is obviously the bigger bug, since it really shouldn't matter what size 
the scrollbars are. #1 just illustrates that there are some differences between 
OPT and Debug builds.

So should this bug go to [e-mail] now?

Comment 24

[kinmoz]

Over to [e-mail].

Comment 25

[Peter Trudelle]

clearing target for re-triage by new owners

Comment 26

[Mike Pinkerton (not reading bugmail)]

how serious is this? should we try and get it for rtm?

Comment 27

[kinmoz]

I hear that people run into this bug all the time. It's very disconcerting when 
some of your textarea content renders as garbage, and some of it disappears, not 
to mention that you can actually crash sometimes when trying to select this 
garbage. I think it should be fixed before RTM. :-)

Comment 28

[Michael Schwendt]

Build ID 2001062823 on Linux has another and new bug in the text area editor. 

When moving right (or left) with the cursor keys the cursor stops at strange
word boundaries when it is expected to move to the end of the form. It looks
like it is help up by hidden string delimiters inserted after a cut'n'paste job.
The only work-around is to move the cursor "around" (i.e. up, right, down, or
down, right, up) those places, whatever it may be that blocks proper movement.

To reproduce this, I type a long text which extends over 2-3 lines at least. I
then position the cursor at some arbitrary plac, press return to insert a line
feed, and then go back and press delete to concatenate the two pieces again.
Afterwards, the cursor is not able to move across the position where I did that
"split'n'merge lines" thing.

Comment 29

[Michael Schwendt]

Lame typos of mine:

it is help up -> it is _held_ up
at some arbitrary plac, -> at some arbitrary _place_,

Comment 30

[kinmoz]

In order to avoid morphing this bug into something else ... I filed bug 90141 to 
cover the *new* issue reported by [e-mail] (Michael Schwendt) above.

Comment 31

[Vladimir Ermakov]

What is the status of this bug? I've tried to reproduce it, but failed both on
windows 98 and Linux RedHat 6.2 builds... should this be resolved?

Comment 32

[Michael Schwendt]

I haven't been able to reproduce it for some time. Using Linux Build ID
2001100808 right now.

One issue (probably related to bug #90141, too) is left though: 

At the end of sentences, the editor loses at least one of multiple newline
characters _sometimes_ causing "what you see is NOT what you get". Where I want
an empty line and press return twice, I see an empty line, but I don't get any
in the submitted data. This is _not always_ reproducible, but clearly a bug in
Mozilla's code because it has worked before. Copying may be required, but I
haven't found out yet.

Comment 33

[Vladimir Ermakov]

This is definately not a crash any more, and the end of line problem is
completely different from the original bug... Michael, Please file a separate
bug for it. I'll resolve this as works for me.

Comment 34

[kinmoz]

This bug is still alive and well, and I just created a test case that makes it
easy to reproduce on any platform, using any skin/font.

I have 3 separate bugs regarding, Deletion, Pasting, and Setting the value of a
textarea via JS, all of which are due to this bug. Rather than duping them all
to this one bug, I'm going to resummarize this bug to state what the problem is,
and then make those bugs dependent on this one.

Old summary:

  textarea input form crashed during complex edit session

New summary:

  nsBoxToBlockAdaptor::Reflow() prevents TextArea contents from being reflowed

Comment 35

[kinmoz]

Attachment: Reliable Test Case

Using the buttons in the test case, adjust the width of the textarea until
the arrow ("-->") on the textarea's first line is as close to the textarea's
vertical scrollbar as possible, without creating a horizontal scrollbar.

Note: To see any of the bugs listed below, the textarea must have a vertical
scrollbar and no horizontal scrollbar.

Make sure you don't touch the first line in the textarea, the one that contains
the arrow, while attempting any of the edits listed below.

    * Delete some lines of text. (bug 101122)
    * Copy some text within the textarea and paste it back into
      the textarea. Make sure that whatever you paste does not create a
      horizontal scrollbar. (bug 107973).
    * Type something in the textarea, then hit the "Reset Content" button.
      (bug 107973).

Comment 36

[Michael Schwendt]

Using the "Reliable Test Case" I'm able to reproduce a couple of symptoms again.
When cutting out lines (using SHIFT+CURSOR_DOWN and DELETE block operations) I
get   empty graphical lines which the cursor cannot reach or edit. It just skips
them.

Please also see comment #32. I still get such minor bugs in the text area editor
occasionally, but I don't have the overview of where possible duplicates might
have been reported long ago. Something must be wrong with how line (or string)
delimiters are handled.

Comment 37

[Eric Vaughan]

Attachment: The following patch fixes it. The patch should be applied from the mozilla directory.

Comment 38

[Eric Vaughan]

Patch moved to bug#110328

Comment 39

[kinmoz]

Attachment: Patch Rev 1 (One line fix extracted from previous incremental reflow patch)

Here's the one line change, extracted from evaughan's box incremental reflow
rewrite, that fixes the problem. I tweaked the comments a bit to make them
consistent with each other.

Comment 40

[kinmoz]

After the patch has been reviewed, we'll probably want to check this into the
trunk and to the 0.9.4 and 0.9.6 branches if we can since the 3 bugs that depend
on this are the most reported problems I hear about in regards to textareas.

Comment 41

[Eric Vaughan]

r=evaughan on your patch

Comment 42

[Marc Attinasi]

Comment on attachment 57971 [details] [diff] [review]
Patch Rev 1 (One line fix extracted from previous incremental reflow patch)

sr=attinasi

Comment 43

[kinmoz]

--> kin

Comment 44

[kinmoz]

Fixed checked into trunk:

    mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp  revision 1.33

I'm leaving this open till I can land this on the 0.9.4 branch.

Comment 45

[Dave]

*** Bug 110833 has been marked as a duplicate of this bug. ***

Comment 46

[kinmoz]

*** Bug 25538 has been marked as a duplicate of this bug. ***

Comment 47

[kinmoz]

Nominating for edt0.9.4 since this causes some of the most reported problems 
with textareas. (See the "Bug 74383 blocks" list above.)

Comment 48

[Marek Z. Jeziorek]

was this fix verified on the trunk (and there are no known regressions)? if yes,
please check the fix (I assume that this is the one liner patch above) into
0.9.4 branch.

Comment 49

[kinmoz]

The fix has been on the trunk since 11/21/01, without anyone reporting any
regressions. There was some confusion on my part as to whether or not I should
resolve this bug as FIXED before I got permission to check it in on the 0.9.4
branch, but I guess what I'll do is mark this bug as FIXED so that
[e-mail] can verify it on the TRUNK.

After he does this, I'll check it in on the 0.9.4 branch.

Comment 50

[kinmoz]

*** Bug 107973 has been marked as a duplicate of this bug. ***

Comment 51

[kinmoz]

*** Bug 100727 has been marked as a duplicate of this bug. ***

Comment 52

[kinmoz]

*** Bug 101122 has been marked as a duplicate of this bug. ***

Comment 53

[kinmoz]

*** Bug 112475 has been marked as a duplicate of this bug. ***

Comment 54

[Vladimir Ermakov]

verifying on 2001-12-03-03-trunk windows 98 and 2001-12-03-08-trunk linux

Comment 55

[kinmoz]

Fixed checked into MOZILLA_0_9_4_BRANCH:

    mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp  revision 1.24.66.3

Comment 56

[m_mozilla]

*** Bug 106593 has been marked as a duplicate of this bug. ***

Comment 57

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 110186 has been marked as a duplicate of this bug. ***

Comment 58

[kinmoz]

*** Bug 112753 has been marked as a duplicate of this bug. ***