Closed Bug 212320 Opened 21 years ago Closed 15 years ago

Cannot send Mail for later delivery in offline mode

Categories

(SeaMonkey :: MailNews: Backend, defect)

Product:
SeaMonkey
Component:
MailNews: Backend
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: carsten_schlipf, Assigned: Bienvenu)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

When I write a message in offline mode and click on "Send Later", I would expect
the message to be stored in either "Outbox" or "Unsent Messages" (on one
computer it's called "Outbox", on the other "Unsent Messages") folder. However
no message appears in these folders. And after going online, no message is sent.
So the message I sent in offline mode got deleted.

This errors occured on Windows XP, Windows 2000 and SuSE Linux 8.2.

Reproducible: Always

Steps to Reproduce:
1. Switch to offline mode
2. Write a message to your own email account.
3. Click on "Sent Later"
4. Check outbox folder -> It's empty
5. Go online
6. No message is sent.

Actual Results:  
The message written in offline mode got deleted.

Expected Results:  
The message should have been stored in the outbox folder until I go online again
and then the message should be sent. The message should not be removed from the
outbox folder, until it was sent successfully.
*** Bug 225126 has been marked as a duplicate of this bug. ***
Confirming according to bug 225126.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can you reproduce this bug with 1.5?
With the latest night build 2003120208 this bug remains unfixed
This bug is not new; it is a regresion.
The bug still remains in Moz 1.6b. This is a relevant bug and reported since
July 2003, and considering is a regression, it mean that the "send later"
feature, worked before this date.
This bug still holds in Mozilla 1.7a. It has been running since Moz 1.5
Working with the preferences, the key "mail.default_sendlater_uri" has an status
of "default", a type "string" and a value of
"mailbox://nobody@Local%20Folders/Unsent%20Messages"
When I type a message to be sent later in the main account "Principal", the
message is saved in the "Local Folders/Unsent Messages", not in "Principal". If
I go On Line, and switch from Principal to Local Folder, and now in File/Sent
Unsent messages , is clicked, the message is sent.....
I tried to change the key from Local%20Folders to Principal, but I receive a
message saying " Unable to save the message, Check your configuration...."
.Could this help to solve this bug?
Yes, this may be the key. Did you find all your lost messages in Local
Folders/Unsent Messages? If yes, then there is no bug here. (Only that the
default sendlater uri is Local Folders, which is ok.)
Try to change the value to:
mailbox://<yourlogin>@Principal/Unsent%20Messages (replace <yourlogin> with the
real login name on this server) And be sure you have an Unsent Messages folder
in this account.

(In reply to comment #9)
> Yes, this may be the key. Did you find all your lost messages in Local
> Folders/Unsent Messages? If yes, then there is no bug here. (Only that the
> default sendlater uri is Local Folders, which is ok.)
> Try to change the value to:
> mailbox://<yourlogin>@Principal/Unsent%20Messages (replace <yourlogin> with the
> real login name on this server) And be sure you have an Unsent Messages folder
> in this account.
> 
I tried but didn´t work.But, with the original setting, the unsent message was
stored in Local Folders, and when going on line, the message is sent, and the
message is stored in Principal...!!!! I could live with it, but still a little
odd...
In addittion to my last comment. I have mozilla 1.7a release...
Ah, sorry, try this:
mailbox://<yourlogin>@<incoming mail server for Principal>/Unsent%20Messages
(In reply to comment #12)
> Ah, sorry, try this:
> mailbox://<yourlogin>@<incoming mail server for Principal>/Unsent%20Messages

I made the changes, and everything is working OK. This workaround should be
placed in some official FAQ.
Actually, I think this is a workaround for an unsupported thing.

As I observe Mozilla behaviour I came to the conclusion, that the default
behaviour is to place unsent messages in the Local Folders. That is the setup
MailNews does with a clean profile. Only those who migrate from Netscape
Communicator will have Unsent Messages folder in their Account. That was OK in
NC because it only allowed 1 account. But in Mozilla, this leads to an
unbalanced situation - 1 account has Unsent Messages, the others don't.
Therefore everything goes to Local Folders and there is no Unsent Messages in
any other account. I think this is what Mozilla promotes.

If you want to hack and point Unsent Messages somewhere else, you are on your
own. I also prefer the setup you have, but just because I don't need to have the
whole 5 folders of Local Folders expanded.

David Bienvenu, could you comment on this? If I am right, you can resolve this
critical bug as invalid :) There is no bug, just user confusion.

Alberto, if you think that Mozilla should ask where to put the unsent messages
and allow to change it anytime, file a new bug. But it will only be and
enhancement (RFE). And I will support you in that bug too.
yes, unsent messages by default is in local folders, and there's no ui for
changing it. There may be some confusion because starting up online didn't used
to prompt to send unsent messages; now it does. I'm a little worried that 4.x
migrated profiles might still have a problem; if not, yes, this would be invalid.
Yes, they have a problem if you delete the account, so the send_later_uri will
point to nonexistent folder. But that is bug 124449.

Alberto didn't have any bug, he just didn't know where were the messages stored.
But they were not lost.

But I am not sure what the original reporter meant...
Up to Mozilla 1.4 , this problem didn´t exists. Now I realized, the changes
introduced since Moz 1.5 with multiple mail accounts. With Moz 1.7a , there is
an explanation about this feature, the first I realized. I assume my ignorance
but I credit it  to the lack of information for an average user.
I think this behaviour is there since 1.3, atleast.

We have solved the confusion and found your unsent messages.
What is the actual problem now? Is the current summary of this bug still relevant?
If you just wish more documentation (or warning in the prefs panel), please,
create a new bug saying so. But this bug (with the current summary) is solved.
At least for you, because we can't be sure, that your version is the same as the
reporter's (Carsten Schlipf). We must wait until he says something.

David, would it be possible to make the Local Folders expanded by default (after
Moz install)? So that new users notice that some messages are appearing there.
Yes, they may collapse them the first time they use MailNews and so wouldn't see
the messages. Could Local Folders be highlighted (with the special icon) to
indicate new messages appeared there? After the user presses Send Later.
Maybe telling people what account the unsent messages folder is in the unsent
messages prompt would help...I'm not crazy about expanding the local folders
account - people get unhappy when things expand like that...Maybe if we said
"You have unsent messages in your Local Folders account"
(In reply to comment #19)
> Maybe telling people what account the unsent messages folder is in the unsent
> messages prompt would help...I'm not crazy about expanding the local folders
> account - people get unhappy when things expand like that...

I meant shipping Moz with Local folders expanded by default.

Ok, what about using the status bar and saying "Message was stored in Local
Folders/Unsent Messages for later delivery...", after composing the message and
choosing "Send later".
(In reply to comment #16)
> Yes, they have a problem if you delete the account, so the send_later_uri will
> point to nonexistent folder. But that is bug 124449.
> 
> Alberto didn't have any bug, he just didn't know where were the messages stored.
> But they were not lost.
> 
> But I am not sure what the original reporter meant...

Aceman, the original reporter meant exactly what he posted, and I can confirm
and reproduce his results.

First, my system details:  Mozilla 1.8a2 (Mozilla/5.0 (Windows; U; Win98; en-US;
rv:1.8a2) Gecko/20040714) on Windows 98 SE, having migrated from Netscape
Communicator 4.79 (with 1.8a1).  Since I have only one e-mail account, I don't
use Local Folders and have everything pointed to the main account renamed
"Mail."  I have the spellchecker set to run prior to sending messages.

With *no* changes to the mail.default_sendlater_uri key in prefs.js (remains the
default string "mailbox://nobody@Local%20Folders/Unsent%20Messages"), I receive
the following results according to the steps below:

1) Compose e-mail message offline.  Click "Send Later."  Spellchecker runs, and
composition window disappears after clicking "Send" button of spellchecker.
2) Open Mail offline.
Result:  there is *no evidence* of the message under "Unsent Messages" in
*either* "Local Folders" or the primary account of "Mail".  It has simply vanished.

With the above proposed change of the mail.default_sendlater_uri key to a string
following the pattern "mailbox://<yourlogin>@<incoming mail server for
Principal>/Unsent%20Messages," the following is observed:

Perform steps 1 & 2 as above
Result:  under the primary account folder "Mail," in the subfolder "Unsent
Messages," the message is in evidence--marked unread, bolding the folder name,
and with the message count next to the folder, as expected.

There *definitely* is a standing problem with the mail.default_sendlater_uri key
properly routing offline mail messages.  I would not mind at all messages being
stored in Local Folders | Unsent Messages, but it appears that, between myself
and the original poster (Carsten Schlipf), this does not even take place with
the default string.

Given that the default string is *not* routing offline messages to Local Folders
| Unsent Messages as it stands, I'm puzzled as to what to suggest.  Is there
something in the string that isn't keying correctly in the case of NC 4.x
migration?  Is a user name required in the string, rather than "nobody?"  I'm at
a lost as to what to suggest, except that this is certainly *not* a resolved bug
at this juncture.
Can you check your steps again? You said:
>First, my system details:  Mozilla 1.8a2 (Mozilla/5.0 (Windows; U; Win98; >en-US;
>rv:1.8a2) Gecko/20040714) on Windows 98 SE, having migrated from Netscape
>Communicator 4.79 (with 1.8a1).

>With *no* changes to the mail.default_sendlater_uri key in prefs.js (remains the
>default string "mailbox://nobody@Local%20Folders/Unsent%20Messages"), I receive
>the following results according to the steps below:

AFAIK, if you migrate an account from Communicator, your
mail.default_sendlater_uri will be set to point to the Unsent messages folder in
that migrated account. Please check this.

Then, you said you manually changed the value according to my advice (which
worked for Alberto). Can you send us part of you prefs.js which contains this
line and also the lines about your mail account (e.g. the name of your pop3
server, login name)? Maybe you didn't make it right.

And how can you talk for the reporter? He didn't even say if his account was
migrated, is talking about some 'outbox' folder, we know nothing about his Local
Folders. He may have a completelly different problem.

(In reply to comment #22)

> AFAIK, if you migrate an account from Communicator, your
> mail.default_sendlater_uri will be set to point to the Unsent messages folder
> in that migrated account. Please check this.

As stated in my previous posting, I migrated from Communicator 4.79 with Mozilla
1.8 alpha 1.  I am using the same profile for 1.8 alpha 2, having updated by
uninstalling 1.8a1, keeping the profile, and installing 1.8a2.  I had made no
changes to the mail.default_sendlater_uri key when the problem behavior was
observed, and to restate, when I examined it, it contained the *default* string
"mailbox://nobody@Local%20Folders/Unsent%20Messages."  As nothing was changed in
my prefs.js file between my migration with 1.8a1 and the update to 1.8a2, the
string for this key would also have been unchanged.
 
> Then, you said you manually changed the value according to my advice (which
> worked for Alberto). Can you send us part of you prefs.js which contains this
> line and also the lines about your mail account (e.g. the name of your pop3
> server, login name)? Maybe you didn't make it right.

I'm not clear on what you're asking here.  In my previous comment, I stated that
changing the mail.default_sendlater_uri key to the proposed pattern string of
"mailbox://<yourlogin>@<incoming mail server for
Principal>/Unsent%20Messages" resulted in the behavior one expected:  the
message composed offline was saved in the Unsent Messages folder of my primary
account ("Mail"--my renaming), and was then properly sent when going online.  To
wit, the change of the key string to the above pattern resolved the problem. 
This does not address the inability of Mozilla to perform the expected function
properly with the *default* string for this pref key.

> And how can you talk for the reporter? He didn't even say if his account was
> migrated, is talking about some 'outbox' folder, we know nothing about his
> Local Folders. He may have a completelly different problem.
 
I don't propose to be speaking for the reporter; my statement was to reinforce
that his problem--as he described it--was identical to the behavior I observed
on my system with Mozilla 1.8a2, that it was not a case of being unable to find
a message composed offline, it was a situation of said message not having been
stored in the expected folder and then sent when going online.

I agree that he does not state whether or not he has migrated, and that he does
not state whether or not he examined the offline message storage folder in Local
Folders.  I disgree with your statement that he "is talking about some 'outbox'
folder."  He states that the problem behavior has been seen on three different
operating systems--Windows XP, Windows 2000, and SuSE Linux 8.2--and that the
folder expected to store unsent messages is titled "Outbox" on one computer
(perhaps the Linux box) and "Unsent Messages" on another.

Given that the reporter states that "no message is sent," I believe this to be
evidence that the messages he composed offline were not stored in the
appropriate folder under Local Folders (this is the same as the behavior I
experienced).  This, however, should be verified by query to the reporter.  He
should also be queried on whether or not he has migrated from NC 4.x or another
similar app (such as Outlook).  This would confirm the bug as reported.  (One
should be able to contact the reporter for this information through his listed
e-mail address.)

As it stands, I still maintain that there is a problem with the
mail.default_sendlater_uri key with the default string of
"mailbox://nobody@Local%20Folders/Unsent%20Messages" in that--from my experience
 and that of the reporter's--it does not result in the expected behavior of
placing messages composed offline in the appropriate folder of Local Folders,
essentially "losing" any message composed offline.  Further investigation and
confirmation from other users would strike me as the next responsible step, as
this is not a trivial problem.
(In reply to comment #22)

> AFAIK, if you migrate an account from Communicator, your
> mail.default_sendlater_uri will be set to point to the Unsent messages folder
> in that migrated account. Please check this.

As stated in my previous posting, I migrated from Communicator 4.79 with Mozilla
1.8 alpha 1.  I am using the same profile for 1.8 alpha 2, having updated by
uninstalling 1.8a1, keeping the profile, and installing 1.8a2.  I had made no
changes to the mail.default_sendlater_uri key when the problem behavior was
observed, and to restate, when I examined it, it contained the *default* string
"mailbox://nobody@Local%20Folders/Unsent%20Messages."  As nothing was changed in
my prefs.js file between my migration with 1.8a1 and the update to 1.8a2, the
string for this key would also have been unchanged.
 
> Then, you said you manually changed the value according to my advice (which
> worked for Alberto). Can you send us part of you prefs.js which contains this
> line and also the lines about your mail account (e.g. the name of your pop3
> server, login name)? Maybe you didn't make it right.

I'm not clear on what you're asking here.  In my previous comment, I stated that
changing the mail.default_sendlater_uri key to the proposed pattern string of
"mailbox://<yourlogin>@<incoming mail server for
Principal>/Unsent%20Messages" resulted in the behavior one expected:  the
message composed offline was saved in the Unsent Messages folder of my primary
account ("Mail"--my renaming), and was then properly sent when going online.  To
wit, the change of the key string to the above pattern resolved the problem. 
This does not address the inability of Mozilla to perform the expected function
properly with the *default* string for this pref key.

> And how can you talk for the reporter? He didn't even say if his account was
> migrated, is talking about some 'outbox' folder, we know nothing about his
> Local Folders. He may have a completelly different problem.
 
I don't propose to be speaking for the reporter; my statement was to reinforce
that his problem--as he described it--was identical to the behavior I observed
on my system with Mozilla 1.8a2, that it was not a case of being unable to find
a message composed offline, it was a situation of said message not having been
stored in the expected folder and then sent when going online.

I agree that he does not state whether or not he has migrated, and that he does
not state whether or not he examined the offline message storage folder in Local
Folders.  I disgree with your statement that he "is talking about some 'outbox'
folder."  He states that the problem behavior has been seen on three different
operating systems--Windows XP, Windows 2000, and SuSE Linux 8.2--and that the
folder expected to store unsent messages is titled "Outbox" on one computer
(perhaps the Linux box) and "Unsent Messages" on another.

Given that the reporter states that "no message is sent," I believe this to be
evidence that the messages he composed offline were not stored in the
appropriate folder under Local Folders (this is the same as the behavior I
experienced).  This, however, should be verified by query to the reporter.  He
should also be queried on whether or not he has migrated from NC 4.x or another
similar app (such as Outlook).  This would confirm the bug as reported.  (One
should be able to contact the reporter for this information through his listed
e-mail address.)

As it stands, I still maintain that there is a problem with the
mail.default_sendlater_uri key with the default string of
"mailbox://nobody@Local%20Folders/Unsent%20Messages" in that--from my experience
 and that of the reporter's--it does not result in the expected behavior of
placing messages composed offline in the appropriate folder of Local Folders,
essentially "losing" any message composed offline.  Further investigation and
confirmation from other users would strike me as the next responsible step, as
this is not a trivial problem.
My apologies for the double posting.  For some reason Bugzilla duplicated my
post due to what it termed a "Mid-Air Collision."
From comment 22 :
As it stands, I still maintain that there is a problem with the
mail.default_sendlater_uri key with the default string of
"mailbox://nobody@Local%20Folders/Unsent%20Messages" in that--from my experience
 and that of the reporter's--it does not result in the expected behavior of
placing messages composed offline in the appropriate folder of Local Folders,
essentially "losing" any message composed offline.  Further investigation and
confirmation from other users would strike me as the next responsible step, as
this is not a trivial problem.
I think Debbie Kraft is right. This is not a trivial problem; it does have a
"work around" , and it works for those brave enough to mess with the profile,
but for the average user, is a question of " I better stick with my old browser,
no bugs on it..." besides, this problem was posted a year ago.....
(In reply to comment #24)
>As stated in my previous posting, I migrated from Communicator 4.79 with >Mozilla
>1.8 alpha 1.  I am using the same profile for 1.8 alpha 2, having updated by
>uninstalling 1.8a1, keeping the profile, and installing 1.8a2.  I had made no
>changes to the mail.default_sendlater_uri key when the problem behavior was
>observed, and to restate, when I examined it, it contained the *default* string
>"mailbox://nobody@Local%20Folders/Unsent%20Messages."  As nothing was changed
>in my prefs.js file between my migration with 1.8a1 and the update to 1.8a2,
>the string for this key would also have been unchanged.
Just for completeness, did you see this pref set in your prefs.js file? Or it
wasn't there so you concluded (correctly) that it is set to the default. Or did
you check this via about:config, where it indicated it's *default* setting?

> I'm not clear on what you're asking here.  In my previous comment, I stated that
> changing the mail.default_sendlater_uri key to the proposed pattern string of
> "mailbox://<yourlogin>@<incoming mail server for
> Principal>/Unsent%20Messages" resulted in the behavior one expected:  the
> message composed offline was saved in the Unsent Messages folder of my primary
> account ("Mail"--my renaming), and was then properly sent when going online.  To
> wit, the change of the key string to the above pattern resolved the problem. 
Sorry, I didn't realize it worked for you in the original posting. Your texts
are sometimes too long :) So I am glad at least this works.

> I don't propose to be speaking for the reporter; my statement was to reinforce
> that his problem--as he described it--was identical to the behavior I observed
> on my system with Mozilla 1.8a2, that it was not a case of being unable to find
> a message composed offline, it was a situation of said message not having been
> stored in the expected folder and then sent when going online.
> 
> I agree that he does not state whether or not he has migrated, and that he does
> not state whether or not he examined the offline message storage folder in Local
> Folders.  I disgree with your statement that he "is talking about some 'outbox'
> folder."  He states that the problem behavior has been seen on three different
> operating systems--Windows XP, Windows 2000, and SuSE Linux 8.2--and that the
> folder expected to store unsent messages is titled "Outbox" on one computer
> (perhaps the Linux box) and "Unsent Messages" on another.
Sorry, you are right again. I just tested it. I didn't know that if you create a
folder named 'Unsent Messages' or 'Outbox' they are automatically special (with
the icon and context menu for send). But you must update the pref accordingly. I
tested this too - I set it to Outbox, Unsent Messages in the main account, and
Unsent Messages in Local folders. Creating a message in the account saved it
into the correct folder in each case. Moz 1.7 EN.

>Given that the reporter states that "no message is sent," I believe this to be
>evidence that the messages he composed offline were not stored in the
>appropriate folder under Local Folders (this is the same as the behavior I
>experienced).  This, however, should be verified by query to the reporter.  He
>should also be queried on whether or not he has migrated from NC 4.x or another
>similar app (such as Outlook).  This would confirm the bug as reported.  (One
>should be able to contact the reporter for this information through his listed
>e-mail address.)
The problem is, he doesn't respond on this bug since hi filed it year ago. I
didn't try to contact him directly...

I am really confused now!

(In reply to comment #26)
> From comment 22 :
> As it stands, I still maintain that there is a problem with the
> mail.default_sendlater_uri key with the default string of
> "mailbox://nobody@Local%20Folders/Unsent%20Messages" in that--from my experience
>  and that of the reporter's--it does not result in the expected behavior of
> placing messages composed offline in the appropriate folder of Local Folders,
> essentially "losing" any message composed offline.
Alberto, I thought your problem was fixed long ago... In comment 10, you
confirmed the messages actually WERE stored in Local Folder, you just didn't
expect them there. Therefore your complain was, that the DEFAULT PREF WORKS AS
IT SHOULD, it just wasn't obvious.

Debbie says the DEFAULT PREF IS NOT WORKING CORRECTLY, that is the opposite
claim! And now you support him (her)?

Guys, we should really clean this bug up.

> Further investigation and
> confirmation from other users would strike me as the next responsible step, as
> this is not a trivial problem.
The problem is, milions of people downloaded Moz with this default setting and
they didn't report problems. Or is none of them migrating a NC account?

> I think Debbie Kraft is right. This is not a trivial problem; it does have a
> "work around" , and it works for those brave enough to mess with the profile,
> but for the average user, is a question of " I better stick with my old browser,
> no bugs on it..." besides, this problem was posted a year ago.....
The default setting works for most people I have seen here to have problems. The
"work around" is actually an (unsupported?) hack, because you wanted your
"unsent messages" folder in the main mail account, not in Local Folders. Don't
worry, I like that setup too, so I don't try to go against you. But average user
doesn't need to mess with his prefs - unless Debbie is right.

Of course it would be nice if the user had an UI to choose the folder, but
nobody works on it. David, do you know some Mail UI guys?

Anyway, I can't help you further, I tried to migrate an account and test your
claims, but it somehow didn't work. It imported no mails and no settings. To
help you, Debbie would have to send me her prefs.js file, panacea.dat, and maybe
a listing of the mail directory (names of files and dirs in the OS) - located
according to the 'mail.server.server?.directory' prefs (e.g. dir /s > list.txt).
You may support Bug 124449 for the folder selecting UI.
(In reply to comment #27)

> >As stated in my previous posting, I migrated from Communicator 4.79 with
> >Mozilla 1.8 alpha 1.  I am using the same profile for 1.8 alpha 2, having
> >updated by uninstalling 1.8a1, keeping the profile, and installing 1.8a2.
> >I had made no changes to the mail.default_sendlater_uri key when the
> >problem behavior was observed, and to restate, when I examined it, it
> >contained the *default* string
> >"mailbox://nobody@Local%20Folders/Unsent%20Messages."  As nothing was changed
> >in my prefs.js file between my migration with 1.8a1 and the update to 1.8a2,
> >the string for this key would also have been unchanged.

> Just for completeness, did you see this pref set in your prefs.js file? Or it
> wasn't there so you concluded (correctly) that it is set to the default. Or
> did you check this via about:config, where it indicated it's *default* 
> setting?

After reading about the bug, I checked the key using about:config.  The string
of "mailbox://nobody@Local%20Folders/Unsent%20Messages" was listed as the
default setting.

> >Given that the reporter states that "no message is sent," I believe this to
> >be evidence that the messages he composed offline were not stored in the
> >appropriate folder under Local Folders (this is the same as the behavior I
> >experienced).  This, however, should be verified by query to the reporter.
> >He should also be queried on whether or not he has migrated from NC 4.x or
> >another similar app (such as Outlook).  This would confirm the bug as
> >reported.

> The problem is, he doesn't respond on this bug since hi filed it year ago. I
> didn't try to contact him directly...
 
Unfortunately, unless people are really motivated to pursue a fix for something,
they don't tend to follow up on it.  There's also the possibility of him moving,
changing his e-mail address, both at the same time, and a number of other events
that might prove more important than a bug in Mozilla.  I, myself, was in and
out of hospital for the first six months of 2004, and wouldn't have followed up
on anything not critical due to my surgeries. :-/
(In reply to comment #28)
> I am really confused now!
> 
> (In reply to comment #26)
> >From comment 22 :
> >As it stands, I still maintain that there is a problem with the
> >mail.default_sendlater_uri key with the default string of
> >"mailbox://nobody@Local%20Folders/Unsent%20Messages" in that--from my
> >experience and that of the reporter's--it does not result in the expected
> >behavior of placing messages composed offline in the appropriate folder of
> >Local Folders, essentially "losing" any message composed offline.

> Alberto, I thought your problem was fixed long ago... In comment 10, you
> confirmed the messages actually WERE stored in Local Folder, you just didn't
> expect them there. Therefore your complain was, that the DEFAULT PREF WORKS AS
> IT SHOULD, it just wasn't obvious.

Aceman, the double-quoted post above is mine, not Alberto's.  His last comment
was #26.  From what I've read, he hasn't changed his position or his reported
results.

> >Further investigation and confirmation from other users would strike me as
> >the next responsible step, as this is not a trivial problem.

> The problem is, milions of people downloaded Moz with this default setting and
> they didn't report problems. Or is none of them migrating a NC account?

Again, double-arrow quote is mine.  And I think a more realistic question at
this point is how many users actively use offline composition?  A user is only
going to discover this error (if it is reproduceable across the board) when
attempting to compose a message offline and then send it later.  In addition, to
what degree does Thunderbird usage factor into this?

I'm going to post to netscape.mozilla.users.win32 and toss the question out to
see if anyone else has experienced this, and, if not, to share the string for
the pref key.  Perhaps with more data, this bug (if it remains such) can be
clarified.
(In reply to comment #31)
> (In reply to comment #28)
> > I am really confused now!
> > 
> > (In reply to comment #26)
> > >From comment 22 :
> > >As it stands, I still maintain that there is a problem with the
> > >mail.default_sendlater_uri key with the default string of
> > >"mailbox://nobody@Local%20Folders/Unsent%20Messages" in that--from my
> > >experience and that of the reporter's--it does not result in the expected
> > >behavior of placing messages composed offline in the appropriate folder of
> > >Local Folders, essentially "losing" any message composed offline.
> 
> > Alberto, I thought your problem was fixed long ago... In comment 10, you
> > confirmed the messages actually WERE stored in Local Folder, you just didn't
> > expect them there. Therefore your complain was, that the DEFAULT PREF WORKS AS
> > IT SHOULD, it just wasn't obvious.
> 
> Aceman, the double-quoted post above is mine, not Alberto's.  His last comment
> was #26.
Yes, he quoted your comment 22 in comment 26 (not marking it very visible),
which I was replying to. But he supports it, therefore it doesn't matter he
didn't say it himself.

>  From what I've read, he hasn't changed his position or his reported
> results.
I took this as a change in his position:
 "I think Debbie Kraft is right. This is not a trivial problem; it does have a
 "work around" , and it works for those brave enough to mess with the profile,"
Why would he say something like this? Till now, his default pref worked and he
didn't need any workaround to fix the default behaviour (and correct sending of
messages). In the past, he couldn't reproduce YOUR problem. Is he able now? Or
does he trust you so much? :)

> > >Further investigation and confirmation from other users would strike me as
> > >the next responsible step, as this is not a trivial problem.
> 
> > The problem is, milions of people downloaded Moz with this default setting and
> > they didn't report problems. Or is none of them migrating a NC account?
> 
> Again, double-arrow quote is mine.
Yes it is. He quoted it and supported in his next lines in comment 26.

> And I think a more realistic question at
> this point is how many users actively use offline composition?  A user is only
> going to discover this error (if it is reproduceable across the board) when
> attempting to compose a message offline and then send it later.
Many users do work offline. Anyway, if the error is that serious as you
reported, even 1 user using offline composition would notice it and report. If
1000 users see it, everybody would already know, that Mozilla is unusable
offline. I didn't hear anything like that so far. I think you must have
something rare. Which doesn't lower the severity of the bug.

>  In addition, to
> what degree does Thunderbird usage factor into this?
Good question. I use the suite myself. But David Bienvenu surely uses
Thunderbird heavily and should spot it.

> I'm going to post to netscape.mozilla.users.win32 and toss the question out to
> see if anyone else has experienced this, and, if not, to share the string for
> the pref key.  Perhaps with more data, this bug (if it remains such) can be
> clarified.
The value of the mentioned pref is not very useful. We know your value of it and
don't see anything wrong with it. The problem has to be somewhere else - the
environment in which a correct value behaves incorrectly. Therefore you would
have to share with use the files I requested (with properly censored secret data:)).

Since I twicked the prefs file a year ago, all updates until the present 1.7.2 ,
works fine ( of course, prefs file is the same, as it is with multizilla...which
I think is great.)
My problem, was and is, the same for  many users, I don´t have broadband.
Telephone compàny limitations in my area imposes dial up. This is the reason why
you work off line to save in the billing charge. I think, this could be a common
feature in developing countries. I have now no complaints with Mozilla, but
nevertheless, I think of a wider audience someplace in the world....
I can confirm this bug.
When I try to "Send Later" a message Mozilla say that it "can not copy" the
message to the folder. Retry?
If I try Yes it exit without warning and the message is NOT sent;
if I try No, it exist say to check the mozilla config.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041001
Mnenhy/0.6.0.104
With mozilla 1.7.3 , and my twicked pref file, this feature is no longer a
problem, but consider my comment Nº 33.
Product: Browser → Seamonkey
comment 34:

Do any of the hints in the first comments of this bug help you? We may help you,
but tell us more. How did you create this account, how many accounts you have, etc.

Alberto, thanks for confirmation, that your problem is still fixed. I have
dialup myself, so don't worry, I watch over these problems :)
I have now Mozilla 1.7.5 build 20041206, and I am so used to it that it is great
for me. It means, you like the browser, and any oddity that appears if you find
a workaround is fine. One odd behavior, for instance, is that all messages 
unable to be delivered and later returned, are stored in local folder, so I go
there once in a while to check, which massages have been not delivered...Is this
the expected behaviour?..As I said, I live with it and used to work with it....
And answering the last question : I have two accounts of which I mainly use one:
Principal. Also, the News account.
(In reply to comment #37)
> One odd behavior, for instance, is that all messages 
> unable to be delivered and later returned, are stored in local folder, so I go
> there once in a while to check, which massages have been not delivered...Is this
> the expected behaviour?..
I don't understand this. You send the message out, and the message comes back in
a server generated error message? Or the message doesn't actullay go out, e.g.
your SMTP server is down or you are offline?
The second case would be ok.
The message is sent, and it is returned with an answer similar to the following :
 ----- The following addresses had permanent fatal errors -----
<dr@xxxxxxts.com>
    (reason: 451 4.4.1 <dr@xxxxxxxts.com>... reply: read error from xxxxxxxxts.com.)
The message is automatically saved in Local Folder.
You mean Local Folders/Inbox? Where do your other incomming messages go?
The returned mail goes to : Local Folder\Trash
Incoming mail goes to Principal\inbox
Directly to the trash? Now that is strange. Do you have any message filters
active? Or the junk mail analyser?
Comment #35 suggests this is WFM as of ~1.7. I don't see it in seamonkey 1.1 either

I see it with seamonkey 1.5a 20070105 on linux though... But there using send later doesn't work even in online mode, so it's probably not this bug.
(In reply to comment #43)
> Comment #35 suggests this is WFM as of ~1.7. I don't see it in seamonkey 1.1
> either

WFM with TB 3.0b2
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.