New issue
Advanced search Search tips

Issue 918268 link

Starred by 20 users

Issue metadata

Status: Fixed
Closed: Jan 11
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Pop-up blocker now blocks middle- and control-clicks from opening a new tab

Reported by, Dec 30

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
1. Find any page with a visible link
2. Control-click the link
3. Observe the 'pop-ups blocked' icon appear in the URL bar

What is the expected behavior?
Middle- and control-click would open the link in a new tab.

What went wrong?
These new tabs are apparently being treated as pop-ups from the site itself, and are being blocked from opening by the popup blocker.  I can allow pop-ups from the site to let the tabs be created, but then I have to enable popups for every site I want to open tabs from.  Also, I'd prefer to not give sites popup access!

Did this work before? Yes I updated recently, I don't know what version I was on before.

Chrome version: 71.0.3578.98  Channel: stable
OS Version: 10.0
Flash Version:
Nevermind, it might be Ghostery doing something weird!  I see the listed behavior when Ghostery is enabled, and not after I disable it.
Labels: Needs-Bisect Needs-Triage-M71
Components: -UI UI>Browser>PopupBlocker
Labels: Triaged-ET Needs-Feedback
Thanks for filing the issue!

Unable to reproduce the issue on reported chrome version 71.0.3578.98 using Windows 10 with the below mentioned steps.
1. Launched Chrome
2. Navigated to a webpage having link(s)
3. Ctrl+Click on link opened that particular link in a new tab.
In the process we didn't observe any 'pop-ups blocked' icon appearing in the URL bar.

@Reporter: As mentioned in C#1 that the issue is seen due to Ghostery, could you please check the same in a new profile without any apps & extensions and let us know if the issue still persists.
Thanks for looking over this report!  The issue can't be reproduced/goes away once I disable Ghostery.  I did see another Ghostery user report the same issue when they were on Chrome 71.*, but it went away once they updated Chrome to 72.*.  They're using the Chrome dev channel, so it seems the next version of Chrome should fix my issue when it is generally released.  It does seem that 71 has some negative interaction with Ghostery, though.
Project Member

Comment 5 by, Jan 1

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot
Labels: -Needs-Bisect
From comment#4, it is clear that this is being caused due to Ghostery and the issue seems to be gone once it's disabled. Hence removing Needs-Bisect label. Please feel free to add it back if required.

 Issue 920405  has been merged into this issue.
 Issue 920407  has been merged into this issue.
Just wanted to add that this issue did seem to appear only after I updated Chrome to 71.*, so it appears that it's a new interaction with whatever existing Ghostery behavior.  I imagine it's not Chrome's responsibility to fix extensions' behavior, but there seems to have been something in the most recent Chrome update that was a factor in this issue.

The general take on the Ghostery-side ticket ( ) seems to be 'wait for 72 at the end of the month', so I might update to the dev channel until then just to fix this issue locally.  Thanks for the responses in this ticket!
Labels: Hotlist-ConOps
Reports are showing up on reddit as well:

A specific callout is that pausing the Ghostery extension doesn't resolve it, but disabling the extension (via chrome://extensions) does.

It looks like a few bugs mentioning this behavior have been filed to the Ghostery bug tracker:

Another user reported that they're seeing similar behavior from the ImTranslator extension:
Quick update with more user feedback.

There's a semi-active forum thread here, and I've shared the answer as we know it to be:

The Listnr spike notification also came in this morning:

I'm not seeing any update notice on - we didn't push out an update, right?

If not, then this spike probably isn't related to any changes to Chrome. Could the extension have pushed out an update (do we have a way to check)?
Ghostery wasn't it for me, but I've identified the culprit in my case. Roboform Password Manager ( extension. Disabling it makes middle click work again.

 Issue 920677  has been merged into this issue.
 Issue 920646  has been merged into this issue.
Once I disabled Ghostery everything worked again. 

In the mean time I did discover another issue that was also fixed by turning Ghostery off. When I wanted to open a video on Youtube in full screen it didn't allow me to (Haven't tested it for other sites).
In Ghostery, we keep getting bug reports, but it looks like it is caused by sending messages from the content script to the background and back again, for instance:

// content-script
window.addEventListener('mousedown', () => {
  chrome.runtime.sendMessage({ action: 'test' }, reply => {
    console.log('got a reply');

// background
chrome.runtime.onMessage.addListener((message, sender, respond) => {
  console.log('got message', message);
  respond({ action: 'reply' });

Here is a minimal extension to demonstrate it:

If you can also reproduce, it looks like an issue in Chrome itself.
I'm experiencing the same issue. I assumed that middle mouse button wasn't working correctly until I noticed that the pop-up was automatically being blocked. Having read this thread, I can see that it may be related to Ghostery and not specifically Google Chrome. Further, as mentioned by another user, specifically in regards to not being able to "full screen", I am experiencing the same technical issue on Netflix whereby I am unable to make use of the "full screen" function. Is this also related to Ghostery or Chrome specifically? Seems have happened within the past 24 hours on my side. 
Here's the console error:

Uncaught (in promise) TypeError: fullscreen error
    at Object.<anonymous> (none:6)
    at Object.enterFullscreen (none:2)
    at Object.toggleFullscreen (none:6)
    at Object.toggleFullscreen (none:6)
    at i.toggleFullscreen (none:6)
    at Object.onFullScreenChange (none:6)
    at Object.handleClick (none:6)
    at Object.handleEvent (none:6)
I should also have mentioned the steps to reproduce the problem:

1) Go to
2) Click on "Browse"

It should open a dialog to upload a file. But on systems affected by the issue, it will not open.

The original bug report can be found in the Ghostery issue
philipp: Thanks for the minimal repro. Using that, I was able to bisect this down to:

Extensions Bindings] Add a fieldtrial testing config entry for native bindings

Devlin, can you take a look? It looks like this experiment just recently launched to stable.
Oops, actually adding devlin this time.
Can we confirm that adding --disable-features=NativeCrxBindings to the command line fixes it?
I can confirm that with "--disable-features=NativeCrxBindings", I am unable to reproduce the issue on latest Chrome stable 71.0.3578.98.

Thank you Charlie and  philipp.classen@ for steps.
Labels: RegressedIn-71 M-71 FoundIn-71
Status: Assigned (was: Unconfirmed)
Update : 

Issues isn't reproducible on Chrome Beta(72.0.3626.53), Dev(73.0.3664.3) and Canary(73.0.3667.0) channels.
If it's not reproducible, was there a fix rolled out to 72+?

If so, can the field trial be disabled remotely for everyone until after 72 is rolled out, or at least for 71 and below?
It looks like this is only an issue when:
a) native bindings are enabled
b) user activation v2 is not enabled

mustaq@, it looks like UAv2 is turned on by default beginning in M72.  Is that still on track?  If so, we can just restrict native bindings to only being on for M72+.  If there's a chance that UAv2 will *not* be shipped to 100% in M72, we should investigate this further and figure out why it fails.
UAv2 is doing good on M72 beta so far: saw a few bugs, none very bad.  However, beta samples can't possibly cover all corner cases, so we are on standby mode!

After a bit more investigation, this is definitely user-gesture related.  It looks like the user gesture is not being properly handled with UAv1 in these cases, and any method that requires user gesture will fail.  I'm going to see if I can bisect it down a bit more, but I think Mustaq is a better owner for this overall.

However, due to the impact, I'm going to roll back the native crx bindings experiment to M72 (where UAv2 is enabled).
Labels: Target-72 M-72
Adding M-72 labels for tracking.
The specific issue (though I don't know why) is this line here [1], which was added in [2].  Basically, we create a scoped user gesture from a token when delivering a response from a message that was initiated with a user gesture.  If we do that, then any call the web page makes that requires a user gesture will fail.  Mustaq, will the act of creating a WebScopedUserGesture from a token consume the gesture?  (If I comment out that line, everything works fine)

(Also note this has been disabled on 71, so clients should be fixed once they pick up the new variations)
Thank you rdevlin.cronin@ for disabling on M71.
Another side effect I just noticed is in a Disqus form (for example on the site above), if you click the upload image button, which should pop up a system file open dialog, it does not. No Chrome popup blocker notification shows up in this case, which made it even more confusing, and switching to the Chrome emulator in dev tools makes the file dialog work again.
#32 Is it possible to manually trigger the sync from the client that would disable this experiment again?
@35: Chrome should re-fetch experiments on startup, so restarting the browser will work.  However, updates from the server aren't available to all clients immediately or simultaneously, so it may be a few hours before they are available.
Ah, that explains why a restart didn't fix it. So it's a staged rollout essentially.
I've updated our forum messaging to confirm the source of the behavior, let folks know a fix is rolling out over the next few hours, and mentioning that a restart may be required.

The issue looks to be fixed for me after a restart, thanks!
 Issue 920757  has been merged into this issue.
I have the same problem the second day, how fixed this?
I recommend enabling chrome://flags/#user-activation-v2
As mentioned in comment #27 it will be enabled by default in the next major release anyway.
Components: Platform>Extensions>API
This bug is specific to extension's use of user activation v1.  Thanks rdevlin.cronin@ for the analysis above.

More precisely, the ScopedUserGestureToken mentioned in #c31 above was added back in early 2017 [1].  NativeCrxBinding exposes the bug, then UAv2 hides it (it's token-agnostic).

Back to rdevlin.cronin@ to decide: can close this bug now, and/or find an owner from the extensions team for the unlikely case we have to roll back UAv2.


rdevlin.cronin@: (in case this is still relevant) I missed this question, sorry:

> will the act of creating a WebScopedUserGesture from a token consume the gesture?
No it shouldn't.  Any chance the pass token is null, or has been consumed elsewhere?

Status: Fixed (was: Assigned)
I'm going to close this out, since the immediate issue was fixed.  I've filed 921141 to track the ongoing investigation into the underlying cause.
It was mentioned we (users) won't need to update chrome once the issue is fixed? Well it has asked me to update but not only that. Chrome is suddenly asking me for permission to access my storage space. In addition it's telling me I don't have enough space. This does  not make sense to me. Is this part of the issue  getting fixed? I'm concerned because of another personal matter that took place yesterday regarding PayPal and Gmail and fraud and Identity theft . Some is impersonating PayPal. Access your personal email. Sending cloned company documents. Once u open a link, u open a passage for anyone to enter. Could this be part of the glitches today?? 
@46 None of the changes related to this bug would have caused permission changes, or resulted in a Chrome binary change.

Sign in to add a comment