UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Example URL:

Steps to reproduce the problem:
The easiest way to reproduce this (that I know of) is to use the admincp control panel of an vBulletin 3.7-based forum.
I have no time to build an example from scratch and I don't have one that is public accessible. I think the explanation is detailed enough, I know it is quite a lot of work to go and reproduce this but hey, it's your job after all.

1. Navigate to a webpage at https://somedomain.com/somepath that has a self-signed https certificate
2. Go to advanced -> proceed at your own risk
3. Click a link that loads some content from the SAME domain into a frame, for example there's a link to https://somedomain.com/otherpath that is lodaed into a frame within the URL at step 1 which is still visible in the address bar. This content contains a POST-method form (whose "action" is still under the same domain)
4. submit the form with some data. The response is shown as expected within the frame.
5. I don't remember if there's some javascript taking care of pushing the urls (loaded into the frame) into the history or if that comes out-of-the-box when you click a link whose target is a frame
6. Now hit the BACK button

What is the expected behavior?
Should behave EXACTLY THE SAME as if you do this with a domain that has a proper https certificate, or that works with plain HTTP.

That is, when you hit the back button you should get the warning 

"This webpage requires data that you entered earlier [...] You can send this data again, but [...]"

And now if you do right-click->"reload frame", then the POST request should be resent with the data and the response loaded into the frame. Also, if you don't reload and you hit the Back button again, you should be able to go back one step further in the history, and if this was a GET request, this should reload without any issue. All this within the frame (the url on the address bar always remains the same).

This IS the actual behavior when I do this on an identical site that has a proper https certificate or with plain http (these are test, development and live copies of the same site so they are identical except for the domain and the https certificates).

The fact that I am over https with a self signed certificate is completely irrelevant because I already accepted to go ahead, and the domain of the Even if there was an actual issue or an actual need to explicitly protect me from loading self-signed https within the frame as opposed to within the main document (which there isn't), then you should show me the "back to safety / go on at your own risk" warning in the frame from the beginning, not at some random time when I try to go back to a page that requires to resend a POST request.

What went wrong?
At step 6, a sad face appears in the frame, and if I move the mouse over it, I see this warning (which by the way should be visible from the beginning, not just when moving the mouse):
"This webpage requires data that you entered earlier in order to be properly displayed. You can send this data again, but by doing so you will repeat any action this page previously performed."

And so far this is expected.

But then, I right-click and choose "reload frame". At this time, instead of re-sending the POST request with the data and loading the response in the frame (as it DOES when on http or properly secured https), it shows this vague, nonsense and basically bullshit error message (again, intermittently depending on where I move the mouse, pathetic):

"The webpage at https://somedomain.com/otherpath might be temporarily down or it may have moved permanently to a new web address.

This keep showing up if I try to reload or go further back.

Additionally, if in the other frame I click any other link that has the affected frame as a target, which would usually load just fine (no reloading involved, no POST requests involved), I now systematically get the nonsense error.

And then, if I go to the omnibox and try to load the main initial url from step1 from scratch, I get the HTTPS warning again, which usually you shouldn't get once you have "proceeded at your own risk" once, until you close the browser. Then starting from that, all goes back to functioning normally, until I try to repeat steps 2-6, at which point I encounter the issue again.

Did this work before? Yes until very recently

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 
Flash Version: