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.
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 0.4.0.574 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!)
Cannot reproduce on RHEL 5.2 What version of FF and pirut you have? Thanks, matěj
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.
(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.
[root@wdc-rhel4-test ~]# rpm -qa | grep firefox firefox-3.0.1-3.el4 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 ~]#
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)
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.
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.
Created attachment 315905 [details] Better backtrace I thought that URL would work, apparently it doesn't
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!
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
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.
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.