Closed Bug 355194 Opened 15 years ago Closed 13 years ago

Local/POP3 'Rebuild Summary File' generates "error, exception, ..." in <widgetglue.js>

Categories

(MailNews Core :: Database, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0a3

People

(Reporter: sgautherie, Assigned: rkent)

References

Details

Attachments

(1 file)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061002 SeaMonkey/1.1b] (nightly) (W98SE)

1. Context-click a folder
2. Select Properties...
3. Rebuild Index
r. When the task ends, I get the one/two following errors:

Depending on emtpyness and/or on type of folder !?
{
Error: uncaught exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMsgFolder.updateFolder]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://messenger/content/widgetglue.js :: RebuildSummaryFile :: line 284"  data: no]
}
(then)
Always
{
Error: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgDBView.searchSession]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: chrome://messenger/content/commandglue.js :: RerootFolder :: line 371"  data: no]
Source File: chrome://messenger/content/commandglue.js
Line: 371
}

As I remember, I tried this feature when it was added no so long ago,
and there was no error:
this may be a regression !?
Flags: blocking-seamonkey1.1b?
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20060919 SeaMonkey/1.1b] (nightly) (W98SE)

(This bug was already in the -0919 build at least.)


'blocking&#8209;seamonkey1.1b=?':
This bug does not seem major in itself (yet),
but, as it is a new feature, I think it would be better for it to work as cleanly as possible before v1.1b.
It's a nice though hopefully rarely used feature if it works, but we won't push back the beta for something apparently not seen by anyone else than you, sorry.
It would be good to investigate this though, and we'll probably be able to take a fix after beta or even in a later 1.1.x release if needed.
Flags: blocking-seamonkey1.1b? → blocking-seamonkey1.1b-
Same problem also occurs on Thunderbird trunk - version 3.0a1 (20070411) on Win-XP SP2 - when "Rebuild Index" is executed.
Difference is line number only.
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMsgFolder.updateFolder]"
> nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"
> location: "JS frame :: chrome://messenger/content/widgetglue.js ::
> RebuildSummaryFile :: line 249"  data: no]
Then all mail in the mail folder is lost.

This problem - all mail lost after "rebuilding index" - also occurs when manual recovery of .msf file (delete .msf and restart Thundebird/Seamonkey/Mozilla).

Changing to "Core", and changing to "Critical" because "dataloss". 
Assignee: mail → bienvenu
Severity: normal → critical
Component: MailNews: Main Mail Window → MailNews: Database
Keywords: dataloss
Product: Mozilla Application Suite → Core
QA Contact: database
Version: 1.8 Branch → Trunk
I think the last problem is a new problem, new to the trunk, and really deserves its own bug, w/o confusing the issue in this bug.
(In reply to comment #4)
> I think the last problem is a new problem, new to the trunk
According to your Bug 363008 Comment #1, it seems that "mail loss" didn't occur previously even the JS error was issued.
I'll open new bug for "mail data loss on trunk" problem.   
Change back severity/product/component to original.
Assignee: bienvenu → mail
Severity: critical → normal
Component: MailNews: Database → MailNews: Main Mail Window
Keywords: dataloss
Product: Core → Mozilla Application Suite
QA Contact: database
Version: Trunk → 1.8 Branch
I've opend Bug 377239 for "mail loss" after "Rebuild Index" error on Trunk.
Sorry for spam.
As I reported to FIXED/VERIFIED Bug 377239 Comment #4, this bug (Bug 355194, Error message when Rebuild index, No impact in using Tb) still remains on Thunderbird latest trunk, even though "mail loss when trunk" problem has been resolved by a patch for Bug 196732.
Changing to Component=Core again. Sorry for spam.
Assignee: mail → bienvenu
Component: MailNews: Main Mail Window → MailNews: Database
Product: Mozilla Application Suite → Core
QA Contact: database
Version: 1.8 Branch → Trunk
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070421 SeaMonkey/1.1.1] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070421 SeaMonkey/1.5a] (nightly) (W2Ksp4)

*OS: W98 -> W2K, as I'm not using W98 anymore.

(In reply to comment #0)

> Depending on emtpyness and/or on type of folder !?
> {
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMsgFolder.updateFolder]"  nsresult:
> "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
> chrome://messenger/content/widgetglue.js :: RebuildSummaryFile :: line 284" 
> data: no]
> }

Error still there:
local/POP3: always; IMAP: never.

> (then)
> Always
> {
> Error: [Exception... "Component returned failure code: 0x80004001
> (NS_ERROR_NOT_IMPLEMENTED) [nsIMsgDBView.searchSession]"  nsresult: "0x80004001
> (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame ::
> chrome://messenger/content/commandglue.js :: RerootFolder :: line 371"  data:
> no]
> Source File: chrome://messenger/content/commandglue.js
> Line: 371
> }

I don't get this error anymore.
OS: Windows 98 → Windows 2000
Summary: 'Rebuild Index' generates 1-2, "error, exception, ..." in <commandglue.js> and <widgetglue.js> → Local/POP3 'Rebuild Summary File' generates "error, exception, ..." in <widgetglue.js>
Duplicate of this bug: 387585
OS: Windows 2000 → All
Hardware: PC → All
Product: Core → MailNews Core
Since I'm looking at issues associated with rebuild in bug 449768, and I hate seeing this error whenever I test rebuilds, let me take this bug and see if I can get rid of it.
Assignee: bienvenu → kent
This error comes from this code in nsLocalMailFolder.cpp:

    // if we have to regenerate the folder, run the parser url.
    if(folderOpen == NS_MSG_ERROR_FOLDER_SUMMARY_MISSING ||
      folderOpen == NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE)
    {
      if(NS_FAILED(rv = ParseFolder(aMsgWindow, aReparseUrlListener)))
      {
        if (rv == NS_MSG_FOLDER_BUSY)
        {
          mDatabase->RemoveListener(this);  //we need to null out the db so that parsing gets kicked off again.
          mDatabase = nsnull;
          ThrowAlertMsg("parsingFolderFailed", aMsgWindow);
        }
        return rv;
      }
      else
        return NS_ERROR_NOT_INITIALIZED;
    }

That is, this error is thrown when ParseFolder SUCCEEDS - and I believe is meant to be an expected error that just says that the database exists, but is currently being initialized by the parser. So I think all I need to do is to stop propogation of this error, and document it as an expected non-error return.
Status: NEW → ASSIGNED
If you accept my analysis, this will remove the error. What do you think, David?
Attachment #333858 - Flags: superreview?(bienvenu)
Attachment #333858 - Flags: review?(bienvenu)
Bienvenu, can I get some comments on the proposed solution here?
Does the case of a summary file that's out of date still work? E.g., the file size is different that what's stored in the summary file? Does the case of a missing summary file still work? Basically, if you change this code this way, a bunch of things need to be tested...
I scanned through all of the calls to UpdateFolder, and the only substantial action ever taken based on the error return is to clear the busy cursor in commandglue.js  In the vast majority of cases, the error return is not checked.

So I don't see how this change can have any effect other than to remove the spurious error message display.
Attachment #333858 - Flags: superreview?(bienvenu)
Attachment #333858 - Flags: superreview+
Attachment #333858 - Flags: review?(bienvenu)
Attachment #333858 - Flags: review+
Comment on attachment 333858 [details] [diff] [review]
NS_ERROR_NOT_INITIALIZED is expected
[Checkin: Comment 17]

ok, thx for checking. An other alternative would be simply to catch the exception in js, but you're right; as of now, no one checks for that error.
Keywords: checkin-needed
Checked in, changeset id: 302:7329bb555545
Keywords: checkin-needed
Target Milestone: --- → Thunderbird 3.0b1
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #333858 - Attachment description: NS_ERROR_NOT_INITIALIZED is expected → NS_ERROR_NOT_INITIALIZED is expected [Checkin: Comment 17]
V.Fixed between
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080909002343 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
and
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080910003607 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.