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

RESOLVED FIXED in Future

Status

()

Core
Layout
P2
critical
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Anoakie Turner, Assigned: Marc Attinasi)

Tracking

({crash})

Trunk
Future
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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
(Reporter)

Comment 1

16 years ago
I tried the latest win32 mozilla build...   So far it seems this bug is only
reproducable in Linux.
Summary: crash when hitting CTRL-Delete more then once on the "Web Page" field → Crash when hitting CTRL-Delete more then once on the "Web Page" field at babelfish

Comment 2

16 years ago
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?
Assignee: rogerl → asa
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → doronr
(Reporter)

Comment 3

16 years ago
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)
Component: Browser-General → JavaScript Engine
QA Contact: doronr → pschwartau
(Reporter)

Updated

16 years ago
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → doronr

Comment 4

16 years ago
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 -
(Reporter)

Comment 5

16 years ago
Created attachment 75319 [details]
Gzipped backtrace.

Gzipped backtrace for CTRL-Delete crash.
(Reporter)

Comment 6

16 years ago
Attached the backtrace. I hope it helps.

Comment 7

16 years ago
Created attachment 75324 [details]
Stack backtrace (text version)

Comment 8

16 years ago
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 -
Assignee: asa → rods
Component: Browser-General → HTML Form Controls
QA Contact: doronr → madhur
(Reporter)

Comment 9

16 years ago
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

16 years ago
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 -
(Reporter)

Comment 11

16 years ago
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

16 years ago
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

16 years ago
Also cc'ing jkeiser -
(Reporter)

Comment 14

16 years ago
Created attachment 78087 [details]
Backtrace with debug enabled build

Backtrace from mozilla .99 compiled source with debug enabled.
(Reporter)

Comment 15

16 years ago
Created attachment 78089 [details]
Repost of attachment 78087 [details] (text/plain)

Comment 16

16 years ago
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 - ?
Assignee: rods → attinasi
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → Layout
Ever confirmed: true
QA Contact: madhur → petersen

Updated

16 years ago
Keywords: crash
Attachment #78087 - Attachment is obsolete: true
Attachment #78087 - Attachment mime type: application/octet-stream → text/plain

Comment 17

16 years ago
Setting Priority to P2
Priority: -- → P2

Updated

16 years ago
Target Milestone: --- → Future
(Reporter)

Comment 18

16 years ago
Fixed is Mozilla 1.0.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Seems fine on WinXP trunk 20020614 too, though I don't think I was able to
reproduce before.
You need to log in before you can comment on or make changes to this bug.