6780 - [PP] Mail treats files in the apprunner folder as mail folders

Status: VERIFIED WORKSFORME

(MailNews Core :: Backend, defect, P3)

Description

[Simon Fraser [no longer active]]

I'm seeing mail trying to read the various files in my apprunner folder
as mail folders. So I get mail folders in the folder pane called:

apprunnerDebug
apprunnderDebug.xSYM
Chrome
etc...

if I click on one of these, it creates a -msf file and says:

+++ nsMsgMailboxParser::OnStartBinding: URL: 0x02a10868, Content type:
application/x-unknown-content-type
url file = /Development/Mozilla build/src/mozilla/dist/viewer_debug/-editor

I sure hope it's opening these files read-only.

There are several bugs here:
1. It defaults to the application directory when looking for mail folders.
2. It happily trys to open non-TEXT files as if they were mail folders.
3. .msf files are created even when the file being opened is obviously not
   a mailbox file.

I'll attach my prefs file.

Comment 1

[Simon Fraser [no longer active]]

Attachment: Prefs file that was active when reproducing the bug.

Comment 2

[Simon Fraser [no longer active]]

Additional note: when opening the mail window, it printf'ed:
"No accounts. I'll try to migrate 4.x prefs.."

Comment 3

[Phil Peterson]

Not sure who this belongs to. Starting with putterman, alecf is on the cc list.

Comment 4

[Jean-Francois Ducarroz]

That append when your prefs are invalide like is the case when they are
generated by the new profile Manager!

Comment 5

[lchiang]

Could this have to do with http://bugzilla.mozilla.org/show_bug.cgi?id=5942? A
new profile manager has been introduced in today's build.

Comment 6

[scottputterman]

Jean-Francois, you were encountering this for a while.  How did you solve this,
or was this never solved?

Comment 7

[Jean-Francois Ducarroz]

On Mac, an empty path is valid contrary than on Unix and Windows. An empty path
= default path = apprunner application path. Previously we use to process
an empty path even when in fact we should have a valid path and that has been
fixed. I will add some code to avoid to process an empty path but we will still
have the problem of bad prefs generated by the profile manager.

Comment 8

[Simon Fraser [no longer active]]

In response to Lisa's question: I saw this behaviour yesterday too. So it
happened before the new profile manager was around.

Note that I pointed out 3 bad things above. You might want to break this into
3 bugs.

Comment 9

[Jean-Francois Ducarroz]

This problem append every time when your directory pref is set to an empty
string.

Comment 10

[Simon Fraser [no longer active]]

Translation: "This problem HAPPENS etc." :)

Comment 11

[scottputterman]

I'll look into this after some other bugs, but I'm not sure this is an M6
stopper.  If putting the correct preference doesn't work, then I agree that
this is a stopper.  Even if we prevent if from looking through the directory,
you will still need to fix the preference in order to view your mail.  Bugs 2
and 3 won't be fixed for a while.

Comment 12

[scottputterman]

Attachment: Potential patch for this bug

Comment 13

[scottputterman]

I've attached a patch for nsLocalMailFolder.cpp where it checks to see if the
file path is "" before proceeding.  Could someone with a Mac check to see if
this works.  If it does, it would prevent it from reading your current
directory and hopefully cause no problems when you click around the folder pane.
It won't find the correct mail path unless you fill in your preferences.

Comment 14

[Jean-Francois Ducarroz]

Scott, your path won't work on Mac because when you create two nsFileSpec from an empty path and then check if
they are equal failed on Mac! (maybe John has already fix this problem). If you create an nsFileSpec from an Emty
path, then your path is equal to the application path not anymore to an empty path.

Comment 15

[scottputterman]

Urgh.  That makes sense.  So any ideas on how to check for this problem from the
mail code?

Comment 16

[Jean-Francois Ducarroz]

Yes, we should try to abort earlier when we get the path from the prefs if possible else I would have to add a Mac
specific patch to control if the nsFileSpec we are using is in fact the sam that the current application. I am not
working on this right now because I am still stuck in a P1 bug.

Comment 17

[scottputterman]

I'm changing this to M7.  The workaround is to fill in the preferences.

Comment 18

[Phil Peterson]

M8

Comment 19

[scottputterman]

All right.  I'm just going to admit that this probably won't get fixed until we
start getting into bug only mode.

Comment 20

[lchiang]

adding [PP] to the summary.

Comment 21

[sol]

Sounds like a bug that we should fix for PR1, so I added a note in the Status
Whiteboard

Comment 22

[Phil Peterson]

marking this worksforme on the assumption that the account manager creates prefs
with valid paths.

Comment 23

[Alec Flett]

this is Mac-only...have we fixed this on mac?
Jean-Francois?

Comment 24

[Jean-Francois Ducarroz]

I haven't see it for a while.

Comment 25

[lchiang]

esther - can you verify? Thanks.

Comment 26

[esther]

Using mac build 1999112308m12 I tested this by launching mail using an existing
profile and by migrating a profile.  I put a .txt file and an application in the
folder of the migrated 4.x profile so it would have files other than mail
folders in it.  The .txt and application files were not brought into the mail
folder list, and .msf files were not created for them, so 2 & 3 are fixed. Also,
since the application files in the application directory were not listed in the
folder pane, I believe #1 is fixed too.  (Note: I did see the application files
listed in my folder pane back when this bug was logged, but I have since
re-migrated and they are no longer listed).  Verified