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)
Tracking
()
VERIFIED
FIXED
mozilla1.9beta3
People
(Reporter: u294409, Assigned: kinetik)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
roc
:
review+
roc
:
superreview+
roc
:
approval1.9+
|
Details | Diff | Splinter Review |
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
Comment 2•17 years ago
|
||
This is a regression.
Is this Linux only?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Updated•17 years ago
|
Keywords: regression
Comment 3•17 years ago
|
||
Appears to WFM on Win32.
Comment 4•17 years ago
|
||
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.
Assignee | ||
Comment 8•17 years ago
|
||
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)
Attachment #297151 -
Flags: superreview?(roc)
Attachment #297151 -
Flags: superreview+
Attachment #297151 -
Flags: review?(roc)
Attachment #297151 -
Flags: review+
Attachment #297151 -
Flags: approval1.9+
Updated•17 years ago
|
Keywords: checkin-needed
Version: unspecified → Trunk
Comment 10•17 years ago
|
||
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
Comment 11•17 years ago
|
||
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
Updated•16 years ago
|
Flags: blocking1.9?
You need to log in
before you can comment on or make changes to this bug.
Description
•