Bug 459551 - Firefox 3 crashes or hangs if you click on an RPM package download.
Firefox 3 crashes or hangs if you click on an RPM package download.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: firefox (Show other bugs)
All Linux
medium Severity high
: rc
: ---
Assigned To: Gecko Maintainer
Depends On:
  Show dependency treegraph
Reported: 2008-08-19 18:47 EDT by wdc
Modified: 2010-10-22 23:50 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-24 07:10:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Backtrace from firefox -g (7.01 KB, text/plain)
2008-09-04 09:18 EDT, Matěj Cepl
no flags Details
Screenshot of the error message (23.98 KB, image/png)
2008-09-04 09:20 EDT, Matěj Cepl
no flags Details
Better backtrace (61 bytes, text/plain)
2008-09-05 09:41 EDT, Matěj Cepl
no flags Details
Better backtrace (15.29 KB, text/plain)
2008-09-05 09:43 EDT, Matěj Cepl
no flags Details

  None (edit)
Description wdc 2008-08-19 18:47:21 EDT
Description of problem:

Firefox hangs or core dumps when you follow a link to an RPM package

Version-Release number of selected component (if applicable):
Firefox 3.0.1 as comes with RHEL 4.7 as updated via RHN.

How reproducible:
Almost always

Steps to Reproduce:
1. Start Firefox
2. Go to URL http://web.mit.edu/software/linux.html
3. Click on any of the links that refer to an rpm download, for example, the "LPRng 3.8.2 (RHEL 5) link in the first table.
Actual results:

The real player plug-in appears and tries to play the RPM as an audio file.
(But that is NOT a bug, alas.)

Sometimes Firefox will just crash.
Sometimes it will hang.
Clicking on the "Back" button often elicits a crash.

Expected results:

Firefox should not die when a user clicks on an RPM to download instead of knowing to right click on it to save it as a file.

Additional info:

It would be nice if the default configuration of Firefox prioritized an ancient filename convention that nobody uses any more for Real Player files higher than a useful MIMEtype for octet-string on ".rpm".

But living with that reality should NOT core dump Firefox 3.
Firefox 2 managed to cope.
Comment 1 wdc 2008-08-19 20:06:47 EDT
Additional information:

This crash does NOT occur with Firefox 3.0.1 under RHEL 5 (neither the 32 bit
nor the 64 bit platform).

Instead the Totem Mozilla Plugin 2.16.7 reports, "Totem could not play 'fd://0'"

My testing on RHEL 4.7 was only with the 32 bit Intel platform.
By testing under 32 bit RHEL 5, I hoped to eliminate the possibility that
nspluginwrapper was preventing the crash.

"about:plugins" on the RHEL 4.7 system says that .rpm files associate to
nphelix.so Helix DNA plugin: RealPlayer G2 Plug-In Compatible version build with gcc 3.4.6 on June 26 2007.

So maybe this is a plugin interaction new with that plugin under Firefox 3.

How sad that in this day and age a mis-behaving plug-in STILL kills the browser!
(Bad architecture! No biscuit!)
Comment 2 Matěj Cepl 2008-08-29 18:22:43 EDT
Cannot reproduce on RHEL 5.2

What version of FF and pirut you have?


Comment 3 wdc 2008-08-31 22:13:21 EDT
Matej, are you replying to the Bugzilla you intended to?
I state up front that this failure occurs on RHEL 4.7 under FF 3.0.1, and does NOT occur under
RHEL 5.  Why are you asking about pirut?  That seems irrelevant to this BZ.
Comment 4 Matěj Cepl 2008-09-01 06:56:12 EDT
(In reply to comment #3)
> Matej, are you replying to the Bugzilla you intended to?
> I state up front that this failure occurs on RHEL 4.7 under FF 3.0.1, and does
> NOT occur under
> RHEL 5.  Why are you asking about pirut?  That seems irrelevant to this BZ.

pirut is where system-install-package is from.

OK, I missed that point that you tested it on RHEL5. Sorry.
Comment 5 wdc 2008-09-02 19:49:39 EDT
[root@wdc-rhel4-test ~]# rpm -qa | grep firefox

Um, are you sure RHEL 4 has pirut?

[root@wdc-rhel4-test ~]# up2date --whatprovides pirut
[root@wdc-rhel4-test ~]#

[root@wdc-rhel4-test ~]# rpm -qa | grep system-install-package
[root@wdc-rhel4-test ~]#
Comment 6 Matěj Cepl 2008-09-04 09:18:34 EDT
Created attachment 315749 [details]
Backtrace from firefox -g

This is really strange.

OK, yes, I can fully confirm that RHEL4 seems like broken. These are results of my testing:

a) when clicking on http://web.mit.edu/software/pub/linux/mit-zephyr-2.1-6-rhe4.i386.rpm with the plain RHEL FIrefox, I got media player spread to the whole width of the Firefox window. When clicking on Edit menu (so that I can fix associations), Firefox crashed. Unfortunately, no core and thus no backtrace.
b) when restarting firefox with -g parameter and going to the same page, Firefox crashed right away (without HelixPlayer showing anything) and I got the attached backtrace.
(... to be continued)
Comment 7 Matěj Cepl 2008-09-04 09:20:59 EDT
Created attachment 315750 [details]
Screenshot of the error message

a) I checked the associations for rpm file, but it was set to "Install package". So, I thought, everything is OK, but when checked details of the association, it told me that the application is /usr/bin/firefox. When removed the association, and associated rpm file with "Other application" being /usr/bin/system-install-package, and clicking on the same RPM, I got the attached error.

No idea, what to do next.
Comment 9 Matěj Cepl 2008-09-05 09:41:52 EDT
Created attachment 315904 [details]
Better backtrace

This is more complete backtrace -- when I got the first backtrace, I run cont and got the second one. After that further cont didn't help -- the window of firefox didn't vanished, but it is not redrawn, and although processes are running they are on 0% of CPU.
Comment 10 Matěj Cepl 2008-09-05 09:43:04 EDT
Created attachment 315905 [details]
Better backtrace

I thought that URL would work, apparently it doesn't
Comment 11 wdc 2008-09-05 10:20:36 EDT
How very odd.  I just received email containing comment #8 from Didar H Shaikh
flagging the mis-configuration of the MIT web server that sets the MIME type of .rpm
files to "audio/x-pn-realaudio-plugin".  Looking at the bugzilla now, comment #8 is invisible
to me.  Was it deleted?  Does bugzilla have access control that fine-grained?

To answer the issues:  Yes, I'm working the issue of the web server configuration.
However, not everyone can control the configuration of the web server.  For this reason
it is important that a mis configured web server NOT hang or crash the browser!
Comment 12 Issue Tracker 2008-09-05 16:59:16 EDT
hmmm. I can see the same thing. When I click on preferences though, firefox
tells me that it's set to "Always Ask" for rpms.

This event sent from IssueTracker by alanm 
 issue 217863
Comment 13 wdc 2008-09-10 17:00:49 EDT
I just wanted to let you folks know that I was successful in getting the main MIT web site to change the MIME type associated with .rpm files to octet/stream.  This prompts people to save the file, rather than starting the Real Player Plugin.

Y'all should still fix the browser death, but I wanted to warn you that fetching the .rpm file from web.mit.edu will no longer be a useful test case.
Comment 15 Martin Stransky 2008-10-24 07:10:17 EDT
I think this issue can ba closed. 

The firefox crash is caused by real-player plugin (it can't stand rpm files as input) and mis used rpm files were badly marked as real player stream.

As for the firefox crash, it's caused by closed-source plugin so we can't fix it. Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.