237947 - Mozilla Freezes when handling filetypes with an entry in .mailcap that does not exist (emails / links with doc, xls etc attachments, downloads, opening files).

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect, P1)

Description

[Theblueman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040317
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040317

When selecting an email that has a word doc as an attachment to view in the
message pane, mozilla mail freezes completely.  I have to kill the process. 
Mozilla also freezes when double clicking an email with a word doc as an attachment.
Other attachments seem to work.

Reproducible: Always
Steps to Reproduce:
1.select an email with a word doc with an attachment
2 [review].if message pane is used mozilla freezes or If double clicking on email mozilla
freezes.




This problem started last week when I updated my mozilla nightly build.  I would
say everything worked properly with a build from two weeks ago.

Comment 1

[R.K.Aa.]

Can you download a doc file from web OK?
I saw a bug today in a fresh build, where downloading or opening doc files would
cause a freeze. 99% CPU. Had to killall mozilla-bin to avoid a meltdown.

Comment 2

[Theblueman]

Yes, Mozilla freezes when I click a MS Word document link in the browser
(downloading).

Comment 3

[R.K.Aa.]

Do you somehow have Mozilla configured to open .doc files?

Look in preferences->Navigator->Helper Applications
AND search in your .mailcap file (grep msword ~/.mailcap)

Comment 4

[Theblueman]

Attachment: Helper applications screenshot

The screenshot of my preferences.

My mailcap files contains the following when I grep for msword:

application/msword;/valid_path/OpenOffice.org1.1.1/soffice %s
application/msword;/valid_path/OpenOffice.org680/soffice %s

Comment 5

[R.K.Aa.]

Thanks. Then I'd like you to try something:

-Quit Mozilla
-In your homedir from an xterm: 
Rename .mailcap to mailcap-backup or similar (mv .mailcap mailcap-backup)
-Restart Mozilla
-Try clicking on the mail with the attachment again

Any change? If yes: Can you now also download .doc files again?

Comment 6

[Theblueman]

I renamed ~/.mailcap and was able to download and view .doc links and MS 
Word attachments.
I restored the .mailcap file and deleted one of the ms-word entries, restarted
mozilla and it still froze.  
I then commented out the remaining "application/ms-word" entry, restarted
Mozilla and was able to view MS-Word documents in email and browser.
Thanks.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

OK. What exactly are your settings for word files in preferences/helper
applications?

(In reply to comment #2)
> Yes, Mozilla freezes when I click a MS Word document link in the browser
> (downloading).

Do you have an example url?

Comment 8

[R.K.Aa.]

Biesi: I was testing this on a friends PC and found this doc-site on google: 

http://www.info.gov.hk/swd/text_eng/down_sec/doc.html

First doc on the page made mozilla freeze. (and the rest of the docs too, far as
i tested it)

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

OK. so, url has .doc extension, content type is application/msword, no
content-disposition nor content-encoding.

how about your helper app settings? are they set to show the dialog before
opening the file? what app are they set to open with? default application, app
with absolute path, or app with relative path? and is it the same as in mailcap?

Comment 10

[R.K.Aa.]

*** Bug 238243 has been marked as a duplicate of this bug. ***

Comment 11

[R.K.Aa.]

*** Bug 238081 has been marked as a duplicate of this bug. ***

Comment 12

[R.K.Aa.]

Confirming. This should definately be fixed for 1.7.

Comment 13

[Theblueman]

Attachment: Dialog box when clicking on a word doc link

In reply to comment #7 my settings in preferences are in comment #4.  Mozilla
is set to prompt me. See attachment.

I've had to comment out ms-office entries from the mailcap file for  excel and
powerpoint as well.

Comment 14

[R.K.Aa.]

bwp6: can you paste the line you commented out for doc files here?

Comment 15

[R.K.Aa.]

Modifying summary, reflecting that this a general file handling issue, not
restricted to mail

Comment 16

[R.K.Aa.]

A thought: Is the gnome_vfs stuff possibly involved here? I build without it
since Mozilla otherwise crash on startup. And I don't see the hang on my own build.

Comment 17

[R.K.Aa.]

*** Bug 238354 has been marked as a duplicate of this bug. ***

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

rkaa: hmm, possible... although I build with it, and could not yet reproduce
this problem. (I haven't yet had much time to spend on this, though)

Comment 19

[Theblueman]

In reply to comment #14
The lines I commented out from the ~/.mailcap file are: 

#application/msword;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/excel;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/msexcel;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/vnd.ms-excel;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/x-msexcel;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/powerpoint;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/mspowerpoint;/home/patrickb/OpenOffice.org1.1.1/soffice %s
#application/vnd.ms-powerpoint;/home/patrickb/OpenOffice.org1.1.1/soffice %s

If I didn't comment out excel, an excel attachment would hang mozilla.  Same
with Powerpoint.  

Comment 20

[Theblueman]

I posted some incorrect information.  I use OpenOffice.org1.1.0 but had
installed OpenOffice.org1.1.1 to test.  When I finished testing the version I
deleted the OpenOffice.org1.1.1 directory in /usr/local and in my home
directory.  This was done before the problem started, I'd say at least a month ago.
When I looked at the .mailcap more closely I noticed the path was not valid. The
paths were pointing to a non-existant directory.  I've substituted
OpenOffice.org1.1.1 for OpenOffice.org1.1.0 in my .mailcap file, re-started
mozilla and now excel, word and powerpoint attachments do not freeze mozilla. 

Comment 21

[Michal Lindner]

---~/.mailcap----------------------------------
application/msword;/home/bear/crossover/bin/wine.sh "C:/Program
Files/WordView/wordview.exe" "%s";  \
    x-crossover
application/vnd.ms-excel;/home/bear/crossover/bin/wine.sh "C:/Program
Files/XLView/XLVIEW.EXE" :switch:e "%s";  \
    x-crossover
-----------------------------------------------
-----mimeTypes.rdf------------------------------
  <RDF:Description RDF:about="urn:mimetype:application/x-msexcel"
                   NC:value="application/x-msexcel"
                   NC:editable="true"
                   NC:description="">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-msexcel"/>
  </RDF:Description>

<RDF:Description
RDF:about="urn:mimetype:externalApplication:application/vnd.ms-excel"
                   NC:path="/usr/bin/oocalc"
                   NC:prettyName="oocalc" />
--------------------------------------------------

Comment 22

[Michal Lindner]

I was not able to reproduce bug with the same homedir mounted on another machine
(SGI IRIX 6.5.19m, Mozilla 1.4/20030711). I'm able to reproduce this bug anytime
at my (Linux SMP, Mozilla 1.7b/20040316)

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

Michael: Does /usr/bin/oocalc exist? What about /home/bear/crossover/bin/wine.sh?
bwp6: Thanks for the information, that's very helpful

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

excellent, I can reproduce by specifying a nonexisting directory in mailcap.

investigating.

Comment 25

[Mike Kaply [:mkaply]]

definitely should block 1.7

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

what a stupid mistake...
the problem was: When the base class fails because the file does not exist, we
really have an absolute path, so AppendRelativePath fails. Unfortunately, this
function failing means that start_iter gets never incremented, and that means
the loop is never exited.

the externalhelperappservice change is needed to continue supporting relative
paths.

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v2

this time, including the mentioned externalhelperappservice change.

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 144697 [details] [diff] [review]
patch v2

note that pre-/absence of a helper app preference entry should not make a
difference at all, I think...

Comment 29

[Christian Eyrich]

Is bug 237252 a dupe of this?

Comment 30

[R.K.Aa.]

*** Bug 237252 has been marked as a duplicate of this bug. ***

Comment 31

[R.K.Aa.]

*** Bug 238871 has been marked as a duplicate of this bug. ***

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 238887 has been marked as a duplicate of this bug. ***

Comment 33

[R.K.Aa.]

*** Bug 238840 has been marked as a duplicate of this bug. ***

Comment 34

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 144697 [details] [diff] [review]
patch v2

r+sr=bzbarsky

Could we get this hang regression fix approved for 1.7?

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 239081 has been marked as a duplicate of this bug. ***

Comment 36

[Boris 'pi' Piwinger]

*** Bug 239158 has been marked as a duplicate of this bug. ***

Comment 37

[Steve Coleman]

I have the same problem with the .mailcap pointing to a nonexistant path to my
acroread due to my home directory being cross mounted from another platform/OS,
thus _all_ the paths are wrong in the mailcap. I also have the "proper"
associations set in the browser configuration under "helper applications".
Shouldn't this be checked first to see if there is a local/custom association
which should override the .mailcap one? 

Thanks!

Comment 38

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #37)
> Shouldn't this be checked first to see if there is a local/custom association
> which should override the .mailcap one? 

We have to check both, because mozilla offers an "open with default application"
choice.

Comment 39

[Asa Dotzler [:asa]]

Comment on attachment 144697 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to 1.7

Comment 40

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 239273 has been marked as a duplicate of this bug. ***

Comment 41

[Steve Coleman]

(In reply to comment #38)
> (In reply to comment #37)
> > Shouldn't this be checked first to see if there is a local/custom association
> > which should override the .mailcap one? 
> 
> We have to check both, because mozilla offers an "open with default application"
> choice.

Ok, I can understand your logic here, but its still the wrong thing to do IMHO.
Please let me explain... (sorry,for being so long winded here)

First, I set up the association in the mozilla preferences because I want _that_
to be my default. If the entry exists, use it. If I can't have that be my
default then I need the option to associate a different .mailcap file just for
that Mozilla profile, because you simply can not assume that all applications on
all machines use the same paths for everyone. In todays workplace IT usually
dictates which applications, platforms, and in most cases much of their
application configurations as well. Users are simply stuck with what they get
from IT for the most part. Of all the machines I use (and I've honestly lost
count of them) only one is under my complete control, and there I may be
god-lord-and-master-of-the-universe, but even on that machine I am forced to use
the same NFS'ed home directory and I'm simply stuck with that fact. Sure, I can
create a dummy userid with a local home directory on that one machine just to
use Mozilla, but you can probably guess my opinion on that as a solution...

Personally I would not care if I had to set an environment variable or even
clone the .mailcap file into my personal mozilla directory and even edit it by
hand, but I do need to have some way to change your concept of my "default". I
thought thats what the mozilla preferences was for, but apparently I was wrong. 

It would seem my one option right now, short of deleting my .mailcap file
altogether, is to do the shell game and swap out the ~/.mailcap file in my
one-and-only NFS'ed home directory for a different .mailcap file for each
application I use, each time I want to click on a link that uses any mime type
association. Not only that, but I must do this on each and every
host/platform/OS I use concurrently, and for all  applications I'm using, not
just mozilla.  A “default” ~/.mailcap file is just a bad idea in a distributed
environment. 

Logically, I would check the mozilla preferences and if the association is found
stop there. Failing that, if you have to check for a .mailcap somewhere,  it
would make sense to check for one in the personalized mozilla directory first,
and failing that, then and as a last resort go on to check the home directory. 
The first entry found should be the default. 

If the associations were searched that way then perhaps the mozilla installation
program could have an option to read the home ~/.mailcap file, and validate it,
and then only clone the valid paths while creating a local personalized mozilla
version of it. All the current associations would be there and any new ones
would not pollute the global mailcap in the home directory. 

Sorry, for the rant here. You are all doing such wonderful work with Mozilla
that I hate to complain at all. 

Comment 42

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
nsExternalHelperAppService.cpp
new revision: 1.253; previous revision: 1.252
done
Checking in uriloader/exthandler/unix/nsOSHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp,v  <-- 
nsOSHelperAppService.cpp
new revision: 1.50; previous revision: 1.49
done

(In reply to comment #41)
> First, I set up the association in the mozilla preferences because I want _that_
> to be my default. If the entry exists, use it.

That is used. I'm not sure what you're ranting about here?

that mozilla happens to look in .mailcap as well to find a system default
application is really an implementation detail that users need not really care
about...

anyway, this if FIXED for 1.7 final. (and in nightly builds starting tomorrow)

Comment 43

[R.K.Aa.]

for the record: i believe these are also dups:
bug 239337, bug 238307, bug 238871, bug 238985

Comment 44

[R.K.Aa.]

*** Bug 239638 has been marked as a duplicate of this bug. ***

Comment 45

[R.K.Aa.]

*** Bug 240344 has been marked as a duplicate of this bug. ***

Comment 46

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 241084 has been marked as a duplicate of this bug. ***

Comment 47

[Scott Packard]

*** Bug 242015 has been marked as a duplicate of this bug. ***

Comment 48

[R.K.Aa.]

*** Bug 238985 has been marked as a duplicate of this bug. ***