Hacker News Reader

Comment by anotheryou | Hacker News Reader

Right. The change in context is not clear enough for the average user (Text Field or History) and the consequences are really bad (loss of input text).

View on HN

Does Chrome not prompt you about losing un-submitted changes to a form when triggering a navigation event?

I've never seen a browser do this. It's not clear to me it's a good idea, considering how widely input fields are used behind the scenes. Websites can request that the browser ask before navigating away, but I don't think a browser could reasonably do this automatically without getting it wrong annoyingly often.

Safari does it, and I don't remember the last time I got a false positive.

Most times, but not always. But it's better now at remembering what you typed if you accidentally navigate back then hit forward. I imagine in some situations I could accidentally lose form or input focus, hit backspace, and then lose everything. This could be an app that manually captures key presses with JavaScript rather than a regular input.

Sounds like an app like that should implement some kind of 'are you sure' using onbeforeunload. There are plenty of ways to navigate away from the current page (or close the tab/window) besides hitting backspace.

It does not, but the page author can use javascript to generate a confirmation dialog when you're leaving the page: https://developer.mozilla.org/en-US/docs/Web/API/WindowEvent...

Have to admit using FF most of the time. I only know the sophisticated websites doing it themselves.

edit: chrome doesn't warn, but browsers can re-fill the input forms when you navigate forwards again. This doesn't help if the state of the website was more complex and fails to resume.

I don't think so - I have to build javascript onBeforeUnload checks into forms manually. So: you can protect against it (mostly), but only by annoying the other users who actually do want to navigate away. It's lose-lose.

AFAIK it's done by javascript by the page.

That kind of control is in the hands of the webapp.

For instance if I close this tab, where I'm typing the comment, there will be no prompt. Whereas facebook will prompt me if truly want to leave the page.

(1) No, it does not.

(2) The concept of a "form" is less and less clear in the realm of web apps.

Yes, it does.

In the context of html in a browser, a form isn't a concept to be debated, it's a well understood element defined in the html standard.

If an app chooses to not use html forms and instead uses something like contenteditable to create its own editing environment, then you likely have much bigger issues than the back button.

I can't see how I have issues because a webapp I use wasn't perfectly coded. Remember the majority of browser users are, for a lack of a better word, browsers, not site developers. We can't affect the technology choices of the sites much, as choosing a site by tech purity instead of usefullnes is a losing proposition.

If I have a partially filled-out form that is really the query box for a search backend, and I hit back, why at the browser level should my flow be interrupted? That content was ephemeral.

It's an application-level question, not a system question. Can only be answered with semantic knowledge of the importance of the user input.

Hence we have get vs post forms.

Reply on news.ycombinator.com