Closed Bug 237947 Opened 21 years ago Closed 21 years ago

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

Categories

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

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.7final

People

(Reporter: bwp6, Assigned: Biesinger)

References

Details

(Keywords: hang, regression)

Attachments

(3 files, 1 obsolete file)

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.
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.
Yes, Mozilla freezes when I click a MS Word document link in the browser
(downloading).
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)
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
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?
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.
Summary: Mozilla Freezes when selecting email with word doc attachment → Mozilla Freezes when selecting emails or links with word doc attachments
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?

Assignee: sspitzer → cbiesinger
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)
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?
Summary: Mozilla Freezes when selecting emails or links with word doc attachments → Mozilla Freezes when selecting emails or links with doc, xls etc attachments. Deleting the item from .mailcap prevents hang
*** Bug 238243 has been marked as a duplicate of this bug. ***
*** Bug 238081 has been marked as a duplicate of this bug. ***
Severity: major → critical
Confirming. This should definately be fixed for 1.7.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.7?
Keywords: regression
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.
bwp6: can you paste the line you commented out for doc files here?
Modifying summary, reflecting that this a general file handling issue, not
restricted to mail
Summary: Mozilla Freezes when selecting emails or links with doc, xls etc attachments. Deleting the item from .mailcap prevents hang → Mozilla Freezes when handling filetypes w/helper app defined AND an entry in .mailcap (emails / links with doc, xls etc attachments, downloads, opening files). Deleting the filetype from .mailcap prevents freeze
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.
*** Bug 238354 has been marked as a duplicate of this bug. ***
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)
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.  
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. 
---~/.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" />
--------------------------------------------------
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)
Michael: Does /usr/bin/oocalc exist? What about /home/bear/crossover/bin/wine.sh?
bwp6: Thanks for the information, that's very helpful
excellent, I can reproduce by specifying a nonexisting directory in mailcap.

investigating.
Component: Attachments → File Handling
Priority: -- → P1
Product: MailNews → Browser
Target Milestone: --- → mozilla1.7final
definitely should block 1.7
Flags: blocking1.7? → blocking1.7+
Attached patch patch (obsolete) — Splinter Review
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.
Attached patch patch v2Splinter Review
this time, including the mentioned externalhelperappservice change.
Attachment #144696 - Attachment is obsolete: true
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...
Attachment #144697 - Flags: review?(bzbarsky)
Status: NEW → ASSIGNED
Is bug 237252 a dupe of this?
*** Bug 237252 has been marked as a duplicate of this bug. ***
*** Bug 238871 has been marked as a duplicate of this bug. ***
*** Bug 238887 has been marked as a duplicate of this bug. ***
*** Bug 238840 has been marked as a duplicate of this bug. ***
Comment on attachment 144697 [details] [diff] [review]
patch v2

r+sr=bzbarsky

Could we get this hang regression fix approved for 1.7?
Attachment #144697 - Flags: superreview+
Attachment #144697 - Flags: review?(bzbarsky)
Attachment #144697 - Flags: review+
Attachment #144697 - Flags: approval1.7?
*** Bug 239081 has been marked as a duplicate of this bug. ***
*** Bug 239158 has been marked as a duplicate of this bug. ***
Summary: Mozilla Freezes when handling filetypes w/helper app defined AND an entry in .mailcap (emails / links with doc, xls etc attachments, downloads, opening files). Deleting the filetype from .mailcap prevents freeze → Mozilla Freezes when handling filetypes with an entry in .mailcap that does not exist (emails / links with doc, xls etc attachments, downloads, opening files).
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!
(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 on attachment 144697 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #144697 - Flags: approval1.7? → approval1.7+
*** Bug 239273 has been marked as a duplicate of this bug. ***
(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. 


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)
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
for the record: i believe these are also dups:
bug 239337, bug 238307, bug 238871, bug 238985
*** Bug 239638 has been marked as a duplicate of this bug. ***
*** Bug 240344 has been marked as a duplicate of this bug. ***
*** Bug 241084 has been marked as a duplicate of this bug. ***
*** Bug 242015 has been marked as a duplicate of this bug. ***
*** Bug 238985 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: