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

Status: VERIFIED FIXED

(MailNews Core :: Database, defect)

Description

[Serge Gautherie (:sgautherie)]

[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 !?

Comment 1

[Serge Gautherie (:sgautherie)]

[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‑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.

Comment 2

[Robert Kaiser]

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.

Comment 3

[WADA:World Anti-bad-Duping Agency]

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". 

Comment 4

[David :Bienvenu]

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.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(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.

Comment 6

[WADA:World Anti-bad-Duping Agency]

I've opend Bug 377239 for "mail loss" after "Rebuild Index" error on Trunk.
Sorry for spam.

Comment 7

[WADA:World Anti-bad-Duping Agency]

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.

Comment 8

[Serge Gautherie (:sgautherie)]

[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.

Comment 10

[Kent James (:rkent)]

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.

Comment 11

[Kent James (:rkent)]

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.

Comment 12

[Kent James (:rkent)]

Attachment: NS_ERROR_NOT_INITIALIZED is expected [Checkin: Comment 17]

If you accept my analysis, this will remove the error. What do you think, David?

Comment 13

[Kent James (:rkent)]

Bienvenu, can I get some comments on the proposed solution here?

Comment 14

[David :Bienvenu]

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...

Comment 15

[Kent James (:rkent)]

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.

Comment 16

[David :Bienvenu]

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.

Comment 17

[Mark Banner (:standard8)]

Checked in, changeset id: 302:7329bb555545

Comment 18

[Serge Gautherie (:sgautherie)]

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)