14 ms·

But there are better solutions. Comment #35 in that thread actually provides one: > The problem: Moving away from a form can result in data loss. > Your solut

• animeweedlord 10y ago
  I think Chrome does this as well. The real problem is that it doesn't seem to work with dynamically created forms, and web devs ruined everything with client-side templating. But along the same lines, I would like it if browsers waited 5 seconds before actually killing a tab that you closed. That would not only fix your problem (if you applied it to page history changes as well), but solve most accidental data loss problems, and most importantly for me, be the end to having to reload entire pages just because I held down Ctrl-W for too long.
  • nitrogen 10y ago
    Try Ctrl-Shift-T
    • animeweedlord 10y ago
      I'm well aware. I'm saying that the tab should appear to close but persist in the background for a short period of time so that I can Ctrl-Shift-T and get my untouched context back.
      • chipperyman573 10y ago
        What if you're watching a video on youtube? Even if you mute it, the video will continue to play, and if you resume the video later, your saved time will be 5 seconds later than what you thought it was.
        • animeweedlord 10y ago
          Good point. It's times like these I wish there was proper separation between the "hyperlinked documents and dumb form-based UIs" web and the "jerry rigged universal app runtime" web. EDIT: But if it were an option or an extension, I would gladly enable it to help for 99% of sites I use and either accept the occasional weirdness or blacklist it for Youtube et all
        • icebraining 10y ago
          The browser knows how to pause HTML5 videos. If it's Flash, just kill it off.
      • nitrogen 10y ago
        What are you losing when you use Ctrl-Shift-T?
        • animeweedlord 10y ago
          Even if everything is cached, there is an annoying delay while the tab is reconstructed and the server is pinged. Even for something as trivial as a directly viewing a single image. That's my main pain point (I really do think about frequently), but if others are having problems with AJAX-generated forms or whatever, it would help them too. Another example would be losing your place in on an infinitely scrolling page (yet another web anti-pattern) because you accidentally closed the tab. I would appreciate having a second to correct my mistake before I having to do the"scroll wildly for 30 seconds until it catches up to where I was" song and dance.
• drostie 10y ago
  This can be a little dicey when AJAX was used to render the form that you're thinking about submitting; for a browser to Do It Right they may need to cache complicated stuff like (a) the entire DOM and (b) the entire state of the JS interpreter at the moment navigation began away from the page. Even if we only do this on backwards navigation and immediately trash it when we navigate forwards to a new location, it still sounds to a developer's ear like a memory leak waiting to happen. It might be mitigated if you store no more than, say, 10 pages back.
  • iopq 10y ago
    when you get the form back up, the browser should fill it because it should remember the form state from earlier alternatively, just don't browse away when you have something filled in a form - just ask the user if they meant to do that
    • shkkmo 10y ago
      Detecting and/or saving "something filled in a form" is hard to do with 100% accuracy across all the oddly implemented forms out there. While I feel it has slowly gotten better over the years, especially on well implemented pages, it is still a common enough issue that another solution was needed. I do wish they had mad a user configurable flag rather than forcing people to use plugins to re-acquire functionality they had before.
      • makapuf 10y ago
        Or maybe like just disable it if there is something to lose ie there is a form and I entered something in it with the keyboard
        • Jtsummers 10y ago
          That would be worse. Then the expected behavior (that backspace would navigate back) wouldn't occur because I'm filling in this form. Even though I've left the field (so backspace is captured by the tab and not the form field) and have decided to abandon the comment and go back to reading the thread.
• niels_olson 10y ago
  Wait until you're filling out online mortgage documents, or a security clearance application, or some other high-stakes documents. You will not like the backspace to go back function. Your adrenergic nervous system will make sure of it.
  • spacecowboy_lon 10y ago
    So you think filling out a security clearance form online is a good idea
• nkoren 10y ago
  The web no longer consists of just static web pages and form data. I build complex web applications, which are stateful in many ways that don't involve forms (and involve things like websocket connections, etc). There's no way that the browser could possibly recreate that state by going forward. So web apps of any complexity must necessarily intercept the delete key and break its functionality. And to the extent that the web increasingly consists of such apps, it means that "delete to go back" has long since being a standard feature that users can count on. That's just a fact on the ground. Time to remove the expectation entirely.
  • michalstanko 10y ago
    Finally someone brought up the fact that web does not consist of static classic HTML forms only, HOWEVER I still think Chrome could just restore those that ARE static, and as for the forms that are rendered using client-side templates in single-page apps, their creators should store them as they're being filled, just like Gmail or Google Docs store what you're typing without you having to save it manually. I incline to believe that users that were filling out long forms (and subsequently complaining about losing data because of hitting backspace) were filling out classic old-school static HTML forms, where automatic form restore by Chrome would certainly help.
    • grncdr 10y ago
      I agree that automatic form restoration would be very helpful, but there's a huge space between classic HTML forms (where this is "easy") and single-page apps (where nobody really expects it to happen). That space is where complex, dependent-on-javascript-for-no-good-reason forms live. The kind often encountered when dealing with financial & public institutions. It's unlikely that automatic form restore is going to work for a lot of these (especially multi-step wizards & the like) so preventing an extremely common accident seems extremely prudent to me.
  • __david__ 10y ago
    > There's no way that the browser could possibly recreate that state by going forward. Of course there is—just don't delete anything immediately. All your state stays there like it's in its own (hidden) tab and gets lazily garbage collected "some time" later. If the user navigates back, there's nothing to rebuild as everything is still sitting there intact.
• eslaught 10y ago
  > > The correct solution: Cache tab history completely [...] This is not a solution for the majority of users. The problem with keyboard shortcuts is that most users won't know what happened. All they'll know is that suddenly they're not on the same page any more, and then won't realize they've navigated backwards. Therefore they won't think to navigate forwards again, and they won't get back to their form data, even if it is cached. This happens to me all the time in Emacs. I'll press something by accident, make major unintended changes to my file, and have no idea what I did. Fortunately, Emacs has a way to look up key presses, but this is a relatively advanced feature that typically doesn't exist in other tools anyway. Whenever you have a feature with zero discoverability (e.g. essentially all keyboard shortcuts), you have to be very careful to avoid the "what did I just do?" phenomenon, even if you provide ways to get back to a previous state. I personally think this change by the Chrome devs is extremely reasonable in that regard. Edit: I realize that these changes are aggravating to users who actually use them on a regular basis. However, please also realize that they are not zero-cost, because they do impose a constant and non-trivial burden on everyone else (especially in cases like backspace which are relatively easy to hit on accident).
  • nitrogen 10y ago
    Keyboard shortcuts are only undiscoverable because apps stopped listing the shortcuts next to the menu items.
    • aeosynth 10y ago
      Menu items are only discoverable to those who take the time to look through them; the majority of users do not.
      • chc 10y ago
        Isn't that what "discoverable" means? That if you look for it, you'll find it?
    • chc 10y ago
      In the case of "Go back," there are two or three keyboard shortcuts in most browsers, of which I'd guess backspace is probably the least (intentionally) used.
• stevefeinstein 10y ago
  This is the correct answer. However even this isn't enough. I would also remove backspace from going back a page. It should never have been a thing. Having a key that performs a function modally when the context isn't very clear, is just ripe for confusion. And confusing it has been as the fact that this issue was raised.
• dilap 10y ago
  leaving a page is still traumatic, and caching is never perfect (passwords &c). honestly this was always an insane shortcut.
• te0x 10y ago
  > Your solution: Make it harder to move away. The more genuine way to phrase this would've been something like "Your solution: use different keys for moving away from a form and erasing data", which sounds a lot more reasonable
• debaserab2 10y ago
  Oh man, I can't even imagine the myriad of ways that functionality would fail in today's client side JavaScript apps.
• rayiner 10y ago
  A modal shortcut key whose behavior differs depending on the content of the text-box that has focus is still a braindead UI feature that causes unnecessary surprise. Making the consequences of screwing up less severe doesn't change that. There is no rational defense for overloading a single button with two totally unrelated functions (navigation and text input). It's a design wart that people are defending on inertia alone.
  • jacobolus 10y ago
    Keyboard shortcuts are horribly broken, because all of the common keys (tab, space, return, escape, etc.) and various other standard shortcuts have been overloaded with abandon over the years. In a better world, there would be much clearer defined intermediate interfaces between keyboard hardware, operating system, and final software (e.g. the native app, system shortcut, or browser javascript) performing the action for the user. Every interface would be clean and straight-forward, and easy for the user to adapt to her preferences. In the world we live in, there are a confusing mishmash of 6–7 intermediate layers, which differ on each operating system and keyboard, some of which can be partially adapted by the user, but many of which can’t. These layers are poorly defined, not understood by users, and reach into each-other with various ugly hacks, and they often co-opt each-other’s keyboard shortcuts in arbitrary and confusing ways.
• phasmantistes 10y ago
  Chromium already puts heroic effort into maintaining form state. Note that, a lot of the time, it works great. For example, here on HN, if you enter half a comment, go back, and then forward, your comment will be preserved. But it is hard. No browser has succeeded in serializing full tab state: dom, forms, js, pending requests, etc. Chromium has been working on it and has large pieces of it but it is very very hard to get even close to fully correct. You're letting perfect be the enemy of better.
• dclowd9901 10y ago
  This can be dangerous behavior, or illegal behavior in the case of password fields or credit card information being retained (in JS, you can't backfill password fields, so I don't want my browser doing it with ephemerally cached info). I am fully willing to sacrifice something I don't use (and very few people rely on) over having to refill out a form or risk security to accommodate a very dated and almost unused behavior.
• smegel 10y ago
  Oh yes, then you click forward and JavaScript on the page wipes all the fields. Good thinking 99.
• ikeboy 10y ago
  Or comment 34: >Why not disable backspace only when some form has data entered? Why remove the feature in all cases when the reason only applies to some?
  • Klathmon 10y ago
    Because then we have 3 different ways that the same key will work depending on the page (delete text, go back a page, do nothing?).
• dredmorbius 10y ago
  I'd argue for both. Caching local content as drafts-in-process does in fact make a great deal of sense. How to present that poses a new set of UI/UX considerations. Perhaps not grave, but significant. I do hold strongly that the "backspace to navigate* motif is either profoundly broken or tied to unacceptably weak state stickiness of editing content itself. It's a callousness, capriciousness, and lack of consideration on the part of browser developers to users concerns (as opposed to advertisers) which I'm very hard pressed to defend on any basis.
• LoSboccacc 10y ago
  "Correcter" solution: onbeforeunload handler
• psook 10y ago
  Shortcuts for standard features should be configurable without extensions. The fact that none of the modern browsers implement this is shameful, not the specific choices they make with bindings.
• seanp2k2 10y ago
  For form recover, Lazarus is available for Firefox and Chrome and works wonderfully most of the time. It's saved my bacon on many occasions.
• Fabroskii 10y ago
  What about applications that contain a JS environment? Is this not lost when navigating away, unable to be rebuilt from cache by moving forward? What if my application needs to do something during data entry that can't be replicated by auto-populating the fields? I believe this is taking power away from web developers and putting it into browser developers. That's a bad thing.
• lloeki 10y ago
  To me the worst offender is not loss of data (seriously this is just a web form) but loss of context. Having the current location change is disorienting to the user† especially when it's not the expected result. IIRC Safari had some CMD+Backspace ("Clear history") that I kept on triggering the same way, as in a Cocoa text field it means "Clear from cursor to beginning of line"), but apparently they (thankfully) removed it too. The process, and resulting effect, was the same. Basically in terms of usability this boils down to the key behaviour following an implicit mode (triggered by what's focused), making it hard to discover (or discovered the hard way) and unpredictable. This is similar to Safari's braindead CMD+Z that does both "undo in a text{field,area}" and "reopen last tab". † even though I myself know what happens I am taken aback every single time because it just breaks the flow, resulting in grievous annoyance. Therefore, props to the Chrome team.
  • Margh 10y ago
    fun fact: when the dagger you've used to indicate footnotes is attached to a person (the user), this typically indicates that the person is now dead. i thought you were applying some subtle commentary about the change until i saw you agree with it.
• Shorel 10y ago
  Old Opera did this, before all the other browsers. It still did not help them gain more than 4% marketshare.