48868 - can get text area to cause infinite loop on MacOS

Status: VERIFIED FIXED

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

Description

[saari (gone)]

1) bring up bug in http://bugzilla.mozilla.org/show_bug.cgi?id=29800
2) copy the following into the Additional Comments field

Index: nsPresShell.cpp
===================================================================
RCS file: /m/pub/mozilla/layout/html/base/src/nsPresShell.cpp,v
retrieving revision 3.325
diff -w -u -2 -r3.325 nsPresShell.cpp
--- nsPresShell.cpp	2000/08/10 22:07:33	3.325
+++ nsPresShell.cpp	2000/08/14 01:53:05
@@ -3897,5 +3897,5 @@
           // works.  However, this point is relative to the frame's rect, so
           // we need to add on the origin of the rect.
-          nsPoint eventPoint;
+/*          nsPoint eventPoint;
           frame->GetOrigin(eventPoint);
           eventPoint += aEvent->point;
@@ -3907,4 +3907,5 @@
               if (rv != NS_OK) {
 #ifdef XP_MAC
+*/
                 // On the Mac it is possible to be running with no windows open, 
only the native menu bar.
                 // In this situation, we need to handle key board events but 
there are no frames, so
@@ -3912,5 +3913,5 @@
                 mCurrentEventContent = mDocument->GetRootContent();
                 mCurrentEventFrame = nsnull;
-#else
+/*#else
 								if (aForceHandle) {
 									mCurrentEventFrame = frame;
@@ -3925,4 +3926,5 @@
             }
           }
+*/
         }
       }


3) click the Accept bug radio button. That shoul put you into an infinite loop 
and take down MacOS.

Comment 1

[saari (gone)]

Reassigning to beppe as this looks ender specific

Comment 2

[rubydoo123]

assigning to mjudge and cc sfraser since he is Mr. Mac

Comment 3

[rubydoo123]

simon/mike What do you think we should do here?

Comment 4

[bsharma]

Updating QA contact.

Comment 5

[anthonyd]

can we get a mac person to re-test this to evaluate for m19 or future?

anthonyd

Comment 6

[rubydoo123]

asked brade if she would look at this today

Comment 7

[Kathleen :Brade]

I looked at this last week; I could only reproduce the infinite loop once (but 
maybe I was seeing something else?)

I'll try to look at it again soon.

Comment 8

[rubydoo123]

moving this out to future

Comment 9

[Kathleen :Brade]

renominate for rtm; remove Future milestone
I was able to reproduce this today; I have a macsbug log which I'll attach.
add crash keyword (though it's an infinite loop)

Comment 10

[Kathleen :Brade]

Attachment: macsbug log of stack crawl

Comment 11

[rubydoo123]

updated status

Comment 12

[Simon Fraser [no longer active]]

brade: didn't we debug this once, and find that some nsString& was being set to 
null?

This may go away when NOXIF lands.

Comment 13

[Simon Fraser [no longer active]]

Marking dependent on the NOXIF bug.

Comment 14

[Joe Francis]

i'm confused.  is the infinite loop a loop of asserts?  The stack trace shows you 
are in an assert...

Comment 15

[Kathleen :Brade]

Yes the stack crawl above is not from a crash; there are about 15 asserts or so 
that get hit.  I have seen a crash doing the above steps but I can't reliably 
reproduce it.

The one time I crashed in the debugger, I didn't have all of the symbols loaded 
so Simon and I were seeing bad data values from the debugger so I'm not sure what 
is going on yet.  Sorry!

Comment 16

[Kathleen :Brade]

I can't reproduce this bug at all with a mac debug build from today.  I don't
even see the asserts.  I think the NOXIF landing fixed this so I'm going to
resolve as fixed.

Comment 17

[jerone]

Verified build2001070908 os/mac8.6