Able to repro this issue on Latest canary 25.0.1337.0,Beta 24.0.1312.25 on Win7,Mac 10.8.2 and Ubuntu 12.04

Here is the bisect info:

Good Build : 23.0.1264.0
Bad Build : 23.0.1265.0

You are probably looking for a change made after 156336 (known good), but no lat
er than 156357 (first known bad).
WEBKIT CHANGELOG URL:
  http://trac.webkit.org/log/trunk/?rev=128306&stop_rev=128269&verbose=on&limit=
10000
CHANGELOG URL:
  http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/tru
nk/src&range=156336%3A156357

I can confirm that the following browsers are affected:

* Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
* Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17

Can reproduce this using the JS on http://tab.bz/9m5hn (hit the blue button to trigger opening the links).

Chrome Version 24.0.1312.52

Issue not present in FF 18.0.2 or IE10

I've been having a look at this as my first bug (please be gentle!).

As far as I can tell the source of the bug is to do with whether the event is considered to be caused by a "user gesture".

In particular the following code in RenderViewImpl::show in content/renderer/render_view_impl.cc looks to be the cause of the issue

.......

  if (GetContentClient()->renderer()->AllowPopup())
    opened_by_user_gesture_ = true;

  // Force new windows to a popup if they were not opened with a user gesture.             
  if (!opened_by_user_gesture_) {
    // We exempt background tabs for compat with older versions of Chrome.                 
    // TODO(darin): This seems bogus.  These should have a user gesture, so                
    // we probably don't need this check.                                                  
    if (policy != WebKit::WebNavigationPolicyNewBackgroundTab)
          policy = WebKit::WebNavigationPolicyNewPopup;
  }

.......

This code seems wrong for a couple of reasons:
1) The call to AllowPopup will always return false as this is just a stub function in content/public/renderer/content_renderer_client.cc and popup blocking actually happens in chrome::AddWebContents in chrome/browser/ui/browser_tabstrip.cc .
2) It's unclear why we'd want to open new windows rather than new tabs in this case. If the user doesn't trust the site (i.e popups are blocked) then it won't matter either way. If the user does trust the site then why are we overriding the site in this specific case?

If it were my call then I think I'd just remove that entire chunk of code. That said I can see this isn't a clear cut technical issue so could someone from the Chromium team comment on the desired behaviour and then we can either remove the code or close the bug as invalid.

If the code is to be removed then I'd be happy to create a patch. I realise it's a trivial change but it'd be useful to learn the processes involved.

Just to expand on my second point as I realise it was a little unclear.

The logic that blocks popups is based on whether popups are allowed for the current page and whether the window was opened due to a user gesture (i.e it is not based on whether the page is opened with type NewPopup). So with the proposed code removal the second (and subsequent) new tab is still blocked until you explicitly allow popups for that domain or allow them globally. I've tested this locally.

Hope that is a bit clearer.

Would be great if you can provide a fix!  Looking forward to it.

Any update on this? It's the #1 reason why I don't use Chrome as my primary browser every day.

We think this is causing an issue for us where by we call window.open and want it to appear in a pop-up (not in a tab) and it is appearing in a tab. All other browsers open in a window.

Will this ever be fixed? Is there at least a work around for this? 

Thanks for looking in to this.

This bug forces me to use Firefox on a daily basis for reading most websites. Please fix??

Hi, have there been any update on this? 

Any update? 
window.open("http://google.com","_blank" always opens in a new tab for chrome 39.0.2171.65. All other browsers consistently open google in a new window.

The behavior has definitely changed since this bug was filed.  We appear now to consistently suppress opening more than one window unless enabled by popup blocker settings, and consistently open as a tab by default.  You can force a window to be opened as a popup by supplying a width and height value, eg.:
  window.open('http://www.google.com/', '_blank', 'height=200,width=200');

That said, I'm sure there's still some differences between browsers here (eg. see debate here: http://stackoverflow.com/questions/726761/javascript-open-in-a-new-window-not-tab).  The relevant specs appear to leave this up to the user agent:
 https://drafts.csswg.org/cssom-view/#the-features-argument-to-the-open()-method
 https://html.spec.whatwg.org/multipage/browsers.html#dom-open

I think the remaining differences are really a UI / user preference issue, not a platform/interop issue.  But interested parties could make an argument to the spec editors to have the behavior defined more precisely for more consistent behavior between browsers.