There are tons of good reasons to prefer this behavior, aside from just avoiding duplicates. Think of login forms.
In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.
https://www.theserverside.com/news/1365146/Redirect-After-Po...
It sounds like this warn-on-double-submit behavior is convention and not required, so maybe it has become more common for browsers to stop doing it.
> Why not try it, right here, on Hacker News.
OK, I did. HN does a 302 redirect on comment POST to the comment GET. When you back nav, you are seeing the response to a GET request to /reply?id=X
(In other words, the form is re-rendered.)
Edit: oddly, however, submitting on form rendered by GET /reply?id=X ends up creating a new comment, so that's just weird server logic. It might explain why you occasionally see duplicate comments on HN.
Edit 2: on backnav to a comment edit, the redirect is to GET /edit?id=X, which is a re-render of the edit form, the process I described in my OP. Not sure what's going on with the back-after-post...maybe a bug?
With the text you previously entered, which the browser restored. If it did not for you, you have non-standard settings like disabled caching. I can assure you that it behaves the same on Firefox for Linux, Windows, macOS and Safari on iOS: go back, form content is restored.
In fact, the entire internet is full of people trying to get rid of this behavior.
I'm not sure I understand. The "conventional" solution to this is not to do it -- the reason browsers don't re-fill submitted forms is to prevent duplication. Give users the ability to post-backclick-repost and your DB will rapidly fill up with duplicate rows.
If you do need to back-navigate to a page that has been submitted (say, to edit the submission w/o requiring an edit-specific URL), you have the server re-render the form with the filled values.
If that isn't sufficient, you can always push your form state on the history stack using the history API, so even though this is a bad idea (IMO), you can still do it pretty easily without needing to resort to re-writing nav.
I hate to say it, but I feel like a lot of this stuff had server-side solutions that worked fine circa 2010, but have been almost completely forgotten.