OS: Windows

Can you please help us with a sample code or jsfiddle example which executes this behavior. This will help us to triage the issue better.

Thanks.!

You are welcome. Run on local server, or disable web security in chrome. (I guess you know it :) )

Deleted: issue.zip 1.1 KB

issue.zip 1.1 KB Download

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on Win-10 and Ubuntu 14.04 using chrome reported version #61.0.3163.100 and latest canary #63.0.3239.6.
Issue is not seen in OS-Mac.
This is a non-regression issue as it is observed from M50 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

The blink bits seem to be functioning correctly. I am guessing that the issue is somewhere in the area where OS-specific windows are actually created. Avi, could you help triage?

As per everyone, this is not a Mac issue.

Investigating.

dglazkov: I thought this was WebViewClient::DidFocus() but it doesn't seem to be. Where does the callback out of Blink happen?

First, a note about why this works on the Mac. It does so by accident. On the Mac, all windows are owned by a top-level app. If the user closes the window that is the topmost, and they're using that app, the Mac OS will promote the next-down window to be top-most. That is a behavior of the Mac OS, and it happens to match the expectations of the user in this case.

As for all other platforms, this fails due to abuse checks.

If we look at DOMWindow::focus() we see the following code:

  bool allow_focus = incumbent_execution_context->IsWindowInteractionAllowed();
  if (allow_focus) {
    incumbent_execution_context->ConsumeWindowInteraction();
  } else {
    DCHECK(IsMainThread());
    allow_focus =
        opener() && (opener() != this) &&
        (ToDocument(incumbent_execution_context)->domWindow() == opener());
  }

  // If we're a top level window, bring the window to the front.
  if (GetFrame()->IsMainFrame() && allow_focus)
    page->GetChromeClient().Focus();

In this case, the ExecutionContext::IsWindowInteractionAllowed() call returns false; we don't have any window interaction tokens. There is then a second chance, if it's being focused by the window that opened it. In this case, that's backwards, and the window that *it* opened is trying to focus it. So it fails, and the ChromeClient::Focus() call isn't made.

However, even if it *were* made, that turns into a call to RenderViewImpl::DidFocus(), which has *yet another* check for abuse, which is making sure that a user gesture is being processed at the time. And no, the window being closed is not a user gesture.

This case hits just about every anti-abuse mechanism we have for window activation. And as plausible as this case might be that it's not abuse, it's not worth the effort to carve it out from the other cases.

My recommendation is to not use window.open(). Popups are a remnant of the early days of the web, before things like iframes were available. Immediately after popups were introduced, abuse of them became rampant, and it has continued to this day. There are better options available. Use them instead.