439763 - New filter dialog broken

Status: VERIFIED DUPLICATE of bug 441429

(Thunderbird :: General, defect)

Description

[David Ascher (:davida)]

Attachment: screenshot

will attach screenshot.

it's impossible to specify conditions for new filters.

Comment 1

[Kent James (:rkent)]

I'm seeing something similiar. When I try to define a new search (by right clicking on a folder, and selecting Search ...) I get a search dialog that fails.

Main symptom: the "Search for messages in " field is always blank, regardless of what I do.

Error console is showing:

no element found: chrome://messenger/content/msgFolderPickerOverlay.xul

along with complaints about SetFolderPicker not defined.

David, what do you see in the error console?

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Related to bug 436630? That was the bug with a checkin in the past week with something related to msgFolderPickerOverlay.

Comment 3

[Kent James (:rkent)]

If I back out attachment 324903 [details] [diff] [review] from bug 436630 my search symptoms go away.

Comment 4

[Phil Ringnalda (:philor)]

Kent: new bug, please. Failing to load the condition part of the new filter dialog is not the same bug as failing to load the folder picker in the search dialog and trying to load a removed overlay, not even if Joey caused them both.

David: could you do some experimenting, please? Do you still get the same broken dialog with the same profile running an old nightly (say, a few months ago)? And do you get a working dialog in a new profile with the current build? And have you defined custom headers for filters, and if someone reminds us where those are stored and you move that file out of your profile, does it work again? I don't see your bug in any of my profiles on any of my machines, but I did get that same effect when I corrupted some file while screwing up patching bug 413680, so I suspect you're seeing corruption rather than fresh UI breakage.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: screenshot with fresh profile

This occurs on a fresh profile as well. Debug 3.0a2pre TB build on Leopard 10.5.3 from this morning's checkout.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

If this helps, when I click the "New" button in the Message Filters dialog, the following assertion gets triggered:

###!!! ASSERTION: forward references have already been resolved: 'Error', file /Users/skywalker/Desktop/Mozilla/cvs/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1095

followed by this error:

JavaScript error: chrome://messenger/content/searchTermOverlay.js, line 254: gSearchTermList is null

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: screenshot with fresh profile and 1 newly added IMAP account

Comment 9

[Joey Minta]

Are people still seeing this bug with today's nightly? Or did bug 440196 fix this?

Comment 10

[Phil Ringnalda (:philor)]

Hmm, I probably duped the wrong way with bug 440955 - with today's nightly on the Windows box where Wednesday I wasn't seeing any problem at all, I'm seeing a once-per-run bug 440196 effect: start Tb, filters, New, no conditions and an empty box for action with "no element found" and "failed to load overlay" errors, then every subsequent New works perfectly until I close Tb. So I'm seeing that bug 440196 is only fixed for times after the first (and perhaps some previous bogus-looking include was there to get something cached); Mitra might be seeing that only without as much predictability; davida must have been seeing something else to get the folderpicker part without the action part. Want to do that in a reopened bug 440196, or a reopened bug 440955?

Comment 11

[Mitra Ardron]

Either way ... the requested stuff from Error Console is:

SetFolderPickerElement is not defined - in chrome://messenger/content/searchWidgets.xml line 515   when the dialogue opens, 
and
SetFolderPickerElemenent is not defined in 
chrome://messenger/content/FilterEditor.xul line 1 
when I try to select a folder to move a message to.

P.S. Any good way to cut-and-paste- out of Error Console (if not, that should be an enhancement request)

Comment 12

[Serge Gautherie (:sgautherie)]

Bug 440196 was for <SearchDialog.xul>;
this one is for <FilterEditor.xul> ;->

Comment 14

[Serge Gautherie (:sgautherie)]

V.Duplicate, per bug 441429 comment 4.

Comment 15

[Phil Ringnalda (:philor)]

Actually, it almost certainly wasn't a duplicate of bug 441429 - note that it was filed an hour and a half before the patch that caused bug 441429 was checked in, and that the bug 441429 symptom was a blank space separating the "for incoming..." label from the "perform these..." label, while this bug's symptom was visible radio buttons, but a condition listbox just a few pixels high, a combination of something unknown and unknowable which persisted a bogus height for the dialog with the way that the condition listbox doesn't have anything to give it a min-height when the dialog shrinks, so it looked broken instead of too small and davida didn't try to expand it until he rebuilt and was also hitting bug 441429. But I guess since only eleven words and the screenshot in this bug are actually *about* this bug, we might as well leave it, and I'll file a new one for working around it.

Comment 16

[Serge Gautherie (:sgautherie)]

(In reply to comment #15)
> bug 441429 symptom was a blank space separating the
> "for incoming..." label from the "perform these..." label, while this bug's

Bug 441429 was looking like Gary Kwong's 2 screenshots.
Maybe they were showing two bugs at once ?
At least, it seems bug 441429 patch fixed it/both...

> But I guess since only eleven words and the
> screenshot in this bug are actually *about* this bug, we might as well leave

I concur that I never understood what the issue was from DavidA's comment 0 text and screenshot.

> it, and I'll file a new one for working around it.

If there is (still) "another" bug,
please, (re)file it and and a comment here.