283127 - Firefox hangs when loading MIME content

Status: RESOLVED EXPIRED

(Firefox :: File Handling, defect)

Description

[Jim Burnes]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050210 Firefox/1.0 (Debian package 1.0+dfsg.1-6)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050210 Firefox/1.0 (Debian package 1.0+dfsg.1-6)

After I installed some additional software on my machine, Firefox started
freezing anytime I loaded a non-vanilla html file.  In other words if I clicked
to download a file or multimedia content, Firefox would freeze hard.  This did
not usually affect X Window or Linux directly.  Doing a 'killall firefox-bin'
would kill the offending process.

Having never seen this before, I thought that one of my last kernel changes had
screwed up Firefox.  Luckily I ran 'strace' to find out what was going on.

As you can see below, the trace begins with Firefox doing a polling routine as
it waits for events.  When I click on a 'download' link, Firefox does a number
of things, but primarily it's looking for MIME libraries to figure out what to
do with the content I just clicked on.

If you look closely, it does manage to open the '/usr/lib/gnome-vfs-2.0
directory looking for the 'modules' subdirecty and various helper modules.  It
apparently loads the one it's looking for and then uses some sort of gnome-vfs
protocol to try to load the correct helper app.  Some of that routine includes
opening up an RPC channel to the localhost.

Well since I just have gnome-vfs installed, but I'm running XFCE4 there isn't
anyone listening for RPC/Orbit requests.  It essentially waits forever.

I even told XFCE4 to startup gnome services after starting itself, but to no avail.


Reproducible: Always

Steps to Reproduce:
1. Have libgnomevfs2-common installed on Debian or gnome-vfs-2.0 folder in the
/usr/lib/ file hierarchy.
2. Use XFCE4 (or possibly another) Window Manager.  Anything but Gnome/Metacity.
3. Load up Firefox and click on any page that would normally be processed as an
unknown or non-native file type.
4. Watch Firefox Lockup Hard
 

Actual Results:  
Firefox locked up hard, but Linux and X Window are still active and stable.

Expected Results:  
Firefox should either give you a popup asking where to save the content, or it
should already know what helper application to use.

Firefox should not believe that vfs2 MIME services are actually available unless
it's made calls to check that gnome-vfs-2.0 services is actually listening.




Problem was isolated using 'strace firefox'.  

Temporary, but ugly work around is to rename the /usr/lib/gnome-vfs-2.0
directory to something else.  That fixes the problem, but if you use this I hope
you don't need gnome-vfs functionality ;-)

Comment 1

[Jim Burnes]

Attachment: strace output at time of freeze

Okay...

This is the relevant portion of the output from:

 (strace firefox 2>&1) >vfs-bug.log

The log begins where firefox has finally found a mime/database helper in
gnome-vfs-2.0 directory structure.  (Or so it thinks).	I don't have the source
code at hand, and I'm not familiar with this section, but I think it's trying
to initiate a dialog with a non-existant ORBit daemon.	It then freezes when it
expects to get a reply, but doesn't.

I know that vfs support is optional because I've seen some discussions on the
net where you can include '--disable-gnome-vfs' at compile time.  I looked, but
haven't found a way to disable this at run time.  In either case, depending on
the existance of a library as proof that the entire gnome subsystem is
operational is not good program style.	There should be a call in the library
that determines this.  I think there is something called gnome-vfs-daemon, but
haven't found much info about it.  Like I said before, the ugly fix is just to
make sure Firefox doesn't find this directory.

I really don't have much time to hunt this down, as I only ran into this
because I was trying to download gdesklets for the CPU temperature monitor. 
I'm fine tuning my box for MythTV and I wanted to make sure my CPU wasn't
overheating.

Anyway, I DL'd gdesklets from the normal debian repository and it pulled down
various gtk and gnome dependencies, but not all of gnome.  It's possible gnome,
never having really been initialized (I run XFCE4), was not prepared to be
queried for mime types.

Good luck and let me know what you find.

BTW: You guys are doing a fantastic job.  I love Firefox and have used it since
the pre .5x Phoenix days...

Best Regards,

Jim Burnes
[e-mail]

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.