Defect - popup behavior is inconsistent

VERIFIED WORKSFORME

Status

P2
normal
VERIFIED WORKSFORME
6 years ago
4 years ago

People

(Reporter: jbecerra, Assigned: ally)

Tracking

Trunk
x86_64
Windows 8.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
Blocks: 831947

Updated

6 years ago
Blocks: 859003
Whiteboard: feature=defect c=Info_app_bar u=metro_firefox_user p=0

Updated

6 years ago
Component: General → Browser
OS: Windows 8 → Windows 8 Metro

Updated

5 years ago
Priority: -- → P2
(Assignee)

Updated

5 years ago
Assignee: nobody → ally
(Assignee)

Comment 1

5 years ago
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()[1] 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).

[1] dxr.mozilla.org/mozilla-central/widget/windows/winrt/MetroUtils.cpp#l237
Flags: needinfo?(netzen)
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.
Flags: needinfo?(netzen)
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.
(Assignee)

Comment 4

5 years ago
Brain fail! The last 3 comments are actually about bug 872163! >.<

Updated

5 years ago
Blocks: 875024
No longer blocks: 859003
QA Contact: jbecerra
Summary: defect - popup behavior is inconsistent → Defect - popup behavior is inconsistent
Whiteboard: feature=defect c=Info_app_bar u=metro_firefox_user p=0 → feature=defect c=Info_app_bar u=metro_firefox_user p=2

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 5

5 years ago
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
Last Resolved: 5 years ago
Flags: needinfo?(jbecerra)
Resolution: --- → WORKSFORME
(Assignee)

Updated

5 years ago
Flags: needinfo?(jbecerra)
(Assignee)

Comment 6

5 years ago
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.
Flags: needinfo?(jbecerra)
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
(Reporter)

Comment 9

5 years ago
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
Flags: needinfo?(jbecerra)

Updated

5 years ago
Blocks: 906772
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.
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.