Closed Bug 872163 Opened 11 years ago Closed 11 years ago

Defect - Metro Firefox Settings, About, and Sync flyouts should close when Win8 Settings panel opens


(Firefox for Metro Graveyard :: Shell, defect, P3)

Windows 8.1


(Not tracked)

Firefox 24


(Reporter: bbondy, Assigned: ally)



(Whiteboard: feature=defect c=Settings_pane_options_and_about u=metro_firefox_user p=2)


(1 file, 1 obsolete file)

1. Go to the settings charm, open the options panel (or about, or sync).
2. Go to the settings charm, open the permissions flyout

You'll see 2 flyouts shown but only one should be shown.
I notice permissions hides itself as soon as the settings charm is expanded, we should do this for the other flyouts too.

Summary: Metro Firefox Settings, About, and Sync flyouts should close when Win8 Settings panel opens → Defect - Metro Firefox Settings, About, and Sync flyouts should close when Win8 Settings panel opens
Whiteboard: feature=defect c=tbd u=tbd p=0
Priority: -- → P3
:bbondy, is there anything this bug needs before it is [shovel-ready] ?
should be ready to go
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=0 [shovel-ready]
Assignee: nobody → ally
Whiteboard: feature=defect c=tbd u=tbd p=0 [shovel-ready] → feature=defect c=tbd u=tbd p=2
Hi Ally, if you'll be taking this in Iteration #8 please add the Bug ID of the stories the defect relates to as a block.
Flags: needinfo?(ally)
There is really a good one, so let's do the sync flyout & the about flyout since those appear to be the defective cases
Blocks: 831958, 831955
Flags: needinfo?(ally)
Blocks: metrov1it8
No longer blocks: metrov1defect&change
QA Contact: jbecerra
Whiteboard: feature=defect c=tbd u=tbd p=2 → feature=defect c=Settings_pane_options_and_about u=metro_firefox_user p=2
Attached patch half fix at best (obsolete) — Splinter Review
Hides all xul flyouts if a xul flyout is selected. This means the windows 8 settings flyout still sits over the old one until another fly out is selected. This is a half fix best (you still see the overlay of hte setting panel but not hte 2 flyouts over each other) and at worst no better (there's still two things causing visual clutter).

I think the answer lies elsewhere.
(In reply to Brian R. Bondy [:bbondy] from comment #3)
> Actually I think a good place might be when the window is deactivated.  If I
> recall correctly, anytime a metro flyout is displayed our window will be
> deactivated.
> cpp#l444
> I think there's already an event sent there.
There is an event, but I noticed halfway through today that "Content:Deactivate" doesn't fire when flyouts happen. Which is to say if that were true, than I expect to see fire, and I do not. This is the event I would expect the Cpp to be sending as the function is called "SendActivationEvent()"

Maybe it's actually sending a different message. Let's find out.
> This will also fix another bug of when you switch away from Metro the
> permissions flyout dismisses but our flyouts don't.
I did some digging starting from SendActivationEvent(), called in FrameworkView::OnWindowActivated().

of which the most relevant line is probably the call to
which tosses over to (a file that dxr could not find, but mxr can?)
whose key line I think is
which I think leads to this ball of wax
which to the best of my (very rusty) c++ does not raise any message, event, or observer notification. I think there is currently no way for the JS to be aware of this event, and that's the missing link.

(pretty please bbondy, someone, tell me I'm wrong! :( )

I think starting at OnWindowActivated() might be the right path. So, I think this bug is going to need two parts: A)backend, cpp to message B) frontend, js to actually control our flyouts.
Flags: needinfo?(netzen)
TimA suggests that might actually be the answer.
looks like tim's suggestion is spot on. let's go with that
Flags: needinfo?(netzen)
Attachment #753528 - Attachment is obsolete: true
Attachment #755118 - Flags: review?(netzen)
Comment on attachment 755118 [details] [diff] [review]
FlyoutPanelsUI listening for "deactivate" event

Review of attachment 755118 [details] [diff] [review]:

Yup seems like widget activated/deactivated leads to are activate/deactivate.
There's a non exhaustive list of events here:

Looks good and this fixes a bunch of issues with the flyout being inconsistent with the permissions flyout.
Attachment #755118 - Flags: review?(netzen) → review+
I'm all for killing multiple bugs with one stone.
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
For testing and verification.
Flags: needinfo?(virgil.dicu)
verified for it8 - re-opening the setting charms menu using a side swipe while our flyout is visible closes our flyout.
Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20130612 Firefox/24.0

Verified that all flyouts (Options, Sync, About, Permissions) are closed when Setting are open.
Flags: needinfo?(virgil.dicu)
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130816030205
Built from

Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment0 and got expected result.
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.