User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Build ID: 20110902133214 Steps to reproduce: Composing a message and saving from time to time Actual results: Ping! and box on the top right of the screen, announcing a new message. I believe this has started with 6 or 7, that messages saved in the Drafts folder are considered to be "newly arrived". Expected results: nothing.

This should have been fixed by bug 661239. Anything in Tools -> Error console when this happens ? Does this also happens if your run Thunderbird in -safe-mode (see http://support.mozillamessaging.com/en-US/kb/Safe-Mode) ?

Ludo: Hm - my patch for bug 661239 only affects the Linux version of Thunderbird. Unfortunately, due to the ternary nature of our notification backends, it didn't propagate to the other two platforms. I do believe Irving was going to be looking at this notification code - he might be a good candidate to tackle this one. If he doesn't want it, I can take it. -Mike

It didn't happen in safe mode, but I haven't used that one long enough. The bug does not happen the whole day, and I haven't found out a sure way to reproduce it. The error console does not have timestamps, so I can't tell whether an error entry is related to the effect. PS: Apparently I sent this bug twice, see Bug #690293. That one mentions that I use the german version where the drafts folder is named differently (Entwürfe)

Is your complaint same as bug 673400?

(In reply to WADA from comment #5) > Is your complaint same as bug 673400? Its not a duplicate, but clearly related. I don't mind that TB saves several versions in the drafts folder. But maybe saving them as "unread" might be the cause of the effect I am complaining about.

Additional question. Saved drafts will appear in [Gmail]/All Mail too, if Gmail IMAP. Do you enable automatic new mail check for [Gmail]/All Mail, even Smart Phone?

> But maybe saving them as "unread" might be > the cause of the effect I am complaining about. I'm seeing the same thing (7.0.1, Windows 7, US) and suspected the same cause. I will get notification windows for new mail when there is no new mail, but just a draft message open that I am working on. The message is saved to a Drafts folder on my IMAP server. That folder is not a subfolder of the Inbox.

Thought I would chime in here since I've starting having this problem as SOON as I upgraded to one of the major versions (8 or 9 I think). Currently on Bleeding-Edge path, with 9.0a2, Windows 7 64, using MailEnable IMAP server. 1. Start typing a long message. 2. Within 5-minutes (my draft save time), I get a "new email" notification for the draft, and I see an UNREAD draft in the drafts folder. 3. Keep typing for another 5-minutes and another one is created. This happens until I send the message (I don't think the drafts get deleted after send). 4. Even after I've left the computer for an hour (no new composition), if I get a new legitimate email, the "new email" notification shows all of my unsaved drafts! So it looks like I have TONS of new email when in reality, there is only one. 5. When I finally do get around to looking in the drafts folder, I see multiple copies of the same draft (one for each 5 minute save). So if I have been working on an email for 30 minutes, I will see 6 identically-titled UNREAD drafts for that email. Should they not overwrite eachother and keep ONE draft per email? Very Very Very annoying. I would be happy to help run a test build if the Moz team needs a hand. -Brian

I can confirm this, it is very annoying! When composing new message, after a few minutes it is auto-saved in drafts and new-message popup appears. It is marked as new message in bold BLUE with a little star before the subject. But when I mark it read and unread again then it is bold BLACK as usual. The problem started when I upgraded from thunderbird 3.6x to 8.0. I am using courier-IMAP on the server side. It is one of several IMAP servers that presents all folders as subfolders of INBOX. To see the folders in a normal flat structure, you set "IMAP server directory" to "INBOX." (with trailing dot, but without quotes) in advanced IMAP server settings. I do have "mail.check_all_imap_folders_for_new=true" but that always used to work fine. If anyone wants to debug this I can provide a test account if needed. Joost.

I can confirm this, it is very annoying, too Can anyone set the status to confirmed, please? The bug itself is anoying enough to me, but since I read this [1], i'm sure this is severe! [1] Bug #673400, https://bugzilla.mozilla.org/show_bug.cgi?id=673400

From my point of view the simplest solution would be an preference option for specifying if draft messages should be saved with status read or unread into the draft folder. May be an boolean option named "mail.compose.autosave_as_unread" can be implemented? As new mails with status "read" are not announced, this should provide an easy way for fixing this annoying problem.

I vote for Jan Peter Stotz's suggestion. Also, what the heck are the devs working on where we can have an update every other day, but this issue drags for months... -Brian

Hi, As far as I can see, it is just a matter of adding a few lines: https://bugzilla.mozilla.org/attachment.cgi?id=537638&action=diff Can anyone take care of it, please?

Christoph, thanks for the test case and draft patch. We're working on a single implementation of new mail notification for all platforms right now in bug 715799, so rather than patch the existing Unix-specific code I'll include an equivalent fix in the shared version.

Thanks Irving! You're our hero! -Brian

IMHO, notification is not the problem here. Tilman is right in comment #6. If drafts are saved as unread, then it makes sense to identify them as a new unread message, because it is new and marked unread. Making exceptions in the notification code is only a workaround. I mean, what's the point of saving a draft as unread? If you just typed the message does that mean you have not read it and have no idea what's in there? I prefer just to revert to saving drafts as read, like it has been working fine for many years. Why break something that works and then implement a workaround for it elsewhere? In case there is some scenario where people prefer saving drafts as unread, then implement Jan Peter Stotz's (comment #12) suggestion but make the option default to false. PS: Downgrade to 3.1.17 on windows worked fine.

A big +1 for Joost's comment #17. Changing the notification behavior is just a workaround and does not fix the actual problem, which is also exposed when using the same GMail account with other systems (e.g. Android's GMail client) concurrently, see Bug #673400. I also vote for Jan Peter Stotz's suggestion, but perhaps on a per account level and not globally. This could then automatically be set for GMail accounts.

i agree that drafts should be saved as unread. Per account would be fine.

Brian, perhaps you meant ".. drafts should be saved as READ"? Saving as UNread causes the notification problem.

Oups. My bad. Yes, they should be saved as READ, and not generate a notification. :) -Brian

I tried to implement that and created a patch. It's attached to Bug 673400, comment 15. I don't have a dev environment handy, so it is completely untested. Would be great if somebody could have a look.

This bug looks initially for request of "don't show alert for draft"(see comment #1, comment #6), and doesn't look to have requested "change back to 'store \Seen flag for draft' in order not to show new mail alert for draft" explicitly. As written in comment #22, "store \Seen for draft" part is already being processed as "configurable Read/Unread status of draft" in Bug 673400. So adding "don't show alert for draft" part to bug summary of this bug, to avoid misleading and confusion. Bug 676249 comment #0 is crispy and is sufficient to know what bug generated problem, what caused problem, how can the problem be resolved, and clearly refers to both "don't show alert for draft" and "store \Seen for draft" since initial, So I've re-opened that bug(refers to two solutions, so meta bug like one). Please watch bug 676249 if you are interested in both solutions, and please dup future bugs to one of next; > bug 676249 : if generic complaint of "draft is Unread, new mail alert is shown for draft" > bug 673400 : if request of "store \Seen for draft" (mark as Read on draft save) > bug 687140 (this bug) : > if request of "don't show alert for draft" > fixed by bug 661239 (but Linux only) > needs fix of bug 715799 By the way, there is no need of additional "me too" posting in above bugs.

Change by bug 470746 is intentional, which is based on reasonable request of bug 470746. - Status of "Unread" for newly saved draft mail - New mail notification or indication of the newly saved draft mail To bug opener and problem reporterd in this bug: What is essential difference of this bug from bug 676249? What is actual problem of this bug? What is your actual request? What is actual problem in "newly saved draft mail in new mail alert"? What is bad or wrong in "newly saved draft mail in new mail alert"? Simply "newly saved draft mail in new mail alert" is annoyng for you? Simply claiming "newly saved draft mail must have Read status"? If "Read status of newly saved draft mail" is your request, it's dup of bug 673400, isn't it? What is actual trigger of "new mail alert" in your case? Newly saved draft mail by Tb who showed the new mail alert? Newly saved draft mail by other Tb? Or new mail arrived at Inbox? If trigger of new mail alert is "new mail in Inbox" istead of "newly saved draft mail in Drafts"(which is Unread, then is assigned 'new mail' state), it's problem described by Bug 809513, isn't it? (see bug 809513 comment #4, please)

(In reply to WADA from comment #24) > Change by bug 470746 is intentional, which is based on reasonable request of > bug 470746. > - Status of "Unread" for newly saved draft mail > - New mail notification or indication of the newly saved draft mail > > To bug opener and problem reporterd in this bug: > What is essential difference of this bug from bug 676249? None at all > What is actual problem of this bug? That I get a "new mail alert" because of a draft > What is your actual request? That I don't get a "new mail alert" because of a draft, or that it be configurable. > What is actual problem in "newly saved draft mail in new mail alert"? That I get a "new mail alert" because of a draft > What is bad or wrong in "newly saved draft mail in new mail alert"? That it isn't a new mail > Simply "newly saved draft mail in new mail alert" is annoyng for you? Yes > Simply claiming "newly saved draft mail must have Read status"? I don't care whether it has read status. I don't want it to produce a new mail alert. > If "Read status of newly saved draft mail" is your request, it's dup of bug > 673400, isn't it? You asked this on 2011-10-10 10:20:44, I answered on 2011-10-10 10:40:41. (No) > What is actual trigger of "new mail alert" in your case? Writing a new mail > Newly saved draft mail by Tb who showed the new mail alert? Yes > Newly saved draft mail by other Tb? I don't know what "other Tb" is. I run only one instance of Tb. > Or new mail arrived at Inbox? Maybe > If trigger of new mail alert is "new mail in Inbox" istead of "newly saved > draft mail in Drafts"(which is Unread, then is assigned 'new mail' state), > it's problem described by Bug 809513, isn't it? (see bug 809513 comment #4, > please) Maybe. I get new mails very often, so I can't tell whether the annoying alert comes all the time or only when a new mail comes.

(In reply to Tilman from comment #25) > > What is bad or wrong in "newly saved draft mail in new mail alert"? > That it isn't a new mail > > Simply claiming "newly saved draft mail must have Read status"? > I don't care whether it has read status. > I don't want it to produce a new mail alert. Thanks for clear description about "what is bad", "what is problem". > > If "Read status of newly saved draft mail" is your request, it's dup of bug 673400, isn't it? > You asked this on 2011-10-10 10:20:44, I answered on 2011-10-10 10:40:41. > (No) Sorry for duped question. I was trying to consolidate bug 676249, bug 676249, and bug 767051 to single bug at once, and I'm tryng to find proper solution for following issue in Bug 809513. When newly saved draft has no \Seen flag after change by bug 470746, "New Mail" state is set for the newly saved draft mail, even though who generated the draft mail is Tb himself. So, following occurs at Tb who generated the draft mail. - "New mail alert" is shown if "new mail check" is enabled for Drafts. - In "New mail alert", the newly saved draft is shown. And, following occurs at Tb who didn't generated the draft mail. (Tb who shares IMAP Mbox) - "New mail alert" is shown if "new mail check" is enabled for Drafts. - In "New mail alert", the "newly saved draft by other Tb" is shown, if the "newly saved draft mail" is detected by "new mail check by auo-syc" or "via IDLE". As for following problem at other IMAP client such as Smart Phone, change by bug 673400 will be needed. - "New mail alert" is shown due to Unread status of the newly saved draft mail by Tb.

I wonder why this bug has not been addressed in two years time. Something has changed though. With my current TB 17.0.7 on Windows, the new message alert is no longer triggered when draft autosave happens. However, it is still marked unread and when a new mail arrives in inbox then any 'unread' draft messages are also listed in the new mail popup. Here is the documentation about IMAP flags: http://tools.ietf.org/html/rfc3501#section-2.3.2 Checking the message files in my IMAP server's maildir tells me that TB does mark all messages in Drafts with the \Draft flag. It also tells me that marking messages with a star in TB sets the \Flagged flag. I can see the benefit of marking the draft as unread, to notify the user that is was auto-saved and has not been sent or explicitly saved. However, abusing the IMAP \Seen flag may not be the best way to do that. Imho, there are two possible solutions to this problem: 1) Make sure to never ever alert in popups about 'unread' messages flagged \Draft, but perhaps other IMAP clients (like on your smartphone) may still nag about it because this behavior is not an RFC requirement. 2) Use \Flagged instead of \Seen when auto-saving items or do not flag at all. Downside to this may be that the star does not show in the folder list and unfinished email may go unnoticed by the user, but the solution is compatible with other clients. I would suggest implementing 1) and make 2) configurable.

As written in comment #1, external symptom of this bug is same as bug 661239 which is already FIXED, but as written in comment #2, fix of that bug is Linux only patch(change in nsMessengerUnixIntegration.cpp only). And, change by that bug for Linux was "exclude folder of Draft, Template flag from new mail alert". If solution for problem of this bug is similar to fix by bug 661239, new mail alert for "draft mail saved with no \Seen by other Tb who shares IMAP Drafts folder" will not be shown. To Tilman(bug opener), what do you think about following case? By Thunderbird-1, draft mail is saved without \Seen flag(Unread). At Thunderbird-2, the draft mail of no \Seen is detected at Drafts. "New mail alert" should be shown at Thunderbird-2? Or it shouldn't be shown? The "draft mail saved by other Tb" should be shown in new mail alert which is shown when new mail in Ibox is detected at Thunderbird-2? Or it shouldn't be shown? Please note that; - "draft saved by other IMAP client" is obviously "New Mail" in this Tb. So, "New mail alert" is never "BAD" or "Wrong" or "Incorrect". - Some people wants "new mail alert" on "draft mail saved by other IMAP client", but other people never wants "new mail alert" on "draft mail". So, if "New mail alert" is shown, someone opens bug at B.M.O., and if "New mail alert" is not shown, other one opens bug at B.M.O. This is reason why solution of bug 673400 is sufficient for this kind of problem on draft mail. - If user doesn't want new mail alert on draft, store draft as Read. - If user want Unread status of draft, store draft as Unread. Please note that I also think following can be called "bug of Tb". When draft mail is saved without \Seen flag in IMAP Drafts folder, "New mail" state is set in msgDBHdr of the saved draft mail at Tb who saved the draft mail. I believe this is not intentional behavior. This is simply "appended without \Seen flag, then New Mail state is set by response parser.

(In reply to WADA from comment #28) > As written in comment #1, external symptom of this bug is same as bug 661239 > which is already FIXED, but as written in comment #2, fix of that bug is > Linux only patch(change in nsMessengerUnixIntegration.cpp only). And, change > by that bug for Linux was "exclude folder of Draft, Template flag from new > mail alert". > If solution for problem of this bug is similar to fix by bug 661239, new > mail alert for "draft mail saved with no \Seen by other Tb who shares IMAP > Drafts folder" will not be shown. > > To Tilman(bug opener), what do you think about following case? > By Thunderbird-1, draft mail is saved without \Seen flag(Unread). > At Thunderbird-2, the draft mail of no \Seen is detected at Drafts. > "New mail alert" should be shown at Thunderbird-2? > Or it shouldn't be shown? No should not, because it's not a new mail. > The "draft mail saved by other Tb" should be shown in new mail alert which > is shown when new mail in Ibox is detected at Thunderbird-2? > Or it shouldn't be shown? No. > Please note that; > - "draft saved by other IMAP client" is obviously "New Mail" in this Tb. > So, "New mail alert" is never "BAD" or "Wrong" or "Incorrect". I disagree, a draft is just a draft. > - Some people wants "new mail alert" on "draft mail saved by other IMAP > client", but other people never wants "new mail alert" on "draft > mail". Then make it configurable. (If understand correctly, THAT is the proposal in bug 673400). I can live with this. Or do something so that it can be remembered whether a draft was done by the same instance of thunderbird. Maybe through some id in the header, but that is only used while its in a draft, not when the mail is sent. It might make sense to have an alert when the user launches a new tb instance later/somewhere else, to remind him that he forgot to finish his draft.

(In reply to Tilman from comment #31) > > To Tilman(bug opener), what do you think about following case? > > By Thunderbird-1, draft mail is saved without \Seen flag(Unread). > > At Thunderbird-2, the draft mail of no \Seen is detected at Drafts. > > "New mail alert" should be shown at Thunderbird-2? > > Or it shouldn't be shown? > > No should not, because it's not a new mail. > > > The "draft mail saved by other Tb" should be shown in new mail alert which > > is shown when new mail in Ibox is detected at Thunderbird-2? > > Or it shouldn't be shown? > > No. > > - "draft saved by other IMAP client" is obviously "New Mail" in this Tb. > > So, "New mail alert" is never "BAD" or "Wrong" or "Incorrect". > > I disagree, a draft is just a draft. How about "new mail indicator"(red star etc.) at Folder Pane and "new icon" before Subject at Thread Pane? If any one agree with you, and if it's applicable to "new mail indicator at Folder Pane/Thread Pane", required code change is simple. If newly detected mail has \Draft flag, don't set flag of "this is new mail" in msgDBHdr of the draft mail at any Tb, who saved draft mail, and who didn't save the new draft. (change in response parser) If "new mail indicator at Folder Pane/Thread Pane" is neeeded when draft mail is saved without \Seen by other client, change in Biff code is needed. Don't show new mail alert if Draft folder. Don't show mail in "New Mail Alert" if newly detected mail has \Draft flag. (these are perhaps change by bug 661239 on Linux only)

The important thing is that the new draft MUST NOT be marked a unread in IMAP, since this is causing the whole mess with Android's GMail client. If I reply to a read mail and save a draft 10 times, the mail thread is shown unread in Gmail on Android with 10 draft mails that need to be scrolled through, just to figure out that there is no new reply to that thread but only a bunch of uninteresting drafts. Uninteresting because I created them typically myself. The combination of the bug that each draft saving results in a new draft mail and the fact that those messages appear as unread render Thunderbird unusable for the combination with GMail and Android.

(In reply to WADA from comment #32) > How about "new mail indicator"(red star etc.) at Folder Pane and "new icon" > before Subject at Thread Pane? > > If any one agree with you, and if it's applicable to "new mail indicator at > Folder Pane/Thread Pane", required code change is simple. > If newly detected mail has \Draft flag, > don't set flag of "this is new mail" in msgDBHdr of the draft mail > at any Tb, who saved draft mail, and who didn't save the new draft. > (change in response parser) > > If "new mail indicator at Folder Pane/Thread Pane" is neeeded when draft > mail is saved without \Seen by other client, change in Biff code is needed. > Don't show new mail alert if Draft folder. > Don't show mail in "New Mail Alert" if newly detected mail has \Draft > flag. > (these are perhaps change by bug 661239 on Linux only) Yes that sounds like a good solution.

Changing bug summary. - add request for "port of bug 661239 to other than Linux". - remove "new mail indicator" part, in order to avoid further confusion which will produce comment like "draft should be saved as Read", in order to focus on "new mail alert on draft is incorrect" only. "New mail alert on draft" will be prohibited by "port of bug 661239". Incorrect "new mail state(new icon) of draft mail at Tb where draft is saved" part is covered by bug 809513.

(In reply to Tammo van Lessen from comment #33) > The important thing is that the new draft MUST NOT be marked a unread in > IMAP, since this is causing the whole mess with Android's GMail client. "New mail alerts on Smart Phone due to no \Seen flag" is already covered by repeatedly referred and pointed bug 673400. What is reason to add such comment to this bug for problem of incorrect "new mail alert in Tb for draft" when draft is saved without \Seen flag in order to make draft mail "Unread status" for some users convenience? > If I reply to a read mail and save a draft 10 times, > the mail thread is shown unread in Gmail on Android with 10 draft mails > that need to be scrolled through, (snip) "Status of Unread" is produced by "\Seen flag is not set by Tb". But "many draft mails which are already deleted by Tb" is merely bug(actual flaw in code) of mail application on Android what is implemented by developer who doesn't understand Gmail's design well. What is your purpose of adding comment about irrelevant problem to this bug? Read thru bug 562748, please. Anyway, please note that here is bugzilla.mozilla.org for solving Tb's bug. Here is not place for complain to developers. Here is not support forum.

By the way, to Tammo van Lessen, when will your patch for bug 673400 be released? If your patch will be released, this bug will be pretty easily worked around by "save draft mail with \Seen flag" when user doesn't want "Unread status of draft mail". So we are waiting for your patch for long time...

(In reply to Joost from comment #27) > I can see the benefit of marking the draft as unread, > to notify the user that is was auto-saved and has not been sent or explicitly saved. > However, abusing the IMAP \Seen flag may not be the best way to do that. > Imho, there are two possible solutions to this problem: >(snip) > 2) Use \Flagged instead of \Seen when auto-saving items or do not flag at all. FYI. According to bug 673400 comment #28 and bug 673400 comment #30, developer's decision in bug 673400 sounds solution like yours. - backout change by bug 470746 (-> store \Seen to draft mail always) - implement a way to "highlighting of draft mail" for reminder or new draft notification to other IMAP client who shares Drafts folder. (this is objective of bug 470746)

(In reply to WADA from comment #36) > Anyway, please note that here is bugzilla.mozilla.org for solving Tb's bug. > Here is not place for complain to developers. Here is not support forum. I'm sorry if I upset you, I never meant to upset other developers, too. I was just afraid, that the key problem that I have got lost out of focus. It looks, however, that I just misunderstood the proposed solution, which appears to be inline with fixing the smartphone issue as well. I'm totally aware of the fact that this is a bug tracker and not a support forum, however, I'm also pretty annoyed about the fact that bug 673400 is now open for 2 year without any progress, so I felt like pushing it a little. (In reply to WADA from comment #37) > By the way, to Tammo van Lessen, when will your patch for bug 673400 be > released? If your patch will be released, this bug will be pretty easily > worked around by "save draft mail with \Seen flag" when user doesn't want > "Unread status of draft mail". So we are waiting for your patch for long > time... You're waiting for my patch? Well, my patch is there, it is waiting for some TB dev picking it up, applying it, testing it, maybe rewriting, committing it and releasing it. I'm not a Thunderbird developer, I don't even know if the patch fully works. It was just meant to provide a starting point for fixing this bug. I have never been in touch with the thunderbird code base before, so the patch is probably not in the best shape. So please find some TB dev who is fancy to just try it, fix it and release it. As a simple TB user I can't help here any more.

(In reply to Tammo van Lessen from comment #39) > You're waiting for my patch? Well, my patch is there, it is waiting for some > TB dev picking it up, applying it, testing it, maybe rewriting, committing > it and releasing it. Another 3 months later, it seems TB developers can't be bothered fixing bugs. They seem to be more keen on implementing features. So I would like to change this bug into: FEATURE REQUEST: implement folder option to disable new mail alert Why: User may not want to be bothered by alert popups for new messages in folders considered less important. The Junk or Spam folder is a good example, but it may also apply to Drafts, "mailing lists" and "annoying people" folders. How: On the "general Information" tab in the "Folder properties" dialog, there are two options: [x] Include messages in this folder in Global Search results. [x] When getting new messages for this account, always check this folder. Please add: [x] Do not alert when new message arrives in this folder.

It'd be better for that message to be positively framed: [x] Alert when new message arrives in this folder. and maybe it would be selected/enabled by default.

(In reply to Joost from comment #40) > So I would like to change this bug into: > FEATURE REQUEST: implement folder option to disable new mail alert Such feature is perhaps needed for following request by other bug, Don't include "New mail count or Unread mail count of Trash or subfolders of Trash" in "Total New or Unread mail count of parent folder including account FOLDER". A solution : [x] Don't include this folder in Total New/Unread count of parent folder and is obviously "Request for enhancement of Thunderbird". Please open separate bug for your request.

Porting the changes from bug 661239 would appear straight forward for someone with a windows build set up. Likely just copy a few lines from http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMessengerUnixIntegration.cpp#622 to somewhere around here: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMessengerWinIntegration.cpp#817

hello, is somebody working on this bug because i would like to work on this bug, i know c++ this would be my first bug so i might need some extra guidance debugging it. thanks!

Hello diwas! Please seee comment 43, that should be pretty much what needs to be done I think.

Comment on attachment 8484037 [details] [diff] [review] New mail notification shown for autosaved drafts fixed. Review of attachment 8484037 [details] [diff] [review]: ----------------------------------------------------------------- Please fix the indention (2 spaces per level). Also you want to enable the test for windows - remove winnt from here - http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/notification/test-notification.js#523 (and make sure the test still works).

Comment on attachment 8485824 [details] [diff] [review] bug687140.diff Review of attachment 8485824 [details] [diff] [review]: ----------------------------------------------------------------- I notice there are differences (from bug 661239) to the linux version, but that's for another bug. r=mkmelin from code inspection, with the below fixed ::: mailnews/base/src/nsMessengerWinIntegration.cpp @@ +827,5 @@ > + // Unless we're dealing with an Inbox, we don't care > + // about Drafts, Queue, SentMail, Template, or Junk folders > + if (!(flags & nsMsgFolderFlags::Inbox) && > + (flags & (nsMsgFolderFlags::SpecialUse & ~nsMsgFolderFlags::Inbox))) > + continue; this row should be indented two spaces more

Comment on attachment 8485824 [details] [diff] [review] bug687140.diff Review of attachment 8485824 [details] [diff] [review]: ----------------------------------------------------------------- When you update the patch, also make sure the patch commit comment is as it should. It must include the bug number, and usually it's the same as the bug summary. Also add r=mkmelin at the end as it now has review. Sent to try to make sure the tests still pass https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=1210be4fe1c4

(In reply to Magnus Melin from comment #52) > Comment on attachment 8485824 [details] [diff] [review] > bug687140.diff > > Review of attachment 8485824 [details] [diff] [review]: > ----------------------------------------------------------------- > > When you update the patch, also make sure the patch commit comment is as it > should. It must include the bug number, and usually it's the same as the bug > summary. > Also add r=mkmelin at the end as it now has review. > > Sent to try to make sure the tests still pass > https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=1210be4fe1c4 sorry i did not understand what manner should the commit comment be this is my first bug submission. please tell me how to do that.

Well, in this case, when you do hg qrefresh -e you could fill in something like Bug 687140 - "port of bug 661239 to other than Linux" is needed (New email alert ping after saving a mail in the drafts folder. New mail alert for draft shouldn't be shown, even when draft is saved without \Seen by change of bug 470746). r=mkmelin Note that all relevant info should be on one line (as that's all that shows in the hg quick log). Extra info can be on additional lines.

i hope this the correct way for the patch, also what should be my next step after review for the fixation of this bug.

Did you edit that by hand? That's usually not a good idea. Where it now reads "New email alert ping ...." should be what you have entered on the first line. "# Bug 687140 - "port of bug ....", without the starting hashtag. So, "hg qrefresh -e", then e.g. "hg export qtip > b687140.patch" and attach b687140.patch Please fix that, and when you attach the new patch you should mark the old ones as obsolete. If it has review (like in this case) you can mark it review+ and state in the comment that you're carrying forward the review. When everything is ready you add the checkin-needed keyword to the bug, and someone will check it in for you.

i am carrying forward the review.

Comment on attachment 8490133 [details] [diff] [review] b687140.patch Review of attachment 8490133 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/base/src/nsMessengerWinIntegration.cpp @@ +828,5 @@ > + // about Drafts, Queue, SentMail, Template, or Junk folders > + if (!(flags & nsMsgFolderFlags::Inbox) && > + (flags & (nsMsgFolderFlags::SpecialUse & ~nsMsgFolderFlags::Inbox))) > + continue; > + I'm processing checkin-needed, but this seems to add trailing whitespace. Can someone confirm if this can just be trimmed?

Thanks for fixing this!

Backing out due to orange - https://hg.mozilla.org/comm-central/rev/e1347282bbec Looking at it more closely, the patch is indeed wrong. Compare when msgFolder gets set in the end (or not) on unix. http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMessengerUnixIntegration.cpp#599

from what i understand from the last comment, i have tried to fix the mistakes in previous patch.

Comment on attachment 8543788 [details] [diff] [review] b687140.patch Review of attachment 8543788 [details] [diff] [review]: ----------------------------------------------------------------- Unfortunately, still fails. https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=9c99e14654c3 You can run it locally by going to the obj-dir, then make SOLO_TEST=notification/test-notification.js mozmill-one

This bug should be fixed, but in the meantime, a potentially helpful link: https://addons.mozilla.org/en-US/thunderbird/addon/imap-draft-unread/

dij, might you be able to finished this?

Bugs like this remind me why I hate notifications every time I turn it back on, even if just for testing.