Closed
Bug 572823
Opened 15 years ago
Closed 15 years ago
Clear open state on parent menu when popup is destroyed
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: enndeakin, Assigned: enndeakin)
References
Details
Attachments
(1 file)
|
4.72 KB,
patch
|
neil
:
review+
|
Details | Diff | Splinter Review |
Otherwise, the open attribute can still be set even though the popup isn't there.
Attachment #452035 -
Flags: review?(neil)
|
||
Comment 1•15 years ago
|
||
Comment on attachment 452035 [details] [diff] [review]
implement this
Seems reasonable to me, although should it check that the attribute exists before adding a runnable?
Side note: what should happen if nsMenuFrame::PopupOpened finds that it's been destroyed?
Attachment #452035 -
Flags: review?(neil) → review+
|
Assignee | |
Comment 2•15 years ago
|
||
(In reply to comment #1)
> (From update of attachment 452035 [details] [diff] [review])
> Seems reasonable to me, although should it check that the attribute exists
> before adding a runnable?
I'll add this check.
> Side note: what should happen if nsMenuFrame::PopupOpened finds that it's been
> destroyed?
Which situation where you thinking of?
|
|
||
Comment 3•15 years ago
|
||
nsMenuFrame::PopupOpened sets the open attribute, but if it finds out that it's been destroyed then it simply returns; should it try to unset the attribute?
|
|
Assignee | |
Comment 4•15 years ago
|
||
Clearing the open attribute during nsMenuFrame::DestroyFrom would seem reasonable as well. Currently only menuactive is cleared.
|
|
Assignee | |
Comment 5•15 years ago
|
||
Actually, as this patch clears the open state when the panel is destroyed, the issue in comment 3 is already accounted for.
|
|
Assignee | |
Comment 6•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
|
||
Updated•6 years ago
|
Component: XP Toolkit/Widgets: Menus → XUL
You need to log in
before you can comment on or make changes to this bug.
Description
•