Closed Bug 807629 Opened 13 years ago Closed 13 years ago

Appmenu stays open after menu item selection

Categories

(Thunderbird :: Toolbars and Tabs, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(thunderbird17+ fixed, thunderbird18+ fixed, thunderbird19 fixed)

RESOLVED FIXED
Thunderbird 19.0
Tracking Status
thunderbird17 + fixed
thunderbird18 + fixed
thunderbird19 --- fixed

People

(Reporter: sm.1975.smith, Assigned: Fallen)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; Zune 4.7) Steps to reproduce: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Thunderbird/19.0a1 (01 November 2012 build) When you open the appmenu, and then choose one of the menu items, the action is completed, and the menu stays open. Actual results: I selected the menu item Options... and the options dialog opened. When I closed the options dialog, the appmenu opened again. When I selected the New Message menu item, the compose window opened, but the appmenu remained open. Expected results: The appmenu should not reopen after dismissing the options dialog or after choosing any other menu item.
This might be by design?
Blocks: 785692
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
This also affected in 17beta and maybe affected 17esr. http://hg.mozilla.org/releases/mozilla-beta/rev/2584cac54ea7 http://hg.mozilla.org/releases/comm-beta/rev/f5fbdcff1f78 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 ID:20121030125442
Just reproduced this on Windows 7. On OSX and Ubuntu, I notice that after I click, the menu respawns before hiding - so I think it's a race. STR: 1) On a Windows machine, click on the AppMenu, and choose "Options" 2) When the Options dialog appears, click "Cancel" to close it. What happens? The AppMenu respawns. What's expected? The AppMenu should not respawn.
QA Contact: mconley
Hm - this seems to happen on each of our split menus - so I see it on Print, Message Filters, Find, and New Message.
I think I've traced this to our appmenu-vertical binding here: http://mxr.mozilla.org/comm-central/source/mail/base/content/mailWidgets.xml#2832 Since the menupopup exists *within* the button, I think the click handler is called both when we first open the menu, and (it seems) any time we click on a splitmenu immediately beneath the menupopup. Philipp - I do believe you introduced this binding. Any ideas what we can do about this?
Flags: needinfo?(philipp)
Attached patch Fix - v1Splinter Review
This should take care, tested on Mac.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #677822 - Flags: review?(mconley)
Flags: needinfo?(philipp)
Comment on attachment 677822 [details] [diff] [review] Fix - v1 Review of attachment 677822 [details] [diff] [review]: ----------------------------------------------------------------- Yep - looks great! Thanks Phillip!
Attachment #677822 - Flags: review?(mconley)
Attachment #677822 - Flags: review+
Attachment #677822 - Flags: approval-comm-beta?
Attachment #677822 - Flags: approval-comm-aurora?
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 19.0
Confirming as fixed for me. Thanks! Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Thunderbird/19.0a1 (03 November 2012 build)
Attachment #677822 - Flags: approval-comm-beta?
Attachment #677822 - Flags: approval-comm-beta+
Attachment #677822 - Flags: approval-comm-aurora?
Attachment #677822 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: