279546 - In <FilterEditor.js>, "Error: SetBusyCursor is not defined"

Status: RESOLVED WORKSFORME

(MailNews Core :: Filters, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Error: SetBusyCursor is not defined
Source File: chrome://messenger/content/FilterEditor.js
Line: 202

1.  Tools -> Message Filters -> (Enter a condition, such as "Subject contains
[foo]")
2.  Click the "Move to Folder" checkbox.
3.  Since I'm using IMAP, select the top-level Inbox and 'Choose this folder for
parent'.

Comment 1

[Serge Gautherie (:sgautherie)]

Reporter:
For the record, could you write which software & release you are running ?

This code seems to be (CVS documented as) IMAP related:
I have no IMAP account to test with...

Neil:
<http://lxr.mozilla.org/mozilla/search?string=SetBusyCursor>
returns (at least)
{{
/mailnews/base/resources/content/msgMail3PaneWindow.js, line 1497 -- function
SetBusyCursor(window, enable)
/mailnews/base/search/resources/content/FilterEditor.js, line 707 -- function
SetBusyCursor(window, enable)
}}
1) |SetBusyCursor()| is defined in the very file: how can it be undefined ?
2) I wonder if the FilterEditor function could be removed/superceded by the
msgMail3PaneWindow one ??

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

Build 2005-01-23-05, Windows XP Seamonkey trunk.

Comment 3

[[e-mail]]

There is a reason that SetBusyCursor might not be defined; the function is
called from a JavaScript object that is registered as a C++ callback whenever
you create a new IMAP folder, and that makes it possible for it to outlive the
window where SetBusyCursor is defined: although there is code to remove the
callback it only gets called when the window is closed, while the code to
register the callback gets called whenever a new folder is created. Thus if you
create two new IMAP folders before closing the window it might happen that the
callback is still registered. Then when you next create an IMAP folder, the
callback has outlived the window and therefore fails to call SetBusyCursor.

Comment 4

[Wayne Mery (:wsmwk)]

Serge, leaving assigned to you :)

Comment 5

[:aceman]

Is this still relevant? The filter editor was reworked since.
Neil, Serge?

Comment 6

[:aceman]

The adding of the listener in SearchNewFolderOkCallback is now guarded by gSessionFolderListenerAdded variable, changed (oh, by me) in bug 736870. It looks to me the previous version of the file with gMailSession didn't prevent AddFolderListener to run multiple times.

Neil, do you think that change may fix the bug here? Or did you mean some other place in comment 3?

Comment 7

[[e-mail]]

(In reply to :aceman from comment #6)
> The adding of the listener in SearchNewFolderOkCallback is now guarded by
> gSessionFolderListenerAdded variable, changed (oh, by me) in bug 736870. It
> looks to me the previous version of the file with gMailSession didn't
> prevent AddFolderListener to run multiple times.
> 
> Neil, do you think that change may fix the bug here? Or did you mean some
> other place in comment 3?

I can't remember, but it seems reasonable.

Comment 8

[:aceman]

Does anybody see this in current Thunderbird/Seamonkey? If nobody responds we should close this as it looks outdated.

I think Serge is not working on this.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to :aceman from comment #8)
> Does anybody see this in current Thunderbird/Seamonkey? If nobody responds
> we should close this as it looks outdated.
> 
> I think Serge is not working on this.

No idea, I'm happy to close it or have others close it as WFM.

Comment 10

[Wayne Mery (:wsmwk)]

WFM as far as I'm concerned