Closed Bug 867495 Opened 7 years ago Closed 7 years ago
Defect - popup behavior is inconsistent
Tested on 2013-04-30 using latest nightly built from http://hg.mozilla.org/mozilla-central/rev/dd0c611a0a27 While testing bug 831947 I noticed that the pop-up blocker info app bar didn't show, and if I opted to allow pop-ups, it would not show them even after reloading. I had to try other examples in the site before the pop-ups showed. This might be minor but there could be legitimate pop-ups that won't show because of this. Steps: 1. Go to http://www.popuptest.com/popuptest1.html Expected: A pop-up blocker info app bar Actual: Nothing happens. It just loads a page. If you go to http://www.popuptest.com/ and try one of the examples there, then it shows the pop-up blocker info app bar, and then if you go to the example in step 1 you will see the app bar.
Whiteboard: feature=defect c=Info_app_bar u=metro_firefox_user p=0
Component: General → Browser
OS: Windows 8 → Windows 8 Metro
I think this should be the following: when win8 shows the settings charm flyout, we notify FlyoutPanelsUI to hide any visible flyouts. Currently the js frontend has no way to know this, however the backend does. I think we should do this by having the MetroUtils::ShowSettingsFlyout() function send an event and have the FlyoutPanelsUI register an observer and hide the flyouts. :bbondy, :jimm is this the best way to get a message from cppland to js land, and how should I go about writing this? (jimm wrote the cpp part of the os snapped messaging when we hooked up the os windowstate message).  dxr.mozilla.org/mozilla-central/widget/windows/winrt/MetroUtils.cpp#l237
I think a partial fix may be enough here. I think the Show method you mentioned is only used when we manually call into it to invoke the settings panel. Like when we press the back button from flyouts. So I don't think that is a good place for the notification. You can check the header files here: C:\Program Files (x86)\Windows Kits\8.0\Include\WinRT\ for a notification about it coming up and add handling for it, but I'm not sure if one exists.
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. http://dxr.mozilla.org/mozilla-central/widget/windows/winrt/FrameworkView.cpp#l444 I think there's already an event sent there. This will also fix another bug of when you switch away from Metro the permissions flyout dismisses but our flyouts don't.
Brain fail! The last 3 comments are actually about bug 872163! >.<
TimA does not reproduce this with a clean profile. I do not reproduce this with my dirty profile or with a new one. :juanb, please re-open if this reproduces on current nightlies with new profiles, otherwise I think this is a WFM.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
actually, this sounds like two issues. The one in the STR and the on in paragraph above it. The one in the str is not reproducing for me. :juanb, if the first one is still producing, could we file a new bug on that?
For testing and verification.
I went to this page with a clean profile: http://www.popuptest.com/popuptest1.html The pop-up blocking bar appeared, as expected. When I click "Allow once," everything seems to work properly. When I click "Never allow," everything seems to work properly. When I click "Always allow," the following happened: No popups appeared <-- all 6 popups should have appeared After navigating away from the page, 2 popups appeared <-- navigating should not cause popups to appear
Tested on 20113-07-11 using the latest nightly. I've been testing this today, and I haven't been able to reproduce the last problem in comment #8. This now seems to be working with all four scenarios, allow once, never allow, always allow, and X.
Status: RESOLVED → VERIFIED
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 Build ID: 20130819030205 Built from http://hg.mozilla.org/mozilla-central/rev/c8c9bd74cc40 Didn't WFM Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment0 and didn't get expected result.
You need to log in before you can comment on or make changes to this bug.