837530 - Archiving Large Amount of Message Results in Unresponsive Script Warning

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Daniel Morante]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

Select 8,894 email messages in my inbox and click "Archive"


Actual results:

Emails began to get archived as desired.  The user interface froze and a few seconds later a pop-up window appeared stating

"Warning: Unresponsive Script"
A script on this page may be busy, or it may have stopped responding.  You can stop the script now, or you can continue to see if the script will complete.

Script: resource:///components/newMailNotificationService.js:304

Options are "continue" or "cancel". 
There is also an option that says "Don't ask me again", I am not sure what that will do so I leave it un-selected.

At this point mail is no longer archiving and the program is waiting for my input.

I click "Continue".

Mail starts to archive again.  a Few seconds later the same pop-up appears.  I repeat.  

After about 10 pop-ups, I decide to enable the "Don't ask me again" option.  The pop-up no longer appears but my user interface is frozen with no feedback on to the current status.


Expected results:

A clear status should be presented to the end user as to what is happening and there should be no pop-ups that pause the process requiring user intervention.  The User interface should not give the impression that the program has "frozen" or crashed.

Comment 1

[herrsergio]

Same problem with Thunderbird 17.0.2 in Debian, trying to delete 6000 emails in an IMAP account.

Comment 2

[WADA:World Anti-bad-Duping Agency]

"Archive many mails" is a "mass mail move", and "Delete many mails" is also a "mass mail move"(merely move target is special Trash).
"Mail move" is roughly consists of;
  "single mail move" : "mail copy to target"      + "Shift+Delete at source".
  "mass   mail move" : "bulk mail copy to target" + "bulk Shift+Delete at source"
  a "Shift+Delete at source" : 
    local mail folder : Set expunged_bit=On in X-Mozill-Status: in folder file,
                        Remove msg data from msgDB  
    IMAP folder       : uid xxx store +Flags (\Deleted)
                        Remove msg data from msgDB(non Just mark it as deleted)
                        Flag as deleted in   msgDB(Just mark it as deleted)
And, because of "mass move", "Selection of many mails at Thread Pane" is also involved.

Currently, performance issue(high CPU, large memory consumption, long time to complete etc.) is already known in "Remove msgDBHdr from msgDatabase" part of above "bulk Shift+Delete at source" phase.
A one of major causes of it is "threading related data update of all not-deleted-yet mails is required when a mail is deleted".

If local mail folder, "bulk mail copy to target" phase may participate to problem, especially when mail folder at remote server due to small write buffer size.

Other one of major causes of performance problem are "additional resource is needed per a selected message", "thread pane refresh of all not-deleted-yet mails is required when a mail is deleted" and so on.

In both cases, problem may be that order of required resources(CPU/Memory or Objects/Time etc.) is not O("number of deleted mails"), is O("number of deleted mais"**2) or O("number of deleted mail"!) like one instead.

"Warning: Unresponsive Script" itself is simply a result of "JavaScript code execution for mass mail move is taking very long time". It's merely a report from a "JavaScript code execution watcher" like module.
See bug 452221 comment #4. I could wait till "2000 mails delete" case but I also couldn't afford to wait for so long time when "4000 mails delete" case.

If "mass 'Mark Mails as Junk/Non-junk'", it's far worse than simple "mass mail move", because "mass 'Mark Mails as Junk/Non-Junk'" consists of "mass Bayesian Filter data update" and "mass mail move" and because "mass Bayesian Filter data update" also requires many Object resources/Memory resources/CPU resources and also takes long. 

Problem is not in "Warning: Unresponsive Script" itself.
"The user interface froze" is a result of "main UI process/task is hi-jacked by very very heavy mass mail move job what is executed under same process/task".
Simple "Warning was issued multiple times when I deleted NN mails" like report or simple "me too" like report can not help performance related problem analysis and resolving performance related problem.

Because performance problem, quantitative data is mandatory to analyze problem.
At least, rule out already known problem of bug 452221, and bugs set in dependency tree for bug 452221, from your case. please.

Comment 3

[WADA:World Anti-bad-Duping Agency]

If IMAP, and if "Just mark it as deleted", "remove msg data from msgDB" part is not needed at source folder. So, comparison of ""Just mark it as deleted" case and "Remove immediately" case may help problem analysis. And, difference of "Move to trash" from "Remove immediately" is "copy to target(=Trash folder)" phase, so workload/required resources/time etc. for "copy to target" can be measured, if measurements starts from same states(same mail data in same mail folder).

Comment 4

[najpierwbrowarek]

(In reply to Daniel Morante from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101
> Firefox/18.0
> Build ID: 20130116073211
> 
> Steps to reproduce:
> 
> Select 8,894 email messages in my inbox and click "Archive"
> 
> 
> Actual results:
> 
> Emails began to get archived as desired.  The user interface froze and a few
> seconds later a pop-up window appeared stating
> 
> "Warning: Unresponsive Script"
> A script on this page may be busy, or it may have stopped responding.  You
> can stop the script now, or you can continue to see if the script will
> complete.
> 
> Script: resource:///components/newMailNotificationService.js:304
> 
> Options are "continue" or "cancel". 
> There is also an option that says "Don't ask me again", I am not sure what
> that will do so I leave it un-selected.
> 
> At this point mail is no longer archiving and the program is waiting for my
> input.
> 
> I click "Continue".
> 
> Mail starts to archive again.  a Few seconds later the same pop-up appears. 
> I repeat.  
> 
> After about 10 pop-ups, I decide to enable the "Don't ask me again" option. 
> The pop-up no longer appears but my user interface is frozen with no
> feedback on to the current status.
> 
> 
> Expected results:
> 
> A clear status should be presented to the end user as to what is happening
> and there should be no pop-ups that pause the process requiring user
> intervention.  The User interface should not give the impression that the
> program has "frozen" or crashed.

I had the same problem.
My solution:
Don't go into folder Spam or Trash - just click (right mouse b)and choose Clear Spam or Clear Trash (maybe in english version it has other text, but I hope You get it ;)
Although this is not solving the bug, but works with no errors.

Comment 5

[Wayne Mery (:wsmwk)]

Do you still see this problem?

Comment 6

[Jerry Baker]

I am seeing this today in Tbird 45.4.0.

Comment 7

[Jerry Baker]

Attachment: Warning dialog

Comment 8

[Jerry Baker]

Attachment: Warning Dialog

Comment 9

[Brian Hauer]

I routinely see an unresponsive script warning message when doing operations such as deleting or moving a large number (e.g., 5000) of messages.  This is on an otherwise extremely fast workstation with an M.2 SSD.

When deleting a large number of messages, the warning dialog cites the following script:

chrome://messenger/cotent/folderPane.js:2113

Depending on how many messages I've selected for the operation, the operation can take a very long time, meaning I will see several of these dialogs unless I click "Don't ask me again."  Meanwhile, the Thunderbird window's title bar is frequently flipped to "Not Responding" by Windows during one of these large operations.

I find it surprising that Thunderbird does delete and move operations on the main user interface thread rather than a background thread.  And maybe it is *attempting* to use a background thread, but if so, the main UI thread is nevertheless being blocked by the operation.