Because I copy/pasted the version strings, I didn't realize until after I submitted this that win64 builds currently have the same version in the dev and canary channels.

FWIW, I can still reproduce this issue with the current Canary Mac build (51.0.2680.0).

Assigning to pbommana@ per offline chat.

This got regressed in M51 and below are the bisect result :

Last Good build : 51.0.2664.0
First Bad build : 51.0.2665.0

Bisect result range :
You are probably looking for a change made after 378395 (known good), but no lat
er than 378533 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5d6a2e1871be2f4f8cc4eacb366a5abf8766fbfc..e5db881b268bc26ae3989a9f6f6a3325d7323baf



Note : I am still checking for the culprit CL.

suspecting CL : https://chromium.googlesource.com/chromium/src/+/42e463ac3a6f667821a8bed78ba0eafde79a7bfc

It's not that. I locally reverted all the CLs from bug 583347 (of which that change was the first) and I can still repro it.

I bisected again on the Chromium builds and got:

You are probably looking for a change made after 378507 (known good), but no later than 378529 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/372f7658f370076484322aed8e15756cea64ee53..8f6a88c155f34940a3e1cf9988aed089d37d96a1

While bisecting I found an interesting symptom. Usually when you close a parent gmail window, you get an onbeforeunload dialog warning you of the children windows that will also close. That dialog doesn't show up any more with the bad versions of Chromium.

I went through the list implicated, and after removing all the rebaselines and all the Android changes, the only one left that stood out was Daniel's ownership patch, https://chromium.googlesource.com/chromium/src/+/9e24bd35f58fff1562b0784be8ab2e612ece6408 .

Tossing to Daniel for further investigation.

I don't know exactly what's going on, but it's certainly plausible for it to be related to the opener plumbing. I'm OOO on Friday but I'll try to take a look in the evening and figure out a patch.

Removing bisect label, as bisect is already provided.

I see in the logs:

[20910:1295:0317/162703:INFO:CONSOLE(156)] "Uncaught CustomError: Error in protected function: Cannot read property 'ih' of undefined", source: https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.en.a8PmMLGCmsY.O/m=m_i,t/am=PiN-ZWD_7_3BuMYwQLv01brz3n--X1J2-9zj_5MmgEh9FcB_s_8H8H8gF2-j/rt=h/d=1/rs=AHGWq9CHtQw-PZj1l5sLaOYzSAXMENrygQ (156)

That might be related, if it helps.

dcheng@, have you had a chance to look into this? This bug is still present in today's canary (51.0.2689.0).

Just to update, This issue is still able to repro on Windows 7 using chrome latest canary M51-51.0.2692.0 .

 Issue 598350  has been merged into this issue.

OK, I still haven't figured out why, but the opener is now different in the Ctrl+Click case.

Originally, window.opener == top-level window in the opening Gmail window. The popped out compose window has a code snippet like this:

function onLoad(){
  var jsFrame = window.opener.js;
  if(jsFrame && jsFrame._GM_ftcb {
    jsFrame._GM_ftcb(window);
    return;
  }
  window.setTimeout(onLoad,200);
}

But now, window.opener == jsFrame, so the window.opener.js lookup fails and the compose window never loads. I'm trying to reduce this and figure out exactly why the behavior changed.

OK figured it out!

Original code worked something like this:
1. We pass *activeFrame as createWindow()'s openerWindow argument [1].
2. When creating a new window, this flows from ChromeClientImpl to WebViewClient to RenderViewImpl::createView().
3. The activeFrame's routing ID gets sent through an IPC [2]. At this point, the browser process thinks the opener is *activeFrame. So far, this is completely wrong. But it doesn't matter because...
4. Later on, RenderViewImpl declines to set the opener since the view creation originated from a renderer [3].
5. The stack unwinds back into Blink's createWindow(), which then calls FrameClient::setOpener() with openerFrame [4].
6. This ends up triggering an IPC to the browser process, fixing the opener relationship [5]. This fixes up the mistake from earlier, and everything works.

However, with the plumbing change, the code that calls setOpener() in Blink's createWindow() is no longer necessary. Unfortunately, this is what was previously fixing up the incorrectly plumbed opener frame, and thus, Gmail breaks. Doh!

[1] https://chromium.googlesource.com/chromium/src/+/372f7658f370076484322aed8e15756cea64ee53/third_party/WebKit/Source/core/page/CreateWindow.cpp#159
[2] https://chromium.googlesource.com/chromium/src/+/372f7658f370076484322aed8e15756cea64ee53/content/renderer/render_view_impl.cc#1655
[3] https://chromium.googlesource.com/chromium/src/+/372f7658f370076484322aed8e15756cea64ee53/content/renderer/render_view_impl.cc#811
[4] https://chromium.googlesource.com/chromium/src/+/372f7658f370076484322aed8e15756cea64ee53/third_party/WebKit/Source/core/page/CreateWindow.cpp#164
[5] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/web/FrameLoaderClientImpl.cpp&rcl=1459367167&l=342

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2fc83084f01d0cb24de7352ca38dbeab2ca6060

commit d2fc83084f01d0cb24de7352ca38dbeab2ca6060
Author: dcheng <dcheng@chromium.org>
Date: Thu Mar 31 16:13:43 2016

Set the correct opener for window.open when calling window != window.

This plumbing has been incorrect for a long time, but the problem was
masked by code made redundant in r378508. Prior to that, the embedder
would incorrectly set the calling window as the opener, but Blink would
later overwrite it with the correct opener.

BUG= 595344 
R=japhet@chromium.org, jochen@chromium.org

Review URL: https://codereview.chromium.org/1849703002

Cr-Commit-Position: refs/heads/master@{#384298}

[add] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/LayoutTests/fast/dom/Window/resources/window-open-with-different-active-and-opener-windows-popup.html
[add] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/LayoutTests/fast/dom/Window/resources/window-open-with-different-active-and-opener-windows-subframe.html
[add] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/LayoutTests/fast/dom/Window/window-open-with-different-active-and-opener-windows-expected.txt
[add] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/LayoutTests/fast/dom/Window/window-open-with-different-active-and-opener-windows.html
[modify] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/LayoutTests/http/tests/security/synchronous-frame-load-in-javascript-url-inherits-correct-origin-expected.txt
[modify] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/LayoutTests/http/tests/security/synchronous-frame-load-in-javascript-url-inherits-correct-origin.html
[modify] https://crrev.com/d2fc83084f01d0cb24de7352ca38dbeab2ca6060/third_party/WebKit/Source/core/page/CreateWindow.cpp

lgtm in 51.0.2696.0 on Win7! Thank you, dcheng@!

Can someone else on the Chrome testing side verify that this is fixed on other platforms?

Hi everyone,
Gmail QA tried this and they can still repro it on 51.0.2694.1 dev (64 bit). Please see b/27775965.
Thanks!

sgudelj:

Correct. This is fixed in 51.0.2696.0. Anything older than 2696 will not have the fix.