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.

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

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

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

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.

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

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.

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.

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

Translation: "This problem HAPPENS etc." :)

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.

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.

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.

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

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.

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

M8

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

adding [PP] to the summary.

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

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

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

I haven't see it for a while.

esther - can you verify? Thanks.

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