Closed Bug 223785 Opened 21 years ago Closed 15 years ago

Crash trying to download gaim rpm file at http://www.usr-local-bin.org/gaim.php

Categories

(SeaMonkey :: Download & File Handling, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: DomIncollingo, Unassigned)

References

()

Details

(Keywords: crash, stackwanted)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031026
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031026

Mozilla crashes when I try to download a gaim .rpm file from
//www.usr-local-bin.org/gaim.php.

Reproducible: Always

Steps to Reproduce:
1) Navigate to http://www.usr-local-bin.org/gaim.php.
2) Click on the link for gaim-0.71-SuSE.ulb.1.i586.rpm.
3) Mozilla crashes.
4) Please see Talkback Incident Id TB24802219W.
Actual Results:  
Sometimes Mozilla crashes while I am waiting for the download to start. 
Sometimes Mozilla does not immediately crash, but the screen goes black and no
download occurs; in these situations, Mozilla crashes when I press the Back button.




Sometimes Mozilla crashes while I am waiting for the download to start. 
Sometimes Mozilla does not immediately crash, but the screen goes black and no
download occurs; in these situations, Mozilla crashes when I press the Back button.

My download preference is set to "Open a progress dialog".

I can duplicate this problem using Mozilla 1.5.
*** Bug 223784 has been marked as a duplicate of this bug. ***
caillon, could you get the talkback incident id?
Whiteboard: TB24802219W
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031030

Mozilla crashes on all these links.

http://support.sco.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_faqid=125364
http://support.sco.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_faqid=125359
http://support.sco.com/rn_cgi/partneronline.cfg/php/enduser/std_adp.php?p_faqid=125361

I have talkback enabled, but the crash does not generate any talkback.

Does not happen with Mozilla 1.5

Suggest changing Severity to Blocker or at least Critical.
Dom, John, do you have the RealPlayer plugin installed?  Does getting rid of it
eliminate the crash?
Yes, I had the RealPlayer plugin installed. Getting rid of it did not prevent
the crash.
This is still broken in 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecho/20031110
Forgot to add that this test was done on the same site web pages and that I have
no plugins installed.
Still broken in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031212
MultiZilla/1.6.0.0c nightly.
Flags: blocking1.6?
interesting
I can reproduce.
console messages:
Gtk-WARNING **: invalid cast from `GtkSuperWin' to `GtkWidget'

Gtk-WARNING **: invalid cast from `GtkSuperWin' to `GtkWidget'

realplayer plugin is installed.
but, it works for me when I remove the realplayer plugin

(nightly build 2003121408 linux gtk1)
bz, do you think this is a plugins problem? 
WFM in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031217
MultiZilla/1.6.0.0d even with the RealPlayer plugin installed.
In light of comment 6?  Doubtful, if the realplayer plugin was actually
uninstalled when that test was done.
Yes, realplayer plugin was actually uninstalled because I did a complete
reinstall of Mozilla to make sure there was absolutly nothing being tested
except Mozilla. The insinuation is somewhat troubling.
I just tested the three SCO links I reported and the link to the gaim.rpm again.
The 3 SCO links now work even with the realplayre plugin installed, but the gaim
rpm link still made Moailla crash. I  deleted rpnp.so from the plugins
directory. See listing:

485 $ ls
flashplayer.xpt    libjavaplugin_oji.so  nppdf.so
libflashplayer.so  libnullplugin.so

RealPlayer no longer shows up in the about Plugins page. I tried the gain rpm
link again and it worked.
John, there is no insinuation involved...  It's just that depending on the OS
setup, it can be very difficult to uninstall plugins (they may be in a directory
that the user has no access to and that's not part of the Mozilla install).

Comment 16 is just the realplayer plugin crashing... if that's all that's left
of this bug, then it's a duplicate.
I test on more than one system. I can be root on any of them. I test as my own
login. I make changes and installs as root.

If the case is that Mozilla crashes because the RealPlayer plugin crashes, then
the RealPlayer plugin should be marked as being not compatible with Mozilla.

I find it interesting that all the pages that have been reported including the
ones I reported from SCO are php pages. It would be interesting to find out (how
I don't know) what version of PHP and httpd the sites are using. According to
the page history, the SCO pages were not changed since I reported them as
causeing crashes but they no longer cause a crash. Either something in Mozilla
changed to make those particular pages not crash mozilla or possible the source
site changed versions of PHP or the httpd server they use.

I like the community of Mozilla. But, in my humble opinion, the inability to run
Flash (sometimes - different bug) and the incompatibility with plugins that used
to work on earlier version of Mozilla and on Netscape will hurt Mozilla in the
long run.
John, plugins in Mozilla/Netscape are just .sos that are linked into the app at
runtime as needed... this means if the plugin crashes the app crashes too. 
There are bugs covering that issue.

In fact, all the general ranting about the plugin architecture would probably
belong in the bugs on that architecture having issues.
I don't disagree that the plugins are a different issue. What I do find an issue
is why the RealPlayer plugin would be called when trying to download a file from
a php site. Conflicting entry points?
It's called because that site claims that the file is RealPlayer plugin data
(based on the "rpm" extension, which is used for both RedHat Package Manager
files and RealPlayer files).  So you click on the link, the server tells us it's
a RealPlayer file, we pass it off to the plugin, the plugin starts reading the
data, gets data it's not expecting, etc.
this sounds like it would be a good one to get fixed quickly...  can anyone
think of some ways to defend against the crash?  blocking1.6- minus for now, but
if we come up with a way to stop the crash in the next few days, remominate.
Flags: blocking1.6? → blocking1.6-
*** Bug 231359 has been marked as a duplicate of this bug. ***
Severity: normal → critical
Keywords: crash
Whiteboard: TB24802219W
Product: Browser → Seamonkey
Hi,
Dom Incollingo  and John Griffiths  do you still have this bug?

The first is broken now and I haven't any trouble with links on Comment #4.

Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 (Ubuntu-1.1.9+nobinonly-0ubuntu1)
Not happening in Firefox 3.0.6
WFM based on comment 24 and comment 25
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: