Thanks for the report, CCing folks who know things about site isolation and form submission.

Is there an existing page we could poke at that's exhibiting the behavior?

Unfortunately the existing page is the payment form for Tarsnap (www.tarsnap.com -- an online backup service I run) so it's only accessible if you create an account there.  But in the morning (it's currently 2:49AM here) I can extract the bits into a publicly visible page.

This page should exhibit the problem for affected users:

http://www.daemonology.net/tmp/chrome.html

Thanks very much for the report!  I've just confirmed that this is a site isolation issue.  I can repro when running with --site-per-process on Mac canary 66.0.3332.0, Mac stable 64.0.3282.119, and Linux ToT.  Without --site-per-process, the bug doesn't occur.  For a repro, I just went to the URL in #3 and typed in "4242424242424242", "123", "1" and "21" into the form.  With --site-per-process, the page outputs "Received GET", without it I get "Received POST Form contents: stripe_token=...".

On my local Linux build, I actually hit this NOTREACHED() with --site-per-process after form post:

[147391:147391:0126/135307.225195:FATAL:navigation_params.cc(81)] Check failed: false. 
#0 0x7f7cb7bd83ec base::debug::StackTrace::StackTrace()
#1 0x7f7cb7c02dbc logging::LogMessage::~LogMessage()
#2 0x7f7cb4dc9d97 content::CommonNavigationParams::CommonNavigationParams()
#3 0x7f7cb5332a20 content::NavigationEntryImpl::ConstructCommonNavigationParams()
#4 0x7f7cb533c844 content::NavigationRequest::CreateBrowserInitiated()
#5 0x7f7cb53440b5 content::NavigatorImpl::RequestNavigation()
#6 0x7f7cb5343a75 content::NavigatorImpl::NavigateToEntry()
#7 0x7f7cb53458ca content::NavigatorImpl::RequestTransferURL()
#8 0x7f7cb5376984 content::RenderFrameProxyHost::OnOpenURL()
#9 0x7f7cb53765de _ZN3IPC8MessageTI25FrameHostMsg_OpenURL_MetaNSt3__15tupleIJ27FrameHostMsg_OpenURL_ParamsEEEvE8DispatchIN7content20RenderFrameProxyHostES9_vMS9_FvRKS4_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#10 0x7f7cb537624d content::RenderFrameProxyHost::OnMessageReceived()
#11 0x7f7cb5566c8d content::RenderProcessHostImpl::OnMessageReceived()
#12 0x7f7cb6d41331 IPC::ChannelProxy::Context::OnDispatchMessage()

This is here in CommonNavigationParams::CommonNavigationParams():

  // |method != "POST"| should imply absence of |post_data|.
  if (method != "POST" && post_data) {
    NOTREACHED();
    this->post_data = nullptr;
  }

So somewhere, when posting a form through a proxy, we've lost the method.  Looks like post_data is still intact up to this point, but we clear it above due to incorrect method.

Adding lukasza@, who I think worked on some form post plumbing for OOPIFs in the past.

cperciva@: can you please confirm if affected users might have enabled "strict site isolation" from chrome://flags?  And if so, does disabling that flag fix this?

Thanks for confirming that I wasn't going crazy!  The idea of POSTs turning into GETs seemed so weird that I started to doubt myself...

BTW it sounds like in addition to whatever bug is resulting in the method getting lost, after the NOTREACHED() in the code you quote there should also be something to clear the Content-Type -- unless you want to leave "Content-Type sent with no body" as a deliberate syndrome for recognizing if a bug like this resurfaces in the future.

alex: I'll send out a few emails.  Unfortunately the users in question are customers, not employees, so it may take a while to get responses.

A bit more details.   We're always pulling the method to use from FrameNavigationEntry in NavigationEntryImpl::ConstructCommonNavigationParams(), now that PlzNavigate has shipped:

  // TODO(clamy): Consult the FrameNavigationEntry in all modes that use
  // subframe navigation entries.
  if (IsBrowserSideNavigationEnabled())
    method = frame_entry.method();
  else
    method = (post_body.get() || GetHasPostData()) ? "POST" : "GET";

But we are not updating the FNE's method for main frames in RequestTransferURL() properly.  I've confirmed that the method passed into RequestTransferURL() is "POST", but frame_entry->method() just before calling NavigateToEntry() is "GET".

Two users have confirmed that they had strict site isolation enabled, and that the problem goes away when they turn that flag off.  Also, they only just turned that flag on recently -- so it may be in fact that this is an old bug which only surfaced recently due to people enabling that flag in response to Spectre/Meltdown.

FWIW, the bug seems fixed if I add     
  entry->root_node()->frame_entry->set_method(method);

to the "// Main frame case." in RequestTransferURL(), just below where |entry| is created.

I can take this on unless someone else wants to.  Fix seems pretty simple; I'll put together a quick test for it.

#9: Thanks for confirming.  Indeed, this is likely an old site isolation bug that only surfaced now, and probably not a regression.

Draft CL @ https://chromium-review.googlesource.com/#/c/chromium/src/+/889646.

Actually, looking back at #8, this is technically a regression since that if statement would've done the right thing without PlzNavigate, but likely stopped working with PlzNavigate (which shipped in M61).

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

commit 5bb1f944bf54f670c3e57c00239a6639766e11ce
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Sat Jan 27 07:41:32 2018

Fix POST method getting lost in form submissions from an OOPIF to its parent.

This CL fixes a problem in RequestTransferURL(), where in the case of
a form submission to the main frame, the FrameNavigationEntry's method
was never updated.

Bug:  806215 
Change-Id: I1614a0e51f91b0d3346ce633bf8f027cf3609f15
Reviewed-on: https://chromium-review.googlesource.com/889646
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532192}
[modify] https://crrev.com/5bb1f944bf54f670c3e57c00239a6639766e11ce/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/5bb1f944bf54f670c3e57c00239a6639766e11ce/content/browser/site_per_process_browsertest.cc

Looks fixed in today's Canary (66.0.3334.0), after r532192.  Thanks Alex!

#14: Thanks for verifying!  Requesting merge for M65.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Requesting merge for M64 as well.  The fix is just one line, well-understood/safe, verified in canary per #14, and would fix an important payments use case for site isolation users in M64.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

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

commit 5beb60a811e1bb7cac8c675a883e19de9ae774d2
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Tue Jan 30 19:01:03 2018

Fix POST method getting lost in form submissions from an OOPIF to its parent (Merge to M65)

This CL fixes a problem in RequestTransferURL(), where in the case of
a form submission to the main frame, the FrameNavigationEntry's method
was never updated.

TBR=alexmos@chromium.org

(cherry picked from commit 5bb1f944bf54f670c3e57c00239a6639766e11ce)

Bug:  806215 
Change-Id: I1614a0e51f91b0d3346ce633bf8f027cf3609f15
Reviewed-on: https://chromium-review.googlesource.com/889646
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532192}
Reviewed-on: https://chromium-review.googlesource.com/893945
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#179}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/5beb60a811e1bb7cac8c675a883e19de9ae774d2/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/5beb60a811e1bb7cac8c675a883e19de9ae774d2/content/browser/site_per_process_browsertest.cc

Can you please confirm this is tested in Canary? FYI last Canary went out on Saturday morning. So there is a chance this fix hasn't landed in Canary yet. Which makes me a bit uncertain to take it for M64 yet. 

Yes, the fix in r532192 went into 66.0.3334.0 Canary.  Charlie has verified it in that version in comment #14, and I've also just verified it myself just to be safe -- the site from comment #3 works fine now when running with --site-per-process.

Approving merge for M64. Branch:3282

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

commit 83841ad42d970b8b5a8fc1af0c545ea58c5c4261
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Tue Jan 30 22:02:46 2018

Fix POST method getting lost in form submissions from an OOPIF to its parent (Merge to M64)

This CL fixes a problem in RequestTransferURL(), where in the case of
a form submission to the main frame, the FrameNavigationEntry's method
was never updated.

TBR=alexmos@chromium.org

(cherry picked from commit 5bb1f944bf54f670c3e57c00239a6639766e11ce)

Bug:  806215 
Change-Id: I1614a0e51f91b0d3346ce633bf8f027cf3609f15
Reviewed-on: https://chromium-review.googlesource.com/889646
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532192}
Reviewed-on: https://chromium-review.googlesource.com/894484
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#623}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/83841ad42d970b8b5a8fc1af0c545ea58c5c4261/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/83841ad42d970b8b5a8fc1af0c545ea58c5c4261/content/browser/site_per_process_browsertest.cc

Verified the fix on Mac 10.12.6, Win-10 and Ubuntu 14.04 using Chrome version #64.0.3282.140 as per the comment #4.
Attaching screen cast for reference.
Observed that Chrome POSTs the form to the URL specified.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 806215.mp4 3.1 MB

	806215.mp4 3.1 MB View Download

Can I pull the reproducer down now, or will it still be needed?  I'm not familiar with Chrome's merging/testing procedures.

Could you attach a copy of the repro case?  It's good to have it to verify things in the future just in case.  Probably fine to take it down either way, though.  Thanks for your help in setting it up!

Verified the fix on Chrome64.0.3282.142/CrOS 10176.67.0 (Daisy), 65.0.3325.39/10323.12.0(Enguarde).  Used the comment #4 to verify.