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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: enndeakin, Assigned: enndeakin)

References

Details

Attachments

(1 file)

Attached patch implement thisSplinter Review
Otherwise, the open attribute can still be set even though the popup isn't there.
Attachment #452035 - Flags: review?(neil)
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+
(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?
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?
Clearing the open attribute during nsMenuFrame::DestroyFrom would seem reasonable as well. Currently only menuactive is cleared.
Actually, as this patch clears the open state when the panel is destroyed, the issue in comment 3 is already accounted for.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: