UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3564.0 Safari/537.36

Steps to reproduce the problem:
Not clear yet. In our web application, consisting of a shell page with the actual application running in an iframe, the following sequence reproduces the problem:
1. Open the application. window.history.state is null.
2. Click a navigation button. A custom state is pushed as reflected by window.history.state.
3. Using the browser navigation, go back, forward, back.

All history API usage happens on the shell page - none from within the iframe.

What is the expected behavior?
The popstate event is fired with the "state" property set to null. window.history.state is also set to null again.

What went wrong?
window.history.state is not set to null again but retains its previous value.

Did this work before? No 

Chrome version: 71.0.3564.0  Channel: canary
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

So far, I have not been able to reproduce this in an artificial reproduction scenario. You would think this is a web application bug and I would tend to agree. However:
- the problem does not occur in Firefox, Safari on iOS or Chrome on iOS.
- any evaluation of window.history.state in any "popstate" event handler makes the problem disappear. Merely doing this in the console after the application has loaded "fixes" it:
  window.top.addEventListener("popstate", () => window.history.state);
- any evaluation in the console of window.top.history.state after pushing the custom state (either after navigation or the browser forward) makes the problem disappear.
- avoiding the "null" state by using replaceState after the shell page load makes the problem disappear.

We've had this problem in Chrome on Windows for a few months now at least.