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




16 years ago
16 years ago


(Reporter: Anoakie Turner, Assigned: Marc Attinasi)




Firefox Tracking Flags

(Not tracked)




(3 attachments, 1 obsolete attachment)



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, 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
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;
<input type="radio" name=tt value="test1" CHECKED>
<input name=url size=38 style="width:400" value="http://"

You can test it here:

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

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/
(gdb) bt
#0  0x410d31d1 in NSGetModule ()
   from /usr/lib/mozilla/components/
... (too many to print here)
Component: Browser-General → JavaScript Engine
QA Contact: doronr → pschwartau


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 -

Comment 5

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

Gzipped backtrace for CTRL-Delete crash.

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

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:

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:


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

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?


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 -

Comment 14

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

Backtrace from mozilla .99 compiled source with debug enabled.

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
Component: HTML Form Controls → Layout
Ever confirmed: true
QA Contact: madhur → petersen


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


16 years ago
Target Milestone: --- → Future

Comment 18

16 years ago
Fixed is Mozilla 1.0.
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.