Closed
Bug 392512
Opened 17 years ago
Closed 17 years ago
Opening a panel from within an oncommand handler of a menuitem fails
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: asaf, Assigned: enndeakin)
References
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
dbaron
:
approval1.9+
|
Details | Diff | Splinter Review |
Opening a panel from within an oncommand handler of a menuitem fails. It seems as the panel is auto-hidden when the menuitem's containing popup is closed.
Opening the panel asynchronously (i.e. setTimeout) works.
Flags: blocking1.9?
Assignee | ||
Comment 1•17 years ago
|
||
This is very easy fix. The call to Rollup in nsXULMenuCommandEvent::Run should call HidePopup with the menu to close instead so that any new popups that were opened aren't rolled up as well.
Mano, does this fix your case? If so, I'll create a test for this too.
Assignee: jag → enndeakin
Status: NEW → ASSIGNED
Reporter | ||
Comment 2•17 years ago
|
||
Yes, thanks Neil.
Reporter | ||
Comment 3•17 years ago
|
||
Assignee | ||
Comment 4•17 years ago
|
||
This changes it so that:
1. In HidePopup, don't close up children that aren't submenus.
2. In nsXULCommandEvent::Run, make sure to call HidePopup with the parent popup of the menuitem that was executed, rather than Rollup, as Rollup always closes the topmost popup, and in this case, a new panel was opened above it during the preceding command event.
Attachment #277043 -
Attachment is obsolete: true
Attachment #277392 -
Flags: superreview?(bzbarsky)
Attachment #277392 -
Flags: review?(bzbarsky)
Comment 5•17 years ago
|
||
So I'm not sure I follow... In HidePopup, we could have menus that are on top of us but are not submenus? And are we looking for the bottommost menu (as the comments say) or the topmost one (as the variable naming seems to indicate)?
How do |foundMenu| and |item| differ at that point in the code, if at all?
Assignee | ||
Comment 6•17 years ago
|
||
(In reply to comment #5)
> So I'm not sure I follow... In HidePopup, we could have menus that are on top
> of us but are not submenus?
There could be popups that aren't menus.
And are we looking for the bottommost menu (as the
> comments say) or the topmost one (as the variable naming seems to indicate)?
It should be topmost, I will fix the comment.
>
> How do |foundMenu| and |item| differ at that point in the code, if at all?
>
At the 'if (foundMenu)' line, foundMenu and item will be the same. I changed the code to use foundMenu consistently and just reuse 'item' as a temporary variable.
Comment 7•17 years ago
|
||
Comment on attachment 277392 [details] [diff] [review]
include test
>Index: layout/xul/base/src/nsXULPopupManager.cpp
>+ // find the bottomost menu and close that menu first. In synchronous mode,
"find the topmost menu with only menus between it and foundMenu and close ...".
>+ if (foundMenu->IsMenu()) {
Why this check? Document.
r+sr=bzbarsky wth that
Attachment #277392 -
Flags: superreview?(bzbarsky)
Attachment #277392 -
Flags: superreview+
Attachment #277392 -
Flags: review?(bzbarsky)
Attachment #277392 -
Flags: review+
Assignee | ||
Comment 8•17 years ago
|
||
Comment on attachment 277392 [details] [diff] [review]
include test
Will fix the comments.
Attachment #277392 -
Flags: approval1.9?
Comment 9•17 years ago
|
||
Comment on attachment 277392 [details] [diff] [review]
include test
a1.9=dbaron
Attachment #277392 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Updated•17 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: blocking1.9? → in-testsuite+
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•