59480 - Modern skin crashes mozilla when ftp browsing mozilla site

Status: VERIFIED WORKSFORME

(SeaMonkey :: Themes, defect, P5)

Description

[AM]

Suse linux 6.3 with helixgnome installed.Gecko/20001107
 downloaded from mozilla.org

If I do a clean install of mozilla after
\rm -rf ./.mozilla
change skin to modern
open  the above url using keyboard naviagation
Mozilla crashes. Happened several times.
Talkback from clean install:
	TB20623132W
I had no problems with the classic skin.

Comment 1

[Jacob Steenhagen]

Does not seem to be the case with 2000110604 on Win2k

Comment 2

[Arjen Hommersom]

works for me on 2000110706/Mandrake 7.2

Comment 3

[Stephan Jaensch]

Does also work for me with latest nightly build on Debian woody. Since there are
two other worksforme reports, resolving bug accordingly.

augustmiles, if the problem persists please provide additional information.

Comment 4

[AM]

I tried again with
Gecko/20001108 Suse 6.3 HelixGnome, Biprocessor SMP machine.
It crashes every time:
Two talkbacks:
TB20688346M (clean install)
TB20688463X (with a pre-existing .mozilla)

I can crash it as often as you wish...

Comment 5

[AM]

I have other talkbacks from another FTP site:
TB20691933M
for instance at ftp.espci.fr

I have got a little further in finding the exact conditions needed:
It seems to be linked with the memory of a vist to the ftp site.
Ie
Choose modern skin
visit the site and open a subdirectory  by clicking on the little triangle.
Quit mozilla.
restart mozilla
revisit the top level of the site
crash
This does not happen with the classic skin.

Comment 6

[Ari Pollak]

Did you start with a fresh mozilla directory (not ~/.mozilla, the actual install
directory), or overwrite old builds?

Comment 7

[AM]

This was a download using the linux installer which removes
the previous install directory. I then rm my .mozilla by
hand, it should thus be a 100% clean setup.

I do one non-standard thing in the install: I change the directory
from /usr/local since I keep a M18 there.

Comment 8

[timeless]

i'm tempted to mark invalid.
I suspect you did not run ./regxpcom && ./regchrome
if you install into a readonly directory and run as mortal then you will crash. 
please run the two mentioned programs (as root or whatever owns mozilla)

Comment 9

[AM]

I don't install mozilla as root. I just run the linux installer as
a normal user. Then I lauch mozilla from a terminal.
I change the install directory in order install in my home directory,
I don't need root privelages for this.
I have never run 
./regxpcom && ./regchrome
that sure! I shall do so at once and generate a talkback

Ok I ran regxpcom (I had to set LD_LIBRARY_PATH and MOZILLA_FIVE_HOME).
regchrome does not exist on my machine ( I checked the locate datebase),
Nor does it exist in netscape PR3.

Lets go...
Launch mozilla, open ftp.mozilla.org using keyboard navigation.
Talkback: TB20759882H

I can get it NOT to crash in the following way: If I configure ftp
to go through a squid ftp proxy then mozilla does not crash. However
Ftp "rewrites" the ftp display so that its not a very good test case.

Otherwise mozilla does run, It does NOT crash with the classic skin.
It is only with the modern skin that this happens.

Comment 10

[Doron Rosenberg (IBM)]

please try running as root once and see if that fixes this

Comment 11

[AM]

Well I ran it as root, it crashed
Talkback: TB20772447X

I tried installing some other skins: ThinIce and Alfred.
They work perfectly, only modern leads to the crash

Comment 12

[AM]

when I run under gdb I generate the following

Program received signal SIGSEGV, Segmentation fault.
0x40857628 in ?? ()
(gdb) where
#0  0x40857628 in ?? ()
#1  0x408571d0 in ?? ()
#2  0x400c39b3 in PL_HandleEvent () from /home2/tony/mozilla/libxpcom.so
#3  0x400c38d6 in PL_ProcessPendingEvents ()
   from /home2/tony/mozilla/libxpcom.so
#4  0x400c462d in nsEventQueueImpl::ProcessPendingEvents ()
   from /home2/tony/mozilla/libxpcom.so
#5  0x404ade0f in NSGetModule ()
   from /home2/tony/mozilla/components/libwidget_gtk.so
#6  0x404adbcd in NSGetModule ()
   from /home2/tony/mozilla/components/libwidget_gtk.so
#7  0x4066d24a in g_io_unix_dispatch (source_data=0x41c6c6c8, 
    current_time=0xbffff4e0, user_data=0x41c6c6a0) at giounix.c:135
#8  0x4066ea83 in g_main_dispatch (dispatch_time=0xbffff4e0) at gmain.c:656
#9  0x4066f0cb in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#10 0x4066f281 in g_main_run (loop=0x825add0) at gmain.c:935
#11 0x40589deb in gtk_main () at gtkmain.c:476
#12 0x404ae2fc in NSGetModule ()
   from /home2/tony/mozilla/components/libwidget_gtk.so
#13 0x4045ac0a in nsJSUtils::mCachedSecurityManager ()
   from /home2/tony/mozilla/components/libnsappshell.so
#14 0x804e275 in JS_PushArguments ()
#15 0x804e845 in JS_PushArguments () 
#16 0x4026d313 in __libc_start_main (main=0x804e718 <JS_PushArguments+12180>, 
    argc=1, argv=0xbffff6e4, init=0x804b2d4 <_init>, fini=0x8054c48 <_fini>, 
    rtld_fini=0x4000ac70 <_dl_fini>, stack_end=0xbffff6dc)
    at ../sysdeps/generic/libc-start.c:90

Comment 13

[timeless]

hrm, Asa could you see if the other talkback reports are different?
let's try xpcom registration.
Hewitt: could your theme be missing something required for ftp view?

Comment 14

[AM]

OK I found one way of not getting it to crash.
If I type the url in the toolbar mozilla stays stable.
If I do
^L to open a dialogue and type the url there 
then return it crashes. All this under modern. Other skins are stable.

Comment 15

[Joe Hewitt (gone)]

No, Modern isn't missing anything.  I can't get this to happen on windows 
either, btw.  If Modern is at fault, it may have something to do with the large 
number of images modern uses.  That's all I can think of.

Comment 16

[Ray Whitmer]

There is no clue in this document why this was assigned to XPCOM Registry.  I am
no longer the owner of XPCOM nor have I worked on XPCOM Registry since Warren
took it, and it is not clear why this got assigned to me.  It is far from clear
who the problem does belong to.  I have seldom been successful doing anything
with skins in Mozilla.  The inability to change skins in a developer build from
the themes list (Redhat 7) prevents me from testing this.  I have seldom ever
had themes work properly from a clean developer build.  Someone who knows themes
and how to make them work should take ownership of this bug or mark it void.

Comment 17

[Patty Mac]

workforme on linux (2001-01-12-08-Mtrunk)

Comment 18

[Joe Hewitt (gone)]

AM, can you still make this happen with recent nightly builds? Myself and pmac
have not been able to duplicate it.

Comment 19

[AM]

Recent build now do work for me

Comment 20

[hangas]

marking worksforme based on comments from Hewitt, pmac, AM.

Comment 21

[Patty Mac]

Verified "workforme" on Linux (2001-03-08-21-Mtrunk).