"error truncating... delete...MSF" dialogs excessive

UNCONFIRMED
Unassigned

Status

UNCONFIRMED
13 years ago
6 years ago

People

(Reporter: gojomomozillabugzilla, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [driver: WONTFIX?])

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc3 Firefox/1.0.7
Build Identifier: Thunderbird version 1.5 (20051201)

When a certain error occurs, the number of dialogs to report it, after each message is filtered, is excessive.

Background:

Sometimes some corruption happens that results in me getting a modal error dialog like: "There was an error truncating the Inbox after filtering a message to folder 'Junk'. You may need to shutdown Thunderbird and delete INBOX.msf."

Deleting the MSF offers temporary recovery, and there is another bug (321371; https://bugzilla.mozilla.org/show_bug.cgi?id=321371 ) addressing the underlying cause. 

This issue is specifically regarding the number of modal dialogs requiring dismissal that come up. Every message that is filtered out of the Inbox generates a new dialog, and mail-checking (and all interaction with the UI) is locked out until the dialog is dismissed. Almost instantly afterwards, another identical dialog can pop. 

So when facing the message "Downloading 1 of 1217" and this dialog, knowing that most if not all messages will also trigger a dialog, a user is essentially locked out of the UI until they (1) click OK 1000+ times; (2) kill thunderbird; or (3) manage to cancel the mail-download in progress before a new dialog pops. (This may not be possible in all situations; I've been able to do it by repositioning the dialog 'OK' directly over the 'stop the current transfer' button and clicking twice rapidly.)

When encountering this underlying error, or similar errors that occur up to once per transfered message, a modal dialog should not be used to report each occurence, and/or if a dialog must be used, the transfer should be cancelled or an option to cancel the transfer should be offered. 

Reproducible: Always

Steps to Reproduce:
Happens every time the underlying MSF is corrupted; but that only happens intermittently (perhaps due to other background indexing/scanning programs touching Thunderbird files). 

Actual Results:  
Lots of modal dialogs appear in arbitrarily long series.

Expected Results:  
Only one dialog appears. Or, each dialog that appears offers a chance to cancel the dialog-producing process.

Comment 1

13 years ago

*** This bug has been marked as a duplicate of 321371 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 2

13 years ago
Reopening, since I missed the part where you'd already noticed the dupe -- 
but I think having a bug open for a side effect of another bug that needs to 
be fixed is unnecessary.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Reporter)

Comment 3

13 years ago
I suspect that even if the underlying bug is fixed such that 'error truncating' never (or very very rarely) happens, there will still be a 'just in case' catch of certain kinds of errors per message/per-filter-action. (Perhaps there are already other rare errors that behave similarly with a slightly different message; I don't know.) The theory behind having a separate bug is that such modal dialog pops should not occur in the tight retrieve-filter loop. 

Other things to consider: (1) it may prove difficult to fix the underlying bug, but easier (and useful) to improve the problematic reporting. (2) it might fall to a completely different person to improve the error-condition reporting than to tackle the 'error truncating' filesystem issue. So it could still make sense to split the issues. 

But, whatever fits the Mozilla process/responsibilities is fine by me... I just wanted the UI upshot of the other bug -- hundreds of dialogs or a kill-quit -- to be recorded somewhere for proper assessment.
QA Contact: front-end

Comment 4

11 years ago
Gordon do you still see the truncate issue?
(Reporter)

Comment 5

11 years ago
Yes, as of TB 2.0.0.6 on Windows XP. And my workaround is still the same: drag the warning dialog so that its 'close' is directly above 'stop' so I can hit 'close'+'stop' before the next popup, then quit TB cleanly, find the 'inbox.msf' file, delete it, restart. 

Sometimes I go for days without seeing it. Other times I see it more than once per day. 
(Reporter)

Comment 6

11 years ago
It looks like the core 'truncate' issue is mainly being investigated (with some recent activity) at the 321371 bug. But given the intermittent nature and longevity of that bug so far, I still think some improvement in the error-reporting (the gist of this issue) would be worthwhile, in particular removing the prospect of 1-dialog-per-message-received-in-a-tight-loop. 
(Reporter)

Comment 7

11 years ago
I just had the joy of dismissing this dialog 71 times -- my usual workaround of drag the dialog so its 'close' is directly over the 'stop' toolbar button, and clicking twice in rapid succession, apparently doesn't work reliably while other slow POP fetches are also happening in parallel. 

And then, when only the dialog-popping mailbox was being checked, a few clicks in rapid succession atop the dialog-close/stop-toolbar crashed Thunderbird. That happens sometimes with this rapid-click workaround; I have to remember to only click twice. 

I keep a shortcut on my desktop to the mailboxes folder, so I can go through the "MSF" delete dance when this pops up, a couple times a week. 

Seriously, even if Thunderbird can't stop the 'error truncating' problem, and can't automate the perfunctory delete-and-rebuild of the the MSF file (bug #321371), can't the MODAL DIALOG be removed from a EVERY-NEW-MESSAGE loop that's IMPOSSIBLE-TO-CANCEL from the dialog (this bug)? 

Comment 8

10 years ago
(In reply to comment #2)
> Reopening, since I missed the part where you'd already noticed the dupe -- 
> but I think having a bug open for a side effect of another bug that needs to 
> be fixed is unnecessary.

David, WONTFIX? 

I come back to Mike's point. Fixing the source problem bug 321371 STM the correct action. Unless you or bryan confirm this as worthy and desirable - perhaps aspects of this are dupe of bryan's developing enhanced status bar work.
Assignee: mscott → nobody

Updated

9 years ago
Whiteboard: [driver: WONTFIX?]

Updated

9 years ago
Depends on: 321371
I'm getting this error, in the latest (ver 5.00 VERSION OF Thunderbird, with Lightning installed, on Win XP, as follows:

There was an error truncating the Inbox after filtering a message to folder 'Meetup'. You may need to shutdown Thunderbird and delete INBOX.msf.


Warning: Unknown property 'box-sizing'.  Declaration dropped.
Source File: https://www.mozilla.org/en-US/thunderbird/5.0/start/?uri=/thunderbird/start&locale=en-US&version=5.0&os=WINNT&buildid=20110624125636
Line: 15

Warning: Unknown property 'transition'.  Declaration dropped.
Source File: https://www.mozilla.org/en-US/thunderbird/5.0/start/?uri=/thunderbird/start&locale=en-US&version=5.0&os=WINNT&buildid=20110624125636
Line: 138

Warning: Unknown property 'transform'.  Declaration dropped.
Source File: https://www.mozilla.org/en-US/thunderbird/5.0/start/?uri=/thunderbird/start&locale=en-US&version=5.0&os=WINNT&buildid=20110624125636
Line: 147

Warning: Unknown property 'transition'.  Declaration dropped.
Source File: https://www.mozilla.org/en-US/thunderbird/5.0/start/?uri=/thunderbird/start&locale=en-US&version=5.0&os=WINNT&buildid=20110624125636
Line: 152

Warning: Unknown property 'transform'.  Declaration dropped.
Source File: https://www.mozilla.org/en-US/thunderbird/5.0/start/?uri=/thunderbird/start&locale=en-US&version=5.0&os=WINNT&buildid=20110624125636
Line: 159

Warning: Unknown property 'transition'.  Declaration dropped.
Source File: https://www.mozilla.org/en-US/thunderbird/5.0/start/?uri=/thunderbird/start&locale=en-US&version=5.0&os=WINNT&buildid=20110624125636
Line: 171

2011-08-09 14:28:44	gloda.datastore	ERROR	got error in _asyncTrackerListener.handleError(): 19: PRIMARY KEY must be unique

Comment 10

7 years ago
easyrider55: What you are seeing is probably bug 668952

Comment 11

6 years ago
shovel pass to blake...

(In reply to Wayne Mery (:wsmwk) from comment #8)
> (In reply to comment #2)
> > Reopening, since I missed the part where you'd already noticed the dupe -- 
> > but I think having a bug open for a side effect of another bug that needs to 
> > be fixed is unnecessary.
> 
> David, WONTFIX? 
> 
> I come back to Mike's point. Fixing the source problem bug 321371 STM the
> correct action. Unless you or bryan confirm this as worthy and desirable -
> perhaps aspects of this are dupe of bryan's developing enhanced status bar
> work.
Flags: needinfo?(bwinton)
Well, I think that popping up a whole bunch of modal dialogs is kind of mean, and we should probably avoid that.  Particularly since it sounds like there's nothing the user can do on this dialog to fix the problem.  So I wouldn't mark this as WONTFIX, I don't think…
Flags: needinfo?(bwinton)
You need to log in before you can comment on or make changes to this bug.