Closed Bug 212625 Opened 21 years ago Closed 17 years ago

drop-down box doesn't open after selecting customize header in Filter rules/Search messages dialogs

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: Matti, Assigned: neil)

References

Details

(Keywords: regression)

Attachments

(2 files)

Ugly hack
740 bytes, patch
mscott
: review+
Bienvenu
: superreview+
asa
: approval1.6+
Details | Diff | Splinter Review
Best I could do
517 bytes, patch
Details | Diff | Splinter Review 
using win2k build 20030712 and the modern Theme

1) open Mailnews :-)
2) select Tools/Message Filter/New
3) select "Customize" in the drop-down box with the default "Subject"
4) select cancel
5) try to open the Drop-Down again : doesn't work


works in 1.4, NS7.1 , 1.3.1
I can see this on Win2k with a CVS-trunk-build of 2003-07-16~05, too.
After 
a. hitting the Escape key, or
b. hitting Tab key, or
c. canceling the "New" window also and reoping it again (step 2)],
I can go through steps (3)(4) again *once*.
Clicking into the dropdownbox has no effect, it does not get the focus.
Summary: drop-down box opens only once → drop-down box opens only once
*** Bug 218272 has been marked as a duplicate of this bug. ***
-> (hopefully) improving summary

This also occurs in "Tools / Search messages" dialog.
Summary: drop-down box opens only once → drop-down box doesn't open after selecting customize header in Filter rules/Search messages dialogs
*** Bug 218361 has been marked as a duplicate of this bug. ***
*** Bug 214852 has been marked as a duplicate of this bug. ***
according to a dupe...
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 218814 has been marked as a duplicate of this bug. ***
Another work-around: For me (mozilla 1.5a on Solaris/SPARC 8 with Gnome2) it
helps to hit TAB after using the Custom subform:  Now I can again type in text
fields on the main form and make selections from the just-customized pull-down list.

I also get this bug on Win2k with build 0.3 RC2
*** Bug 219361 has been marked as a duplicate of this bug. ***
The text boxes also refuse to work once this occurs.  Using 1.5RC2.
*** Bug 217136 has been marked as a duplicate of this bug. ***
*** Bug 221748 has been marked as a duplicate of this bug. ***
*** Bug 221786 has been marked as a duplicate of this bug. ***
*** Bug 222120 has been marked as a duplicate of this bug. ***
*** Bug 222418 has been marked as a duplicate of this bug. ***
*** Bug 222385 has been marked as a duplicate of this bug. ***
See bug 209634 comment 14.

It sounds like someone was depending on a bug, and then the bug got fixed.  The
someone should stop depending on it, or something.
Do be more precise, either the method at
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWidgets.xml#1083
is buggy or it should not be called when customize is _cancelled_.  The caller
is
http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWidgets.xml#1209
(and note that it's unconditional).

Looking at the code, it looks like it should all work; someone who actually
knows what it's trying to accomplish would need to see where it's failing...
This problem occurs whether Cancel or OK is hit.  

Besides the problem with the dropdown box (which, you will notice, continues 
with the odd inverted text coloration after the Custom box is dismissed), the 
edit fields for the filter comparison string and for the filter name become 
unusable (show caret, but can't type).  If you hit More to add a filter, the 
dropdown for the new rule is usable but the edit fields are still not usable.
*** Bug 197177 has been marked as a duplicate of this bug. ***
*** Bug 224435 has been marked as a duplicate of this bug. ***
When the two lines which remove the menu items in the method refreshList() of
mailWidget.xml are commented out, the bug disappears. (Then you end up with all
menu items duplicated, so this is not the fix. But maybe this information helps
to find the right fix.)
*** Bug 224742 has been marked as a duplicate of this bug. ***
*** Bug 224975 has been marked as a duplicate of this bug. ***
After noticing that bug Bug 197177 was marked as a dupe of this bug, I tested
with Mozilla 1.3. This bug was already present in this version in a slightly
different form.

With Mozilla 1.3 after you leave the "Customize Headers" dialog, the drop-down
box in the Search/Filter dialiog is still selected, but you can use it normally.
When you tab to the textfield you can't type anything.

With later Mozilla versions additionally the drop-down box is not usable after
leaving the "Customize Headers" dialog.

So this bug was already present before Boris' checkin, but probably got worse
after it.
Attached patch Ugly hack — — Splinter Review 
We're actually removing a menuitem during its command event.
So here's an ugly hack to avoid that.
Probably a neater method would be to refresh the list when the popup opens.
*** Bug 225757 has been marked as a duplicate of this bug. ***
Neil: Your "ugly hack" fixes the bug for me (including Bug 197177). I think it
would be a good idea to check this in for 1.6. Perhaps you could add a comment
referring to this bug to explain why this hack is necessary. Do you agree?
Comment on attachment 135412 [details] [diff] [review]
Ugly hack

Let's ask a module owner.

The problem appears to be that we're removing the selected item of the menulist
during its command event handler. This patch is just one possible workaround.
Attachment #135412 - Flags: review?
Attachment #135412 - Flags: review? → review?(mscott)
Attachment #135412 - Flags: review?(mscott) → review+
Attachment #135412 - Flags: superreview?(Henry.Jia)
Attachment #135412 - Flags: superreview?(Henry.Jia) → superreview?(bienvenu)
Attachment #135412 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 135412 [details] [diff] [review]
Ugly hack

This is just a low-risk hack to stop the problem manifesting, it doesn't
actually try to resolve the core issue.
Attachment #135412 - Flags: approval1.6?
Comment on attachment 135412 [details] [diff] [review]
Ugly hack

a=asa (on behalf of drivers) for checkin to Mozilla 1.6
Attachment #135412 - Flags: approval1.6? → approval1.6+
I checked the workaround in but I'm leaving the bug open in case someone comes
up with a proper fix.
This also happens on Thunderbird 0.4, when clicking Customize from the dropdown
box and then Ok without entering anything. It is fixed in Mozilla Thunderbird
0.5a (20040105), however.
So why did the changes in bug 209634 trigger this?
(In reply to comment #35)
>So why did the changes in bug 209634 trigger this?
During the command handler for a menulist menuitem the menulist still thinks
it's open, i.e. the "open" attribute's value is "true". Now it appears that
removing the menuitem confuses the menu frame into not completely closing the
menulist, so that the "open" attribute is not removed. When you subsequently
click on the menulist it tries to reopen by setting the "open" attribute to
"true", which subsequent to bug 209634 has no effect.
Don't ask me why the frame works by watching the "open" attribute, it all seems
backwards to me, especially as only the frame ever sets the attribute...
> Now it appears that removing the menuitem confuses the menu frame into not
> completely closing the menulist,

OK, so that's the bug, right?
I can't find the code that tries to take the menu down when an item is
selected... any idea where that is?
It's done by nsMenuFrame::Execute, I think...
OK, so what's happening is that at line 1655 that the menuitem checks to see
whether it still exists before closing its parent... obviously we need the
parent to exist otherwise calling its DismissChain will crash.
Yeah, it would be better to grab a pointer to the mMenuParent content before
line 1606 and check that _that_'s in the document....
Attached patch Best I could do — — Splinter Review 
I couldn't figure out a better way of ensuring that I still had a viable frame
to dismiss...
Assignee: sspitzer → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Product: MailNews → Core
comment 0 WFM Thunderbird version 2.0.0.0 (20070326).  didn't try trunk.
Assignee: neil → nobody
Status: ASSIGNED → NEW
QA Contact: laurel → filters
I shouldn't have reassigned. sorry
Assignee: nobody → neil
wfm with current Seamonkey trunk
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
With the popup rewrite the setTimeout hack is no longer necessary, right?
What is the bug? That the open attribute is set? After bug 279703, the open attribute will be cleared before the command event is sent.
(In reply to comment #47)
>What is the bug?
We're actually removing a menuitem during its command event.
(quoted from comment #27, where the patch was attached)
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: