New issue
Advanced search Search tips

Issue 891108 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Oct 4
Cc:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Pop-up invoked directly from a user action blocked

Reported by develo...@loop11.com, Oct 2

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce the problem:
On our site (e.g. https://www.loop11.com/ui/?l11_uid=50571) we ask users to install our Chrome extension. In line with the recent changes that included removal of inline installation, we've updated our app to open the Chrome Web Store instead at https://chrome.google.com/webstore/detail/loop11-user-testing/bhopfldlicecjkdoidhjfkhbndcjfomf.

The code we've used to open this page is:
```
window.open(CHROME_EXT_STORE, "_blank");
```

This is invoked directly on user action - clicking on the 'Install' button, which according to your documentation shouldn't never get blocked. However, we are getting reports from our users that occasionally, the new tab does get blocked from opening.

What is the expected behavior?
Popup is not blocked, because it gets triggered directly from user click.

What went wrong?
Popup sometimes gets blocked, but we've been unable to reliably reproduce this.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.100  Channel: stable
OS Version: OS X 10.13.6
Flash Version:
 
Cc: csharrison@chromium.org
Owner: mlamouri@chromium.org
Status: Assigned (was: Unconfirmed)
Cc: mlamouri@chromium.org
Owner: mustaq@chromium.org
avi@, I'm not sure why you assigned this to me. Maybe that's related to user activation and you meant to assign to mustaq?
I tried to repro in 70.0.3538.35 with UAv2 enabled and disabled.  Couldn't repro!

developer@loop11.com: Please confirm if enabling UAv2 (chrome://flags/#user-activation-v2) changes the repro for you.

Labels: Needs-Feedback
I took a look at the site. It looks like you don't directly call window.open, it is called via a setTimeout(<callback>, 0) in onmouseup.

In the current code (as far as I know), this leaves you open to timing issues if it takes more than a second for <callback> to be run. Usually this won't happen, but maybe you have some users on extremely slow machines busy doing other work.

I would suggest moving the window.open invocation to be called directly in onmouseup.
Many thanks for checking! We replaced the button with onmouseup handler with a plain 'a href' to avoid this. Feel free to close the ticket.
Status: WontFix (was: Assigned)
Thanks for circling back, I'm happy to help. Please file another bug if you are still seeing the issue.

Sign in to add a comment