Closed
Bug 323980
Opened 19 years ago
Closed 19 years ago
subfolders of default account are not checked for new mail at startup
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: wolfiR, Assigned: wolfiR)
Details
(4 keywords)
Attachments
(1 file)
1.74 KB,
patch
|
neil
:
review+
iannbugzilla
:
approval-seamonkey1.0+
csthomas
:
approval-seamonkey1.1a+
|
Details | Diff | Splinter Review |
If the default account is IMAP it doesn't check for new messages at startup even if prefs are set correctly. This is _most_ likely because bug 250738 wasn't fixed for seamonkey.
Assignee | ||
Comment 1•19 years ago
|
||
That's the same patch as it is in Thunderbird since TB 1.0
Assignee: mail → mozilla
Status: NEW → ASSIGNED
Assignee | ||
Updated•19 years ago
|
Attachment #208940 -
Flags: review?(neil.parkwaycc.co.uk)
Assignee | ||
Updated•19 years ago
|
Flags: blocking-seamonkey1.0?
Comment 2•19 years ago
|
||
Comment on attachment 208940 [details] [diff] [review] patch Can you verify that this doesn't check the inbox twice?
Assignee | ||
Comment 3•19 years ago
|
||
(In reply to comment #2) > Can you verify that this doesn't check the inbox twice? hmm, my IMAP server log shows that the INBOX is never checked via STATUS nor that it fetches the message flags of inbox messages twice. Why would you expect that it checks the INBOX twice?
This doesn't sound too serious. It does check after a few minutes if you have it automatically check in the background, right?
Flags: blocking-seamonkey1.0? → blocking-seamonkey1.0-
Comment 5•19 years ago
|
||
(In reply to comment #3) >Why would you expect that it checks the INBOX twice? Because that's what the code was originally written to avoid. But maybe someone who knows the backend a bit better can confirm this?
Assignee | ||
Updated•19 years ago
|
Summary: subfolders are not checked for new mail at startup → subfolders of default account are not checked for new mail at startup
Comment 6•19 years ago
|
||
Neil's correct - that's why that code was originally there, but I think whatever problem we were trying to work around has been fixed. TB seems to be working fine with this patch, so I think it should be OK for SM.
Comment 7•19 years ago
|
||
Comment on attachment 208940 [details] [diff] [review] patch I guess I've got to take David's word for it...
Attachment #208940 -
Flags: review?(neil.parkwaycc.co.uk) → review+
Assignee | ||
Comment 8•19 years ago
|
||
Comment on attachment 208940 [details] [diff] [review] patch IMHO this should go to 1.0 if possible at all.
Attachment #208940 -
Flags: approval-seamonkey1.0?
Comment 9•19 years ago
|
||
Of course, it should go into trunk and also 1.1 before 1.0, or at least at the same time...
Comment 10•19 years ago
|
||
Comment on attachment 208940 [details] [diff] [review] patch first a=me for 1.0, btw - given this lands on trunk and 1.1 as well. second approval still needed for landing in 1.0 as well...
Attachment #208940 -
Flags: approval-seamonkey1.1+
Assignee | ||
Comment 11•19 years ago
|
||
commited to trunk and 1.8branch for now
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: fixed-seamonkey1.1
Comment 12•19 years ago
|
||
Comment on attachment 208940 [details] [diff] [review] patch a=me too for SM1.0
Attachment #208940 -
Flags: approval-seamonkey1.0? → approval-seamonkey1.0+
Comment 13•19 years ago
|
||
Comment on attachment 208940 [details] [diff] [review] patch second a=me for 1.0
Keywords: fixed-seamonkey1.1
Whiteboard: fixed-seamonkey1.1
Checked in on 1.8.0 so we can freeze SM1.0 now.
You need to log in
before you can comment on or make changes to this bug.
Description
•