132355 - Crash when hitting CTRL-Delete more then once on the "Web Page" field at babelfish

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Anoakie Turner]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020313
BuildID:    .99 and 2002022613

On the page at http://babelfish.altavista.com/, when I click in the Web page
field (the field that already has "http://" entered) and hit CTRL-Del more then
once, mozilla crashes.  I think it may be a JavaScript problem...

Reproducible: Always
Steps to Reproduce:
1. Go to http://babelfish.altavista.com/
2. Click in the "Web page" field
3. Hit CTRL-Del twice

Actual Results:  The browser crashed

Expected Results:  The text "http://" should have been removed from the field
and no futher action taken.

The following code seems to be the culprit:

<script language=JavaScript>
function chooseRadio(form) {
                form.checked = true;
        }
</script>
<input type="radio" name=tt value="test1" CHECKED>
<input name=url size=38 style="width:400" value="http://"
ONFOCUS="chooseRadio(this.form.tt[0])">

You can test it here:  http://www.darkpact.com/test1.html

Comment 1

[Anoakie Turner]

I tried the latest win32 mozilla build...   So far it seems this bug is only
reproducable in Linux.

Comment 2

[Phil Schwartau]

Reassigning to Browser-General until we can get a stack trace. I am unable
to reproduce the crash using Mozilla trunk 20020314xx on Linux, WinNT.

Anoakie, are you using the latest Linux build? Do you have a talkback-enabled 
build? If you crash again, you can post the talkback incident ID here and I'll 
look up the stack trace.

Also: what version of Linux are you using, and what is your window manager?

Comment 3

[Anoakie Turner]

I'm not using the latest linux build,  I am using .99 with galeon (debian
packages).  I did verify it with a 20020226xx CVS build (debian package). I just
installed the latest CVS nightly (Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:0.9.9+) Gecko/20020320, build 2002032008) and verified that it does crash. I
have also just installed the talkback version of .99, but I can't get talkback
to catch the crashes yet...  If you can tell me how to get talkback catch the
crashes with the linux version, I will post the talkback incident ID here.

I'm running Linux 2.4.18 with the preempt patches and WindowMaker 0.80.0.


Here is the crash data (from the latest nightly using gdb...  I doubt this will
help much):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 5544)]
0x410d31d1 in NSGetModule () from /usr/lib/mozilla/components/libgklayout.so
(gdb) bt
#0  0x410d31d1 in NSGetModule ()
   from /usr/lib/mozilla/components/libgklayout.so
... (too many to print here)

Comment 4

[Phil Schwartau]

Anoakie: thanks, could you save your stack trace in a text file,
and attach the text file to this bug via the "Create a New Attachment"
link above? Thanks - it will help if we can see the whole thing.

I'm not sure what to say about Talkback; I thought it came up 
automatically whenever you crash, so you could fill in details
about what you were doing, etc. 

Anyway, if you can attach a stack trace, that would be great -

Comment 5

[Anoakie Turner]

Attachment: Gzipped backtrace.

Gzipped backtrace for CTRL-Delete crash.

Comment 6

[Anoakie Turner]

Attached the backtrace. I hope it helps.

Comment 7

[Phil Schwartau]

Attachment: Stack backtrace (text version)

Comment 8

[Phil Schwartau]

There are a lot of Layout function calls in the backtrace, but
let me assign this to HTML Form Controls just in case the problem
is rooted there -

Comment 9

[Anoakie Turner]

For the "Steps to reproduce" part, #2 says: "Click in the "Web page" field".  A
more detailed description for #2 follows:
Click on the "Web page" field ater the "http://" string.  i.e.  Click here:
"http://[CLICK]"

Comment 10

[Phil Schwartau]

Unfortunately, I still can't reproduce this crash, using Mozilla trunk
binaries from 2002-03-23 on Linux, WinNT, and Mac9.1. On my Linux box,
I am running Red Hat 6.1 and Window Maker 0.61

Following the steps to reproduce given in the original report on
both the given URL and the given testcase:

              http://babelfish.altavista.com/ 
              http://www.darkpact.com/test1.html


Anoakie: does it still crash for you with the very latest build?
Also, if you get a chance, does it crash on any other box besides
the one you reported it on? Thanks -

Comment 11

[Anoakie Turner]

I'm visiting some friends right now and I was able to reproduce the bug on
thier computer, running debian sid.  I installed the nightly (2002-03-23) and
I was able to reproduce the crash.  They are running KDE 2.2.2...  Maybe it's a
bug with one of the debian libraries.  Unfortunately, it still crashes on the
latest build, and I have just reproduced it with KDE 2.2.2.  If I come across
any other boxes, I'll try to reproduce it again...  It may be something related
to debian...  Maybe I should submit this to the Debian Bug Tracking System and
tell them not to forward it upstream :)

Your input is appreciated.  What do you think I should do?

Thanks

Comment 12

[Phil Schwartau]

cc'ing timeless, Boris, Pav: do any of you know someone with Debian Linux?
Could we cc them on this bug in order to get a debug stack trace? Thanks -

Comment 13

[Phil Schwartau]

Also cc'ing jkeiser -

Comment 14

[Anoakie Turner]

Attachment: Backtrace with debug enabled build

Backtrace from mozilla .99 compiled source with debug enabled.

Comment 15

[Anoakie Turner]

Attachment: Repost of attachment 78087 (text/plain)

Comment 16

[Phil Schwartau]

Confirming based on stack trace, which shows an infinite loop 
involving these three calls:

#3182 0x41bdb954 in nsTextFrame::PeekOffset (this=0x86222d4, 
    aPresContext=0x85cb260, aPos=0xbfffdc20) at nsTextFrame.cpp:4253
#3183 0x41b41a66 in nsFrame::PeekOffset (this=0x86222a8, 
    aPresContext=0x85cb260, aPos=0xbfffdc20) at nsFrame.cpp:3404
#3184 0x41b0fa1a in BRFrame::PeekOffset (this=0x86222a8, 
    aPresContext=0x85cb260, aPos=0xbfffdc20) at nsBRFrame.cpp:266


These files are all from Layout, so reassigning to that component.
Based on lxr & bonsai, cc'ing mjudge, who may be able to help -

Note I have been unable to reproduce this on Red Hat; perhaps the bug
is confined to Debian Linux - ?

Comment 17

[Chris Petersen]

Setting Priority to P2

Comment 18

[Anoakie Turner]

Fixed is Mozilla 1.0.

Comment 19

[John Keiser (jkeiser)]

Seems fine on WinXP trunk 20020614 too, though I don't think I was able to
reproduce before.