Additionally, I wanted to confirm that this is also impacting other colleagues in my office who are using Windows (not Mac).

I've created a simple proof of concept here:

https://piwik.hit-me.co.uk/poc.php.

If you click on the form button, you'll be navigated to a fresh page containing the contents of the posted data. If you then refresh this page you'll see that it loses the posted data.

I'm experiencing the same thing after an update to Version 60.0.3112.101 (Official Build) (64-bit)

Generically, it appears to be a change in the behavior of refreshing a POST request with some unknown particulars.  The post request is duplicated, and the form fields sent, but there appears to be something about the request that's preventing it from being recognized by our server (IIS 8.5, CF 11) as a POST request and parsing the form fields properly. 

This is a change in behavior from Version 60.0.3112.90 (Official Build) (64-bit) .  Expected behavior of this form: Caching enabled - resubmits form info, receive response.  Caching disabled - show "Confirm Form Resubmission" dialog, click continue and receive response.  In both cases now (with/without cache enabled) form data is lost.


Sanitized request/response:

Request URL:https://...
Request Method:POST
Status Code:200 OK
Remote Address:XX.XX.XX.XX:443
Referrer Policy:no-referrer-when-downgrade

Response Headers
Content-Encoding:gzip
Content-Length:7969
Content-Type:text/html;charset=UTF-8
Date:Tue, 15 Aug 2017 13:37:07 GMT
Server:Microsoft-IIS/8.5
Vary:Accept-Encoding
X-Frame-Options:SAMEORIGIN
X-Frame-Options:SAMEORIGIN
X-Powered-By:ASP.NET

Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:278
Cookie: ... CFID=XXXXXX; CFTOKEN=5856cf1de9c6c867%2DFD13031A%2DB966%2DC820%2DXXXXXXXXXXXXXXXX
Host:...
Origin:https://...
Referer:https://...
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Request Payload
WorkOrderID=&CSRFtoken=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 Issue 755519  has been merged into this issue.

 Issue 755525  has been merged into this issue.

Possibly related to  issue 747812  but that's specifically about Content-Type not being POSTed.

I'm unable to repro this personally on either 60.0.3112.90 or 62.0.3178.0 but I'm on Linux, all reports have been from Mac and Win.

Agree, I suspect missing Content-Type is causing the webserver to not recognize/parse the body of the request.  

I can confirm on Windows 10 that version 60.0.3112.90 was fine, but 60.0.3112.101 shows this behavior.

The 3178 build is not available to me, 3112.101 is showing as the latest update.

 Issue 755464  has been merged into this issue.

I am able to reproduce on Mac 60.0.3112.101

I notice in chrome://net-internals that the POST triggered by the refresh doesn't contain Content-Type (like  Issue 747812  notes), though the original POST does.

How do we get this prioritized and the OS changed to ALL (or Mac and Win, at least?) This bug will impact a large segment of Chrome users, and will adversely impact intranet applications that are normally navigation-tolerant.

Looks like the post data is actually sent but is ignored by server because Content-Type header is missing.

Also, not certain that the Components designation is representative of the breadth of the problem...?