Closed Bug 412341 Opened 17 years ago Closed 17 years ago

clicking opened menuitem or combobox doesn't close menu

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9beta3

People

(Reporter: u294409, Assigned: kinetik)

References

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008011404 openSUSE/10.3 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008011404 openSUSE/10.3 Minefield/3.0b3pre

menu in firefox trunk doesn't behave like native gtk menu widget.

Reproducible: Always

Steps to Reproduce:
1. open menu
2. click opened menu's menubar item ("top menu item")
Actual Results:  
menu opens again, while it's opened

Expected Results:  
menu should close itself
I noticed it doesn't work well for comboboxes too
Summary: clicking opened menubar position doesn't close menu → clicking opened menuitem or combobox doesn't close menu
This is a regression.
Is this Linux only?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Appears to WFM on Win32.
2008011304 works, 2008011404 doesn't.
Don't ask me about Windows/etc, because I don't use this sh**, I mean I use only Linux.
Attached patch patchSplinter Review
We can't set gConsumeRollupEvent to PR_FALSE in the nsWindow::CaptureRollupEvents aDoCapture == PR_FALSE path  because if check_for_rollup causes an extant rollup to roll up, CaptureRollupEvents will be called with aDoCapture == PR_FALSE, causing us to set gConsumeRollupEvent to PR_FALSE.  This means that gConsumeRollupEvent ends up always being PR_FALSE when we care about the value (i.e. after a call to check_for_rollup).

Fix regression caused by the last minute addition of the gConsumeRollupEvent = PR_FALSE to my patch in bug 188126.  That little change was actually unnecessary and an attempt to be tidy, but turned out to be plain wrong.
Assignee: nobody → kinetik
Status: NEW → ASSIGNED
Attachment #297151 - Flags: superreview?(roc)
Attachment #297151 - Flags: review?(roc)
Same issue for favicon clicking and it's tooltip.
Attachment #297151 - Flags: superreview?(roc)
Attachment #297151 - Flags: superreview+
Attachment #297151 - Flags: review?(roc)
Attachment #297151 - Flags: review+
Attachment #297151 - Flags: approval1.9+
Keywords: checkin-needed
Version: unspecified → Trunk
Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.251; previous revision: 1.250
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
VERIFIED FIXED this and bug 412425 with
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008011604 Minefield/3.0b3pre
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008011804 Minefield/3.0b3pre
Status: RESOLVED → VERIFIED
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: