Mail Window Front End
9 years ago
9 years ago


(Reporter: Omar Bajraszewski, Assigned: Bienvenu)


Windows Vista

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [one case fixed, another still broken - see comment 6])


(2 attachments)



9 years ago
Created attachment 345954 [details]

When I check new e-mail I can often see a broken mail alert. I use Gmail IMAP. I can reproduce it also when I delete ImapMail Folder from Profile Folder.

Steps to reproduce it:
1)Create a Gmail IMAP account
2)Get new mails
1)Go to you Profile Folder and delete ImapMail Folder
2)Launch Thunderbird

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081102 Lightning/1.0pre Shredder/3.0b1pre


9 years ago
Whiteboard: DUPEME

Comment 1

9 years ago
I can this error in console:
Error: foldersWithNewMail.GetElementAt(0) is null
Source File: chrome://messenger/content/newmailalert.js
Line: 68

Comment 2

9 years ago
Don't know why it would happen, but that row is
  var rootFolder = foldersWithNewMail.GetElementAt(0).QueryInterface(Components.interfaces.nsIWeakReference).QueryReferent(Components.interfaces.nsIMsgFolder);

Comment 3

9 years ago
Btw, is this a regression? (I haven't seen it on linux.)

Comment 4

9 years ago
Yes, I think it's a regression, but I'm not sure what caused it. I believe that foldersWithNewMail had an element at one point, but by the time the alert  is up, that folder has been removed, perhaps because the message was junk, and moved away.

Comment 5

9 years ago
Created attachment 349256 [details] [diff] [review]
proposed fix

this has been bugging the heck out of me.

The problem was that when any server cleared biff, it cleared all the server hits. It should just be removing its root folder from the list of folders with new. What was happening was that one server would get new mail, and notify, but before the dialog got up, the second server would report no new mail, and clear all biffs, ruining everybody's fun!
Assignee: nobody → bienvenu
Attachment #349256 - Flags: superreview?(bugzilla)
Attachment #349256 - Flags: review?(bugzilla)

Comment 6

9 years ago
I did some investigation on this issue. I think the root cause is in following snippet in RerootFolder() (mail/base/content/commandglue.js)

  //the new folder being selected should have its biff state get cleared.
    newFolder.biffState =

Setting biffState to "NoMail" triggers 
nsMessengerWinIntegration::OnItemIntPropertyChanged() to be called with 
 aNewValue = nsIMsgFolder::nsMsgBiffState_NoMail. So mFolderWithNewMail->Clear() get called and mFolderWithNewMail gets cleared.

But new mail notification window hasn't poped up yet.

When setting up Gmail IMAP account for the fist time, following codes are executed:
  if (viewType != nsMsgViewType.eShowVirtualFolderResults && (folder.manyHeadersToDownload || showMessagesAfterLoading))
    gRerootOnFolderLoad = true;
      SetBusyCursor(window, true);
(in ChangeFolder() mail/base/content/commandglue.js).

Because msg db hasn't been created yet, fold.manyHeadersToDownload is "true", so the "if" condition holds and gRerootOnFolderLoad is set to "true"

Later, in folderListener::OnItemEvent() is triggered with "FolderLoaded" event,
and following snippet is executed:
              if (gRerootOnFolderLoad)
                RerootFolder(uri, msgFolder, gCurrentLoadingFolderViewType, gCurrentLoadingFolderViewFlags, gCurrentLoadingFolderSortType, gCurrentLoadingFolderSortOrder);

(in mail/base/content/msgMail3PaneWindow.js:210)

RerootFolder() sets "NoMail", but new mail notification window hasn't popped up yet.  So the race condition occurs.

I can re-produce the bug on OpenSolaris and I believe this also exits on Linux.
So I think we also need to made a patch for Linux and OpenSolaris.

Maybe we can make a similar patch for nsMessengerUnixIntegration.cpp?
Comment on attachment 349256 [details] [diff] [review]
proposed fix

I've not tested this, but it looks fine, and I'm assuming you have.
Attachment #349256 - Flags: superreview?(bugzilla)
Attachment #349256 - Flags: superreview+
Attachment #349256 - Flags: review?(bugzilla)
Attachment #349256 - Flags: review+

Comment 8

9 years ago
(In reply to comment #7)
> (From update of attachment 349256 [details] [diff] [review])
> I've not tested this, but it looks fine, and I'm assuming you have.
The patch seems only fixing on MS Windows. But how about Unix?

Comment 9

9 years ago
I've checked in this patch, with one small change - we insert new folders at the front of the list, so the most recent server to get hits shows up first...

yes, this is windows-only. I don't have linux here.
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 10

9 years ago
Since the bug still exists on Linux, I suggest to re-open the bug and change the platform to "Linux".

Comment 11

9 years ago
I'd much prefer a new bug for linux, thx!

Comment 12

9 years ago
Ok, I'll file a new bug

Comment 13

9 years ago
Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081126 Lightning/1.0pre Shredder/3.0b1pre

Comment 14

9 years ago
Sorry, but I can still see the broken alert

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081127 Lightning/1.0pre Shredder/3.0b1pre
Reopening based on comment 14 (from original reporter).
Resolution: FIXED → ---

Comment 16

9 years ago
Just for reference, the unix port of attachment 349256 [details] [diff] [review] was bug 466784.
Whiteboard: DUPEME → [one case fixed, another still broken - see comment 6]

Comment 17

9 years ago
This bug per it's summary is fixed - filed bug 471772 about the remaining issue.
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.