4 ms·
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).
by anotheryou 10y ago
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).
- stephenr 10y agoDoes Chrome not prompt you about losing un-submitted changes to a form when triggering a navigation event?
- coldpie 10y agoI'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.
- stephenr 10y agoSafari does it, and I don't remember the last time I got a false positive.
- lstamour 10y agoMost 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.
- stephenr 10y agoSounds 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.
- anotheryou 10y agoHave 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.
- gruez 10y agoAFAIK it's done by javascript by the page.
- fixermark 10y ago(1) No, it does not. (2) The concept of a "form" is less and less clear in the realm of web apps.
- stephenr 10y agoYes, 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.
- nikanj 10y agoI 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.
- fixermark 10y agoIf 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.
- stephenr 10y agoHence we have get vs post forms.
- DCoder 10y agoIt 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/WindowEventHandlers/onbeforeunload https://developer.mozilla.org/en-US/docs/Web/API/WindowEvent...
- ruipgil 10y agoThat 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.
- pfooti 10y agoI 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.