I have the same problem with some clients, in new version with this same problem. Our strategy is the same, open window and post to him. The pop'up stay on loading.html too.

Another user has create a new issue with the same topic:
 Issue 755492 

I also have the same problem!

I also have the same problem!

I solved my problem setting blank in the first argument of open function.

window.open('','new_name', 'some_configuration');

Let the form url set.

Can't set other url, must be blank. For example, a loading page before loads the post content.

Can you provide a URL to try this on?
Can you collect a net-export log?
http://dev.chromium.org/for-testers/providing-network-details

Probably related to  issue 755497 

 Issue 755492  has been merged into this issue.

I also got this issues with Chrome version: 60.0.3112.101

Adding nasko@ and jam@ as this might be PlzNavigate-related.

I think this might be a PlzNavigate issue.  I've just reproed this on Linux ToT with:
1. Go to http://csreis.github.io/tests/form-post.html
2. In DevTools, execute this as one statement: window.open('http://csreis.github.io','foo'); document.forms[0].target = 'foo'; document.forms[0].submit();

With --enable-browser-side-navigation, the new tab consistently ends up at http://csreis.github.io

With PlzNavigate disabled, the new tab ends up at http://echo.colons.co/?q=%s and displays the submitted form data.

Note that originally I couldn't repro this because I typed in the statements in (2) one after another.  I.e., this likely has something to do with a form post to the new tab while the tab's initial navigation to the URL from window.open is still pending.

Can anyone confirm whether this problem goes away if you restart Chrome with --disable-features=browser-side-navigation?

In  Issue 747812  we see the Content-Type request header is dropped on Refresh when PlzNavigate is enabled. Possibly related?

Comment 11: At a high level, this sounds like an intentional behavior change in PlzNavigate where a non-user-initiated navigation (i.e., the form post) is no longer permitted to interrupt a user-initiated navigation (i.e., the window.open).  clamy@, is that correct?

If that's causing lots of compatibility problems on sites, we may need to revisit that decision (assuming my diagnosis is correct).  I'm not sure how much of the new code depends on the assumption that PlzNavigate has this new restriction, though.

In the meantime, one option is to turn down (or off) the PlzNavigate field trial until we resolve this.  For context, the trial also appears to cause  issue 755256  (for enterprise URL blocking).

May I know how to do PlzNavigate?

#15: PlzNavigate is currently turned on for 100% of M60 stable users, although that may change given these bugs.  You can force it to be off by running Chrome with the --disable-features=browser-side-navigation command-line flag.

For this known issues, may I know when will include in the release?

Any target date to complete this fix?

Comment 21: I think the field trial has already been disabled.  Restarting Chrome should likely be sufficient in most cases for the bug to go away.

"field trial has already been disabled", this is controlled by Chrome side? as I finds that it seems have no issues find?

Yes this is controlled from our side. Finch trial is a mechanism to roll out new features to users and quickly roll them back when we encounter issues such as this bug. Fixing the issue in that case just requires re-starting the browser, which resets the list of enabled features.

@creis: I've confirmed that this is due to non-user initiated navigations not interrupting user-initiated navigations.

Thinking about it, I think we can relax this a bit. I'm thinking of the following model:
- renderer-initiated navigations can interrupt each other, regardless of whether they were user-initiated or not. This means that the last navigation initiated by a document is the one that will be carried out which is what developers would expect.
- browser-initiated navigations can only be interrupted by user-initiated navigations. Developers should not make assumptions on navigations that are not initiated from their documents/documents in the same scripting context.

Switching to this model should fix this bug.

@clamy: Thanks!  That sounds like a good strategy to me.

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

commit 6cbfad5930cd6c7b762318f72572d2472252f395
Author: Nasko Oskov <nasko@chromium.org>
Date: Thu Aug 17 11:31:01 2017

PlzNavigate: non-user initiated navigations cancel renderer-initiated

This CL changes the navigation cancellation policy in PlzNavigate.
Following this CL, non-user initiated renderer-initiated navigations
will be able to cancel user-initiated renderer-initiated navigations.
They still won't be able to cancel browser-initiated navigations.

This fixes an issue where a window.Open followed by a submit form in the
same script does not result in the form being submitted.

BUG= 755507 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I854d4cc16a8627dccf8bacd1fc5327e451bc451e
Reviewed-on: https://chromium-review.googlesource.com/616642
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Camille Lamy <clamy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495139}
[modify] https://crrev.com/6cbfad5930cd6c7b762318f72572d2472252f395/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/6cbfad5930cd6c7b762318f72572d2472252f395/content/browser/frame_host/navigator_impl_unittest.cc

Rechecked this issue on Chrome version 62.0.3189.0 on Windows 10, MAC 101.2.6 (Using Un signed Build) and Ubuntu 14.04. Followed the below steps:

1) Installed chrome and enable the flag "--enable-browser-side-navigation"
2) Navigated to http://csreis.github.io/tests/form-post.html
3) From DevTools executed the following command "window.open('http://csreis.github.io','foo'); document.forms[0].target = 'foo'; document.forms[0].submit();

Observed that a new tab was opened up at http://echo.colons.co/?q=%s and displays the submitted form data. Screen shot attached.
 
@ Oskov: Request you to please check and confirm if this is intended.

Thanks.!

Deleted: Java script output.png 73.4 KB

	Java script output.png 73.4 KB View Download

Yes, the steps from comment #11 are the correct repro steps, so we can consider this fixed.

Also, the fix is actually incorrectly attributed :(. It was authored entirely by clamy@ and I just rebased it to see if we can get it committed earlier. It looks like PolyGerrit takes the Patch Set author instead of the CL author for the committer :(.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-61; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-61 label, otherwise remove Merge-TBD label. Thanks.

Merge approved for M61 branch 3163.

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

commit d4febabca90d58d3898f4932f374e13719c5440d
Author: John Abd-El-Malek <jam@chromium.org>
Date: Fri Aug 18 23:56:11 2017

PlzNavigate: non-user initiated navigations cancel renderer-initiated

This CL changes the navigation cancellation policy in PlzNavigate.
Following this CL, non-user initiated renderer-initiated navigations
will be able to cancel user-initiated renderer-initiated navigations.
They still won't be able to cancel browser-initiated navigations.

This fixes an issue where a window.Open followed by a submit form in the
same script does not result in the form being submitted.

BUG= 755507 

(cherry picked from commit 6cbfad5930cd6c7b762318f72572d2472252f395)

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Ifdc651a513438c6fa2dd5290dda2a5b53be3cd3f
Reviewed-on: https://chromium-review.googlesource.com/616642
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Camille Lamy <clamy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#495139}
Reviewed-on: https://chromium-review.googlesource.com/622257
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#689}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/d4febabca90d58d3898f4932f374e13719c5440d/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/d4febabca90d58d3898f4932f374e13719c5440d/content/browser/frame_host/navigator_impl_unittest.cc

Apologies, applied the wrong component in bulk.