Status
()
People
(Reporter: enndeakin, Assigned: enndeakin)
Tracking
Firefox Tracking Flags
(Not tracked)
Details
Attachments
(1 attachment)
|
4.72 KB,
patch
|
neil
:
review+
|
Details | Diff | Splinter Review |
Created attachment 452035 [details] [diff] [review] implement this Otherwise, the open attribute can still be set even though the popup isn't there.
Attachment #452035 -
Flags: review?(neil)
|
||
Comment 1•9 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•9 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•9 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•9 years ago
|
||
Clearing the open attribute during nsMenuFrame::DestroyFrom would seem reasonable as well. Currently only menuactive is cleared.
|
|
(Assignee) | |
Comment 5•9 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•8 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/21585954d812
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•