The commit comment explains, "Entries that are added to the back/forward list without the user's intention are marked to be skipped on subsequent back button invocations."
The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page.
So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today.
But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.
A lot of seedier sites already abuse these mechanisms, by doing nasty things when you click to close a GDPR notification, focus a search box, or similar intention.
Browsers will probably never be clever enough to tell which clicks had "the right kind" of intention. The arms race continues!
If I understood you correctly, if someone wanted to highjack my back history they could still do it on a random click? Is it only preventing non user interactive changes to the history or did I understand you wrong?
The commit doesn't include a mechanism for marking the should_skip_on_back_forward_ui flag, but the normal way Chrome verifies "user's intention" is waiting for a gesture/click in the page.
So if you're doing front-end routing in response to a user clicking on a link or button in your UI, or swiping the page or what have you, that will allow you to pushState and then intercept the back button, as you can today.
But if you attempt to pushState on load, that's not enough to establish intention; the back button will then skip your pushed states and leave the page.