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

Status: RESOLVED WORKSFORME

(MailNews Core :: Filters, defect)

Description

[Matthias Versen [:Matti]]

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

Comment 1

[Karsten Düsterloh]

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.

Comment 2

[Malte Rücker (mbr)]

*** Bug 218272 has been marked as a duplicate of this bug. ***

Comment 3

[Malte Rücker (mbr)]

-> (hopefully) improving summary

This also occurs in "Tools / Search messages" dialog.

Comment 4

[Malte Rücker (mbr)]

*** Bug 218361 has been marked as a duplicate of this bug. ***

Comment 5

[Oleg Sidletskiy]

*** Bug 214852 has been marked as a duplicate of this bug. ***

Comment 6

[Oleg Sidletskiy]

according to a dupe...

Comment 7

[Malte Rücker (mbr)]

*** Bug 218814 has been marked as a duplicate of this bug. ***

Comment 8

[reb]

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.

Comment 9

[Jeff Van Boxtel]

I also get this bug on Win2k with build 0.3 RC2

Comment 10

[Malte Rücker (mbr)]

*** Bug 219361 has been marked as a duplicate of this bug. ***

Comment 11

[Ray Booysen]

The text boxes also refuse to work once this occurs.  Using 1.5RC2.

Comment 12

[Malte Rücker (mbr)]

*** Bug 217136 has been marked as a duplicate of this bug. ***

Comment 13

[Malte Rücker (mbr)]

*** Bug 221748 has been marked as a duplicate of this bug. ***

Comment 14

[Oleg Sidletskiy]

*** Bug 221786 has been marked as a duplicate of this bug. ***

Comment 15

[Malte Rücker (mbr)]

*** Bug 222120 has been marked as a duplicate of this bug. ***

Comment 16

[Malte Rücker (mbr)]

*** Bug 222418 has been marked as a duplicate of this bug. ***

Comment 17

[Malte Rücker (mbr)]

*** Bug 222385 has been marked as a duplicate of this bug. ***

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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...

Comment 20

[Mike Cowperthwaite]

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.

Comment 21

[Mike Cowperthwaite]

*** Bug 197177 has been marked as a duplicate of this bug. ***

Comment 22

[Stefan Borggraefe]

*** Bug 224435 has been marked as a duplicate of this bug. ***

Comment 23

[Stefan Borggraefe]

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.)

Comment 24

[Robert Mohr]

*** Bug 224742 has been marked as a duplicate of this bug. ***

Comment 25

[Stefan Borggraefe]

*** Bug 224975 has been marked as a duplicate of this bug. ***

Comment 26

[Stefan Borggraefe]

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.

Comment 27

[[e-mail]]

Attachment: Ugly hack

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.

Comment 28

[Mike Cowperthwaite]

*** Bug 225757 has been marked as a duplicate of this bug. ***

Comment 29

[Stefan Borggraefe]

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 30

[[e-mail]]

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.

Comment 31

[[e-mail]]

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.

Comment 32

[Asa Dotzler [:asa]]

Comment on attachment 135412 [details] [diff] [review]
Ugly hack

a=asa (on behalf of drivers) for checkin to Mozilla 1.6

Comment 33

[[e-mail]]

I checked the workaround in but I'm leaving the bug open in case someone comes
up with a proper fix.

Comment 34

[Markus Gaugusch]

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.

Comment 35

[Boris Zbarsky [:bzbarsky]]

So why did the changes in bug 209634 trigger this?

Comment 36

[[e-mail]]

(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...

Comment 37

[Boris Zbarsky [:bzbarsky]]

> Now it appears that removing the menuitem confuses the menu frame into not
> completely closing the menulist,

OK, so that's the bug, right?

Comment 38

[Boris Zbarsky [:bzbarsky]]

I can't find the code that tries to take the menu down when an item is
selected... any idea where that is?

Comment 39

[[e-mail]]

It's done by nsMenuFrame::Execute, I think...

Comment 40

[[e-mail]]

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.

Comment 41

[Boris Zbarsky [:bzbarsky]]

Yeah, it would be better to grab a pointer to the mMenuParent content before
line 1606 and check that _that_'s in the document....

Comment 42

[[e-mail]]

Attachment: Best I could do

I couldn't figure out a better way of ensuring that I still had a viable frame
to dismiss...

Comment 43

[Wayne Mery (:wsmwk)]

comment 0 WFM Thunderbird version 2.0.0.0 (20070326).  didn't try trunk.

Comment 44

[Wayne Mery (:wsmwk)]

I shouldn't have reassigned. sorry

Comment 45

[Matthias Versen [:Matti]]

wfm with current Seamonkey trunk

Comment 46

[[e-mail]]

With the popup rewrite the setTimeout hack is no longer necessary, right?

Comment 47

[Neil Deakin]

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.

Comment 48

[[e-mail]]

(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)