Clear open state on parent menu when popup is destroyed

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: enndeakin, Assigned: enndeakin)

Tracking

Trunk
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
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.