There is an inconsistent behavior around popup creation behavior from unload handlers, that arises now that  bug 627852  is fixed.

1) In new tab (let it be tab1) load http://popuptest.com/popuptest2.html
2) Allow the browser to show multiple popups for this page (by interacting with the popup icon on the right hand side of the omnibox)
3) Re-load the page. You should see one popup appear.
4) Note that this page's unload handler will try to open a second popup window.

Now unload the document via one of the following methods:
5a) close the tab
5b) do a same-site navigation (by click the 'Reload' button)
5c) do a cross-site navigation (type 'www.google.com' into the omnibox).

Expected behavior: 5a, 5b and 5c to all consistently show or suppress the popup in this case.

Actual behavior: the popup is allowed in case 5a and 5b, but suppressed in case 5c.

The suppression in 5c happens because of a "(frame_tree_node_->current_frame_host() == this)" check in RenderFrameHostImpl::OnCreateNewWindow. Prior to r441781, we would actually kill the process in this case -- that was  bug 627852 .

The process kill was added as part of a fix for a security bug: https://codereview.chromium.org/92873004/diff/200001/content/browser/web_contents/web_contents_impl.cc#newcode1280. That intervention was something of a blunt hammer, since at the time rph_id wasn't properly plumbed into the window creation calls. 

So, it might be possible to securely allow popup creation in case 5c today, though suppressing popups in cases 5b (and especially 5a) should be explored too, since popups are pretty user hostile.