Confirmed on Windows 10, but not on Mac. Not sure if this is forms or network yet, bisect would be helpful.

Tested this issue on Windows-10 using chrome latest beta M60-60.0.3112.72 and latest canary M62-62.0.3165.1 by following steps mentioned in the original comment.

After submitting the form, clicked on reload page and observed different behaviors on both the above versions. Tested the same on latest stable M59-59.0.3071.115 and observed similar behavior as M60-60.0.3112.72.

adrian@ Attaching screen cast for reference, could you please let us know which one is the actual and expected behavior of this issue?

Thanks!

The one where the 'form' dict is empty (and 'Content-Type' is missing) is the wrong one - in this case the Content-type header is missing, so web frameworks have no way of knowing what format the form data is in (which is why it remains in the raw, unparsed 'data' field in that case).

team, please re-triage.

Unable  to reproduce the issue on Windows 10 using chrome latest stable 60.0.3112.78 and canary 62.0.3172.2 with the below steps 

1. Navigated to the form from the given link.
2. Filled the form and clicked on Submit button
3. Reloaded the page twice and observed that data is present in the 'form' and 'content-type' fields.

Please find the attached screen cast and confirm if anything is missed here.
Request you please upgrade chrome to the latest version and update the thread if the issue still exists.

Thanks!

Deleted: Aug 2 2017 6-25 AM.webm 2.1 MB

	Aug 2 2017 6-25 AM.webm 2.1 MB View Download

FYI, this is still broken in "61.0.3163.31 (Official Build) beta (64-bit)" but works fine in the latest stable 60.x stable release.

On my machines:

60 stable, Windows: not repro
62 canary, Windows: repro
60 stable, macOS: not repro
62 canary, macOS: repro

I couldn't reproduce this with Chromium binaries fetched by //tools/bisect-builds.py.

Also, I found the request was sent as GET on reload.  Issue 429183?

After latest update 60.0.3112.101 Chrome start to lost all POST data on reload post page :)

 Issue 755483  has been merged into this issue.

FYI, in 61.0.3163.39 it's working fine again.

 Issue 755519  has been merged into this issue.

 Issue 755464  has been merged into this issue.

 Issue 755525  has been merged into this issue.

 Issue 755497  has been merged into this issue.

 Issue 755481  has been merged into this issue.

Bumping priority as per volume of bugs being reported.
This is reproducible on Mac and Windows (not linux) using 60.0.3112.101, see https://bugs.chromium.org/p/chromium/issues/detail?id=755497#c2 or  Issue 755481  for easy reproduction cases.

I can confirm on Windows 10 _this morning_, I did NOT observe this behavior(Missing content-type on reload of POST request) when I was using Version 60.0.3112.90.  But after checking the version, which caused an auto-update to Version 60.0.3112.101, I began to observe this behavior.  So, for me, the behavior change occurred updating from 60.0.3112.90 to 60.0.3112.101.

I guess this unpredictable behavior is due to PlzNavigate Finch.

I can confirm that the "Content-Type" header is lost on re-POST in Chrome 62 with chrome://flags/#browser-side-navigation ENABLED and the header is NOT lost when the PlzNavigate feature is DISABLED.

Similar to  Issue 755507 

Tagging as M60 Stable blocker based on comment #19.

Able to reproduce the issue with Chrome stable(60.0.3112.101) and Beta(61.0.3163.39) 

Please find the manual bisect(since narrow bisect always returned me a good build)

Last good build : 60.0.3111.0
First bad build : 60.0.3112.0

Change log : https://chromium.googlesource.com/chromium/src/+log/60.0.3111.0..60.0.3112.0?pretty=fuller&n=10000

Suspected CL : https://chromium.googlesource.com/chromium/src/+/42b72063edb66bfd015bd9dea116c3e3e937d3eb


Note : When I tried the same on latest Dev (62.0.3178.0)channel I was't able to reproduce 

Since PlzNavigate has been deactivated on M60, I'm bumping down the priority and assigning to ahemery@.

Reproduced on Linux as well using 62.0.3188.0 (Developer Build) (64-bit)

Not sure why but today it works as expected although my version number hasn't changed since yesterday ... - Version 60.0.3112.101 (Offizial Build) (64-Bit)

It works fine for me on the following page:

https://www.axess.de/lib/formtest.htm

It did not do so yesterday...

Problem still exists - tried example above and it failed

Re #32 and #33-- To clarify, Chrome uses experimental flags (downloaded frequently from our servers) to control new features without having to release new builds of Chrome. 

The feature that caused this regression is called PlzNavigate internally and it is controlled by such a flag and/or an override setting set by the user (available in Chrome 61 and later) at chrome://flags/#browser-side-navigation. 

If you are still seeing the misbehavior, it's possible that your browser hasn't yet refreshed the experimental flags from the server, or you have manually enabled the problematic feature. 

Using version: 60.0.3112.101 - is there a means whereby the browser can be "forced" to refresh the flags? 

You can check if the problematic feature is still enabled by going to chrome://version and looking at the variation fields. If you see
c68ab9a3-3f4a17df the feature is enabled. If you see c68ab9a3-f23d1dea or c68ab9a3-ca7d8d80 (or there is nothing beginning by c68ab9a3) the feature is disabled.

To force a refresh, a browser restart should be sufficient. Otherwise, you can run the browser with the following command line flag: --disable-features=browser-side-navigation.

Checked and all is now working as it used to. POST data being re-presented after F5 or CTRL+F5

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

commit 7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7
Author: John Abd-El-Malek <jam@chromium.org>
Date: Thu Aug 17 16:23:14 2017

Fix form resubmissions losing the Content-Type header with PlzNavigate.

A form resubmit gets the POST data from the serialized content::PageState that was sent by the renderer after the original post. There are two parts to this fix:
1) when the first form submit commits, the browser should send the renderer the Content-Type header. Since this is with PlzNavigate, the renderer doesn't actually use it. However, it will send it back along with the post body in  content::PageState.
2) when the (browser-initiated) form resubmit occurs, the browser needs to extract the Content-Type header from the serialized content::PageState and add it to the list of request headers.

BUG= 747812 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Idf1fcc6efe32b948c6fea7e7a5dc5ba06c2d9c26
Reviewed-on: https://chromium-review.googlesource.com/618298
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495188}
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/browser/browser_side_navigation_browsertest.cc
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/browser/frame_host/frame_navigation_entry.cc
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/browser/frame_host/frame_navigation_entry.h
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/browser/frame_host/render_frame_host_impl_browsertest.cc
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/common/frame_messages.h
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/common/navigation_params.h
[modify] https://crrev.com/7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7/content/renderer/render_frame_impl.cc

Tested the issue on Windows-7, Ubuntu 14.04 and Mac OS 10.12.6(Checked in unsigned build) using chrome latest Canary M62-62.0.3189.0 by following steps mentioned in the original comment. Observed that details are displaying as expected. Hence adding TE-Verified label.

Please find the screen cast for reference.

Thank you!

Deleted: 747812.ogv 2.7 MB

	747812.ogv 2.7 MB View Download

Merge approved for M61 branch 3163.

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

commit 95a3b75d7d4ed8286f377a67f63295f2a80b8559
Author: John Abd-El-Malek <jam@chromium.org>
Date: Fri Aug 18 23:45:16 2017

Fix form resubmissions losing the Content-Type header with PlzNavigate.

A form resubmit gets the POST data from the serialized content::PageState that was sent by the renderer after the original post. There are two parts to this fix:
1) when the first form submit commits, the browser should send the renderer the Content-Type header. Since this is with PlzNavigate, the renderer doesn't actually use it. However, it will send it back along with the post body in  content::PageState.
2) when the (browser-initiated) form resubmit occurs, the browser needs to extract the Content-Type header from the serialized content::PageState and add it to the list of request headers.

BUG= 747812 
TBR=jam@chromium.org

(cherry picked from commit 7dfbcccf5e6fe580bd9e12a5841ef28bcee36de7)

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Idf1fcc6efe32b948c6fea7e7a5dc5ba06c2d9c26
Reviewed-on: https://chromium-review.googlesource.com/618298
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#495188}
Reviewed-on: https://chromium-review.googlesource.com/621965
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#688}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/browser/browser_side_navigation_browsertest.cc
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/browser/frame_host/frame_navigation_entry.cc
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/browser/frame_host/frame_navigation_entry.h
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/browser/frame_host/render_frame_host_impl_browsertest.cc
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/common/frame_messages.h
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/common/navigation_params.h
[modify] https://crrev.com/95a3b75d7d4ed8286f377a67f63295f2a80b8559/content/renderer/render_frame_impl.cc

Thanks for all the hard work on this! I look forward to the fix landing in beta :D

Apologies, applied the wrong component in bulk.