Wouldn't something like an "This page contains unsubmitted form input. Are you sure you want to leave?", with maybe a configuration option to disable it, be far better than breaking a long-established and extremely useful keyboard shortcut? Instead the developers chose the easy way out, to pander to users who are apparently too stupid to notice that the focus is somewhere other than the text field they're entering into. Why not also remove the ability for spacebar/Enter to navigate to the currently focused link (or have they removed that already)? If you start blindly pressing keys on a page without looking, it's your own damn fault.
In any case, this screenshot of Opera's keyboard shortcut configuration shows just how far browser configurability has regressed:
> to pander to users who are apparently too stupid to notice that the focus is somewhere other than the text field they're entering into
I think you've just insulted a lot of people. I've run into the backspace behaviour multiple times and never on purpose. Here's a few reasons why it can happen, apart from stupidly mashing my keyboard, which I assure you, doesn't happen very often:
- touchpad not registering a click on the text field
- element reloading due to weird js and losing focus
- tab switching properly between the first 4 fields, but then focusing some random button instead of the 5th input
- broken custom JS elements which don't quite understand focus and editing
- general keypress hijacking which doesn't do what you want
I don't look at the keyboard as I type and I don't always look at the screen either. I expect the text actions (input and editing) to work on text. If I have to think about which possible, implicit mode I'm operating in, it's a bad design. Or are you saying that before every keypress you visually verify where your cursor is, is it blinking, is the right window focused, are there multiple cursors with fake focus, etc?
touchpad not registering a click on the text field
It's not hard to notice whether an element has focused, and especially if you know you have flaky hardware, be aware of that.
All your other reasons are the fault of the website, not the browser.
I expect the text actions (input and editing) to work on text. If I have to think about which possible, implicit mode I'm operating in, it's a bad design.
You're implying that the computer somehow magically (telepathically?) determines exactly where your input is to go. That's not possible.
Or are you saying that before every keypress you visually verify where your cursor is, is it blinking, is the right window focused, are there multiple cursors with fake focus, etc?
In a word, yes. It's seriously not hard to see where the focus is. I usually have multiple windows open but there is only one cursor and it's the only thing that's blinking. Many others I've seen maximise their browser window, so there shouldn't be other cursors much less blinking ones visible (unless there is some strange bug which does cause this --- in which case that is definitely a bug to be fixed). If I'm at all unsure, I make sure.
Besides, if I'm going to submit some very long text, I'll write it all in a real text editor first and then copy-paste.
I don't always look at the screen either.
That's like saying "I don't always look at where I'm going when I drive. Why do I keep crashing into things?"
You're extremely self-centered and dismissive of other people's experience, I have to say.
I'm sorry, but maintaining your little piece of convenience isn't worth denying other users a more forgiving user experience.
You're probably a twenty-something with sharp reflexes. What's "not that hard" to you on whatever websites you happen to use may be a significant challenge for older people who are forced to use terribly designed websites/webapps for work or other services.
You're extremely self-centered and dismissive of other people's experience, I have to say.
The same could be said of the developers who think they're always right.
I'm sorry, but maintaining your little piece of convenience isn't worth denying other users a more forgiving user experience.
Judging by the other comments here, I'm not the only one who uses this shortcut.
You're probably a twenty-something with sharp reflexes.
I'm much older than that. If anything it's the younger generation who are driving most of these unpleasant UI changes and dumbing things down. Reflexes have nothing to do with it. Read carefully, slow down, and pay attention to what you're doing.
What's "not that hard" to you on whatever websites you happen to use may be a significant challenge for older people who are forced to use terribly designed websites/webapps for work or other services.
That goes back to my original suggestion of having a prompt dialog, and making it configurable for those who don't want the "permanent training wheels".
"Judging by the other comments here, I'm not the only one who uses this shortcut."
So what? There's a lot of people who actually lose data due to this "feature". Even if there was more of "your kind" (which I doubt), preventing data loss is more important than slight convenience. You can easily change a setting or a commandline option or install an extension. A lot of other people would need to call tech support for that, because they're afraid they'll break their computer...
"Read carefully, slow down, and pay attention to what you're doing."
For someone beyond their twenties, you're certainly a wise-ass, I have to say.
"That goes back to my original suggestion of having a prompt dialog, and making it configurable for those who don't want the "permanent training wheels"
Your suggestion doesn't work. It would literally break some applications and make others so annoying to use that the prompt would be the first thing users disable, bringing us back to square one.
The underlying problem is unsolvable for a browser vendor. All that can be done is to mitigate it by reducing accidental back-navigation. If that means people like you are inconvenienced, so be it.
> The same could be said of the developers who think they're always right.
Browsers often include telemetry which can answer questions like "how many of backspace presses to go to the previous page were accidents" which may prove them right. While I don't know if that or a similar method was used or not, why do you think they just "think they're always right"? What if they did a proper research on the usability of this change and found you're in extreme minority?
There was a G+ discussion where Chrome devs discussed this. The suggestion of rigging up monitoring to look for this was considered, but the case was seen as so obvious (user-state loss vs. a week or two to adapt to a changed shortcut) that it wasn't considered worth the effort.
IMO the data above is enough when coupled with anecdotal data. Given that it didn't seem worth investing the considerable engineering effort we would need to gather more data. Although there was disagreement on that point. As Peter said, this decision was only loosely based on metrics. Ultimately it was intuition based on a combination of the data mentioned above and anecdote.
> It's not hard to notice whether an element has focused
That's not true for many websites. Maybe you're not using them, but in that case accept that others do.
> and especially if you know you have flaky hardware
We all have flaky hardware. It's called human body :) Sometimes your touchpad press will not register, whatever the computer hardware.
> It's seriously not hard to see where the focus is.
If you're using only websites where it's true, great. First example off the top of my head where it's not true: https://www.anz.com/INETBANK/bankmain.asp - start typing anything in the login box - you'll lose the focus or the page will reload after ~10 seconds. It's one example, but there's lots of similar ones. Another fun one is on a page (not linking, because account is required) where the text boxes for credit card will automatically skip forward every 4 digits, but when you backspace they'll just lose focus instead of skipping back.
> You're implying that the computer somehow magically (telepathically?) determines exactly where your input is to go.
No, that's not it. I'm saying that if I do actions that should put me in a specific mode, a good design does two things: 1) makes it trivial to notice that it happened and 2) minimises the errors if it didn't. Since point 1 is up to the website (and often the mode is not explicit at all), the browser can only handle point 2.
> That's like saying "I don't always look at where I'm going when I drive. Why do I keep crashing into things?"
Here's a large group of people you're missing: people working on a remote desktop with the server not in the same building. This for example includes a lot of government and healthcare offices. If they had to wait for local response for every single character they typed, rather than assume the input mode doesn't randomly change, they wouldn't be able to do their jobs. (on time)
> All your other reasons are the fault of the website, not the browser.
It would be a beautifully principled stand for a browser to take to refuse to fix the problems of a web site, but the result would be a browser that couldn't navigate the web. After all, the first problem it would refuse to fix would be invalid HTML.
I guess I'm one of those "too stupid" ones, it happened many times to me... you're tabbing between inputs, and in speed you press first Backspace and then Tab, and boom, you've lost all the data entered in the form...
Don't most major web browsers save unsubmitted form contents in history? I hit back followed by forward while composing this comment and it was still here.
Or is this one of those "web apps ruin everything" things...
> Wouldn't something like an "This page contains unsubmitted form input. Are you sure you want to leave?"
Firefox presents this message, but it's unreliable and doesn't always present itself. I've already been used to an Alt+Left/Right binding [1] for navigation for at least a year in Firefox thanks to re-binding addons [2]. Backspace was both further away and too annoying in situations where input would lose focus (which can happen, and invisible/near-invisible focus styling on various input fields doesn't help). Chrome has always kept customization on lock-down, so this change to reduce such errors isn't surprising to be honest.
[1] I use a half-size keyboard, where Fn+WASD is mapped to the arrow keys for one handed navigation.
[2] keyconfig and KeySnail are both ones to check. The latter allows for key sequences to be bound to hotkeys (eg: typing 'pin' outside of an input to pin a tab), similar to Opera Presto's mnemonic keybindings ability but not quite as powerful.
Your suggestion doesn't work: Testing for "unsubmitted form input" is inadequate. With web apps and even many non-trivial forms, there is no way to tell if the page contains precious unsaved content, or if the user has performed any kind of work that they don't want to lose.
I hope he was not. As a 'power user' I use GleeBox for keyboard navigation to links that match the text I enter. And as a power user, I've occasionally accidentally navigated away from a page by using space/enter while I was focused on a link without realizing it. Or backspace in the wrong context.
Considering that I never intentionally used the space/enter action to navigate to a link, I wouldn't mind browsers removing this.
I rarely encounter people who are so incredibly unsympathetic to the difficulty others face in using technology (even 'power users' like myself, apparently). Surely there's a point where perhaps we should at least consider changing our approach, when what works for us does not work for many (most?) other people. I haven't met a single non-power-user who actively used backspace to navigate back to the previous page, for example.
At the risk of getting too personal, but with the memory of seeing my mother and grandmother actually crying because something they cared about disappeared for some reason that only I understood: please find something else to feel superior about, or just shut up and feel smug by yourself. It's difficult and frustrating enough already for many people to adapt to the rapid technological changes around them.
Why would anyone overload a key commonly used when typing when mouse gestures are readily available? It's long established, but I, for one, have utterly detested its use ever since I discovered it. You can have alt-left arrow or something and you'll be used to it in a week, whereas everyone else won't lose their forms.
Wow, you jumped to some crappy conclusions rather quick. Maybe some people are not afraid of change, but simply use backspace on the daily basis? I am not one of them persons, but your reply is rather aggressive and assuming there is black or white in this case.
Webapps are too complicated to have this working reliably these days.
Imagine a website with a support chat generated by js extending from the side. Would you expect going forward/back to this page to restore your chat state? I can come up with a number of reasons for yes and for no. But the best option in this case is: make accidentally going away from that chat session very hard.
Yes, saving input won't be possible. But generally, applications that accept user input and cannot save it for some reason ask for confirmation to lose it, so users won't lose it accidentally. Take a text editor for example, you can open it and close it and it won't bother you, but if you write a few words and try to close it, it will ask you whether you are ok losing the data. This is what users expect nowadays. Chrome team somehow doesn't understand/recognize that and instead of fixing the problem in a generally accepted way, tries to rearrange the interface to have fewer accidents, breaking UIs too much in the process and pissing off a lot of users. And that's bad.
"But generally, applications that accept user input and cannot save it for some reason ask for confirmation to lose it, so users won't lose it accidentally."
You'd think they do, but they don't, at least not all of them. The problem isn't the properly designed webapps, it's the improperly designed ones. That's what you somehow don't understand/recognize.
Also, the problem with the redirect happens on a certain popular bulletin board software that works without Javascript (and therefore doesn't provide such a prompt in the first place).
I was talking about desktop applications, not webapps, because web browser is a desktop application and is expected to behave like one. Webapps don't have to do anything.
I don't understand your point, then. We are talking about web apps. Is Chrome supposed to alarm you when navigating away from any site with form input? How would it know if your changes are unsaved or not? (It can't)
Chrome might not be able to, but the website can, surely? Why not leave it to developers to properly handle state within their application (e.g. by using history and 'beforeunload' functionality) rather than second-guessing it at a browser level?
Then the problem would ALREADY be solved, because all developers would already be properly handling state within their application instead of second-guessing it at a browser level. But they don't.
The only thing it could do is alarm you for navigating away from any webpage that has any form that has ever had input put into it. Also, the website could intercept the "go back" event for some purpose. Should the browser fire an alarm then, as well? Either way, it would be a terrible user experience.
There's no notion of "unsaved" changes. There's the notion of form data that hasn't been submitted, which is entirely different. Many web apps don't use "submit" at all, ever.
I fully support this decision (though the chrome team has made some really odd decisions - https://bugs.chromium.org/p/chromium/issues/detail?id=377191), but why is there a general move towards software not being configurable? In the past lots of software packages let you set the key bindings to your heart's content. It feels like more and more software is removing this ability. Are there architectural reasons? Is it a costly feature to maintain?
Yes, it's costly to maintain the combinatorial interactions between configurations. But 'make it a setting' has further costs- when you're supporting a customer and you can't figure out the exact state they're in, when you can't make sweeping product changes because 8% of users have some incompatible option set, when someone implements a bad feature and there's no strong way to keep it out if you can just 'make it a setting', or when a feature becomes obsolete but is kept around 'as a setting'. It relieves the product team from one of their most important responsibilities.
I know your numbers are only an example, but taken at face value — if 8% of your users have an option set, maybe it's because you've overlooked a user-case that's valuable to them. In that case, having a configurable app that can feed you in this data is like free A/B testing and is a boon to a product team, IMO.
Every configuration toggle is something somebody can break by clicking it wrong. For most people, things like this are a source of background worry, not a useful benefit.
Is that why the Backspace key suddenly doesn't work on Chrome anymore? Annoying as hell. Who made this stupid decision?
Android has back key and home key that users hit accidentally all the times. That doesn't cause much problem. Why can't the Web apps save their state to better handle the accidental exit of the app? It's not just the backspace, Ctrl-R and Ctrl-W all exit the app.
Overloading backspace with "go back" was a stupid decision. Undoing it was way overdue.
"Android has back key and home key that users hit accidentally all the times."
The back and home buttons are not overloaded with other meaning based on context. Android applications tend to handle accidental "back" presses gracefully. Accidental "home" presses are usually of no consequence whatsoever.
"Why can't the Web apps save their state to better handle the accidental exit of the app?"
Who cares? They don't and they won't.
"It's not just the backspace, Ctrl-R and Ctrl-W all exit the app."
It's way less likely to accidentally hit those combinations. For backspace, it happens all the time.
"Don't break existing functionality!!"
The functionality isn't broken, it's just that the few
people who actually use this shortcut will have to use another shortcut now. Big Deal.
The back and home buttons are not overloaded with other meaning based on context.
Surely you jest. The back button has seen significant overhaul in the time since it was introduced; it changed from activity-to-activity navigation along the single "back stack" to a confusing, circuitous path walk between applications, their "up" stacks, their "back" stacks, and everything else under the sun. It's difficult to determine when it will take you to the previous activity or to a page you haven't seen in the days since you last launched the application you just ended up on.
If you're in a browser, the back hardware key takes you back -- until it determines that you've reached a navigation root (which might not be the earliest page in the chain), and it pops you back to the previous application or the home screen. Perhaps it closes the tab?
If the keyboard is up, it dismisses it -- unless you're in an autocorrect action (* on certain phones). Maybe it opens the keyboard, too, because it took you back to a previously focused field.
It's far from "not overloaded with other meaning based on context". It is, in fact, "entirely overloaded with other meaning; much of which is based solely on context."
It may be confusing, but that confusing "back behavior" is the one behavior it has, even if it has changed over time.
It is not overloaded. It doesn't start deleting characters depending on where your last tap may have (accidentally) been. Well, maybe some app does that, but I hope you get my point.
Firefox has handled this correctly for ages. The Windows version defaults to Backspace to go back, I guess for compatibility with IE, and the Linux version doesn't. But in either case it's possible to change the behavior of the Backspace key in the options.
Very funny seeing so called "powerusers" complain they have to unlearn perhaps the most stupid shortcut key in the history of shortcut keys, and instead use another, much more obvious shortcut key (alt + left)
and as a bonus, I just discovered the windows + left key, which is properly awesome on this shiney new(ish) xps 13 (much better than the old rotate screen functionality).
Oh, it's accidental hitting of the Tab key and Enter key. You know. Those pesky browser developers mapped those key completely wrong back in the days. If only they unlink the Tab key and the Enter now and force people to only use the mouse click to submit, life would be so much better. /s
It's not accidental. its the "unexpected behaviour".
Tab, enter etc serve exactly the same purpose all the time.
Backspace doing delete one character or delete everything depending on where the mouse is pointing could probably only be beaten for stupidity if pressing the enter key while the mouse is hovering over the close button actually closed the entire browsing session.
Because, as power users, who use both the keyboard and stateful pages, forward "rarely" restores the state and is technically forbidden from doing so.
So an accidental thumb tap a touchpad + trying to delete a character produces a wait for the entire app to reload and then get back to where you were - which can take minutes assuming you were lucky and said app hadn't decided to wait 30 minutes to autosave.
In fact I had turned off fast tap on the touchpad for exactly this reason, glad I can turn it back on again.
If moving the mouse to the backspace button (seriously, the whole point of keyboard shortcuts is for people typing with both hands and not using the mouse) is such a problem, clean the mouse and turn up its sensitivity.
Or better yet, get a touchscreen, you'll never want to go back to mister mouse.
Try to view it overall as a product decision. I don't think it is necessarily "stupid". In fact I think a lot of thought went into it. Not just someone saying "oh today I will remove the backspace functionality".
I think your arguments are sounds. Don't break existing functionality is good but you have to take it into context. Sometimes you have to in order to make the product as a whole better.
If the intent of your statement was to mimic the sort of uninformative, bland, and completely generic pseudo-palliative doublespeak that often comes from management trying to justify their ridiculous decisions, you've done a great job.
"You don't like it? Too bad, we're doing it anyway" is what such statements are actually saying.
I think you're missing the fact that it says both things. Both "we're aware you don't like it; we're doing it anyway" and "it's a product decision".
Emotionless calculation: X% people like it current backspace behaviour, Y% people use it only by accident (they may actually have telemetry to know the percentages). If they change the behaviour, Y% will be happier, which X% will split into "installed extension to revert", "won't care after a month", "switches browser". If the overall change is positive enough, they made a good product decision, even if you and I don't like the new behaviour.
It's just a lazy way to fix a perceived problem, and didn't fix it completely. The correct way is to preserve the states, like the phone apps. iOS and Android have solved it for the longest time.
That doesn't work. The shitty web app is going to intercept the "go back" event as "destroy all user data, as intended" and you're fucked.
If this never happened to you, good for you, you lucky bastard. Now get out of the way, this is a quality of life improvement for millions of real people out there. Hard working people. Mothers and Grandmothers. Think of them while you are bothered to work around this slight inconvenience of yours.
Android users don't use the back button to edit text.
Some web apps can and do save their state, but not all of them do, and you can't force them to by administrative fiat, filing bugs with mozilla, huffing and puffing, or even holding your breath.
Does your phone or keyboard have dedicated Ctrl-R and Ctrl-W keys?
As a user: I really don't understand the reasoning behind this. Backspace is always easier to find, even on the quirkiest keyboards and useful for navigation.
As a Dev: If the user is in danger of accidentally loosing their work then this is a usability issue, which is easily fixed with window.onbeforeunload prompt.
Since the back button is now 'fixed', I wonder if developers are going to see a Javascript confirmation as a bad practice, leaving users who accidentally close press back or close a tab with no safety net.
This seems like a fix, for something that was never broken. I wish the Chrome team would work on giving JavaScript prompts and dialogs a much more modern look at feel.
> which is easily fixed with window.onbeforeunload prompt.
It would be nice, but realistically, you can't expect every single website to get everything correct. If you could force it on people to implement a correct onbeforeunload behaviour, backspace wouldn't be a problem. But you can't force it, and you can't force it to be correct. (webapps are pretty complicated these days "are there any unsaved changes" is not always a trivial question)
This way a class of errors has been removed rather than forcing everyone to think of it in many places.
I think it's just provided less incentive for developers to handle 'unhappy paths' within their app — there are still plenty of ways that you'd want a webapp to handle unexpected closure (e.g. user accidentally closing a tab, browser crashing, network connection dropping before save takes place). If an app is handling these states fluidly they will likely get the 'accidental back' problem solved for free.
I think the argument against feature flagging this (that this reduces app complexity) seems a bit thin.
Normally you want to reduce the number of options in play so that you don't need to think about all the permutations when making future changes — if you introduce a feature in the future, you're not stuck supporting edge cases.
But the whole point of this change is that they don't want the backspace behaviour overloaded (if it's bad UX); so it seems unlikely this would interfere with changes down the line?
Annoying that adding the toast and creating a browser extension was probably more work than adding the feature flag would've been.
> Normally you want to reduce the number of options in play so that you don't need to think about all the permutations when making future changes
Also to reduce testing overhead when you invariably don't think of permutations - which is now that much harder as you'll need to manually test with the feature flag enabled, since everyone else will probably be running with the defaults. You think all text manipulation code in and around the backspace functionality in Chrome is static? Seems unlikely to me. Also reduces refactoring overhead - less code, after all. To me, the question is which will happen first:
1) They remove the toast intentionally after everyone's muscle memory has adjusted.
2) They remove the toast accidentally by refactoring input logic and breaking the popup functionality without noticing.
The "real WTF" here is that user interface should travel with the user. It shouldn't be under someone else's control at all in the first place. It should be platform-agnostic. Windows v. Mac v. Linux (v. Web Apps) and all their applications should all have the same UI: what the user wants.
As a first approximation imagine a JSON doc that specifies a mapping from standard input events to standard commands or functions; it can be extended with application-specific, uh, specifications. It's treated as a "first-class" entity, and respected by apps and Desktops as a matter of course.
Something like that would save all this trouble, no?
In other words, just write a browser in JavaScript and HTML, on top of the existing browser.
And then you just have all the same problems over again, only much, much slower.
And who exactly defines "standard input events" and "standard commands" and "standard functions"?
Those terms don't have any meaning. Such standards do not exist, and never will. Hardware and software developers are not suddenly going to stop defining new input events, commands and functions because some yahoo on the internet proposed a hypothetical standard and insisted that everyone rewrite all their programs to use it and nothing else.
Well, I think you know the particular windmill at which I tilt. You said it yourself: we're not going to stop changing things. My problem is that it's arrogant and rude to force the changes on the users.
Backspace has been the Windows Explorer shortcut for backward navigation since Windows 95.
I use it all the time both in both Explorer and Firefox. And have never ever accidentally deleted text when trying to navigate, or accidentally gone-back when I'm trying to delete text.
It's been Up since at least Windows 3.0. They might have changed it to Back recently.
It's not suddenly an issue; I've occasionally accidentally gone back since IE 3. Between fourth mouse buttons, alt-left, and touchpad swipes, Chrome devs are starting to think that backspace-as-back is more trouble than it's worth.
Anecdotally, I've hit my mouse's back button way more often accidentally than I've gone back accidentally by hitting backspace. And backspace does have the benefit of being able to type it with one hand.
I actually use backspace a lot. I don't know of another hotkey on the keyboard that I can use to go back a page. If I space backspace it seems to alert me to do Alt + Backspace, but that doesn't function either.
It's interesting to note that quite often in these discussions the idea that no other key exists comes up. In the 1990s, keyboard manufacturers started adding "multimedia" and "Internet" keys to keyboards, including keys whose sole and explicit functions were to move backwards and forwards in a WWW browser's navigation history (or in GUI applications in general).
These keys have obviously, even in this everything-in-the-WWW-browser age, still not embedded themselves thoroughly in the public consciousness. There are clearly sizeable classes of people who don't yet regard them as the norm; and people who still first think of keys other than those explicitly engraved for the purpose as the ones to use for it, or do not even know that such keys exist.
To those who are about to miss the point: Yes, your current keyboard doesn't have these keys. You didn't regard them as the norm when you bought a keyboard/computer. They haven't become so established that you don't regard systems without them as deficient, as you very probably would regard systems without (say) a "Super"/"Windows"/"Apple"/"Command" key. This, even in a world where doing many if not most things in a WWW browser is seen as the norm.
How many keys do you feel is sufficient? Already the number pad is an extension that is adding a few keys. And a lot of laptop keyboard are using a Fn (function) key to access additional keys.
My wireless Mac keyboard has a big key in the upper right corner with a left arrow on it. No way to tell if it's backspace, delete, or left. There's also a key in the lower right cluster that has a left pointing triangle on it, along with three other keys with triangles facing in different directions. Then there are two big keys on the left and right sides with upward facing hollow arrows on them. As well as keys with double left and right facing triangles on either side of another key with a right facing triangle followed by two vertical lines, and also another key with an upward facing triangle with a line under it. Not to mention the key referred to as "option" that's labeled with the word "alt" and a branching symbol.
I've become accustomed to using backspace as a Browser Back keyboard shortcut, though I can sympathize with the hate for such. More than once did I intend to go back, only to discover the cursor was presently focused in a text box, or conversely, intend to erase a minor spelling mistake only to go back and lose everything.
I think what I value is not so much having Backspace == Browser Back, but simply having a keyboard shortcut for Browser Back. So certainly, by all means, get rid of Backspace == Browser Back. But please leave a means of configuring at least something as a Browser Back keyboard shortcut.
Glad to see this fixed, overloading backspace has caused enough lost input on websites, the binding was a short sighted mistake, there's plenty of other key combinations that make more sense.
Alt + left arrow is way more obvious than backspace. There have been countless times I pressed backspace inside a textbox and it went back to the previous page, losing all the written text.
There have been countless times I pressed backspace inside a textbox and it went back to the previous page
I can backspace all I want inside this textbox as I'm writing this comment and it won't leave the page. I'm willing to bet that your focus wasn't actually "inside the textbox", because that's not the correct behaviour, unless the browser is making you think it's actually focused when it isn't, in which case that is an actual bug which must certainly be fixed.
It happens in some cases when the focus is on the field.
Here's one condition:
There are sometimes textboxes that are dynamically set to read only depending on certain criteria. If it is set to read only at some point and you aren't aware of it, backspace goes to the previous page.
FYI, this only works in insert mode, for the word you just typed (equivalent to ctrl-backspace, basically). And diw/diW (delete inner word, delete inner non-space-characters-word) may actually be faster depending on the context since you don't need to get to the beginning of the word.
This backspace as the back button in web browsers never worked very well for me, and only seemed to work when I was entering something on a webpage. It never bothered me that it didn't work, and I never found it useful, but when it did seem to work, it would destroy a long post. I support the removal, or disabling by default.
I've already, three times at least, been saved by the fact that I'm on Canary builds where this is already active. Had typed into a form, the form lost focus, I hit backspace and Chrome popped a helpful, unobtrusive box telling me how to go back if I was trying to.
And there's already an extension that brings it back.
I hate seeing Chromium bug tracker links posted to HN or Reddit though. Just like Microsoft GitHub Issues. They just don't need more poorly informed knee-jerk trolls.
edit: Maybe I should clarify? I don't think that anyone is a troll for wanting to keep existing Backspace behavior. But when these bug reports get linked to from reddit/hn, they're invariably overrun by people making assumptions, posting memes and berating developers. It always wind up as counter-productive.
> Downvoted for pointing out how this change has helped me, nice. You just stay classy as ever.
This happens on every news site. Point out something that disagrees with the mindset of someone and back it up with facts? Downvote. I thought Hacker News was better than this?
Sometimes you get sympathy upvotes. Had a -3 converted +11 the other day for a grouchy observation guaranteed to unsettle the kumbaya groupthink around here.
'Backspace' is a widely used interface, system-wide even, and removing it breaks UI consistency.
What they could have done is actually check whether there is a form with a user filled text on the page somewhere, warn the user and ask to press 'backspace' again to confirm. That's it, problem solved.
Doesn't make a difference. You still have to have a delay for a warning message and a delay before you wait for another backspace and it won't be too short to permit these "backspace-backspace-backspace..." to ever work.
Yes, but you mention it only now. And now we're getting into actual design with all the edge cases that it should handle. The next topic would be "what's the appropriate delay" given that both the repeat rate and the repeat delay are configurable and that users can have various input devices. And what about terminals with delayed display time. I'm not saying it won't work, I'm just against the dismissive "that's it - problem solved".
Good decision. But there are other ways to lose text, for example hitting Ctrl + R instead of Ctrl + T. I am not sure if web standards allow to restore text in this case.
I haven't looked, but according to the Chrome devs, because of the way the browser is built, saving the entire state of the DOM, JS, etc. is currently impossible.
I've been highly critical of Google, highly critical of their UI/UX design generally, and highly critical of Chrome lately.
But Google and Chrome are doing the right thing here by disabling the backspace-as-navigation overloading.
I'm rather amused to see the shrieks and screams from those having to un-learn a keybinding. I understand the pain. Most of you will be over it in a few weeks.
This is a very strong argument for getting UI/UX right the first time, as it's precisely that unlearning which is a major PITA.
There are people who seem to have difficulty understanding how anyone could possibly hit a backspace key unintentionally, or that the fixe should lie elsewhere (e.g., Website designes). To this:
1. Losing user state is a Bad Thing. Composed text, lost, is a massive fail. Setting up an application and websites for failure is a Very Bad Idea. Sure, when the Web was created, browsers were, well, browsers, not editing tools. That's no longer the case. Hasn't been for decades.
2. Even evil space-alien-cat geniuses fall prey to this. I've been using computers for a few decades, occasionally get paid to manage, use, and/or program them, and seem to have most of my wits, vision, and motor control about me. I still get hit by this routinely.
3. Not everyone's so lucky. I work with people suffering visual, motor control, and mental impairment issues. Intelligent people, who manage with their own lives. Most have been using computers themselves for decades, some longer than I've been alive. But yeah, when your body and brain start betraying you, it's a real bitch. Overloaded functions, particularly destructive ones, which act in ways you didn't expect, and worse, can't readily detect, are really bad.
Step outside your world for a minute.
And if you're designing interfaces, get that shit right. Because someone's going to be cursing your name in two decades.
Just when users get used to some basic UI/UX element, some hotshot who's angry at his/her boss comes along and ruins everything...
One specific thing about web that bothers me is lack of keyboard support for most apps. Unplug the mouse and you can't do much else with the web (esp. if it's flash). Backspace and Ctrl+W are the two most useful bindings I love in a computer.
If you're going to unlink the "Backspace" because some "stupid" users accidentally press it, then you might as well "re-design" the whole keyboard, cause some idiot is going to press F5 by accident...
They rolled this out on chrome recently. Annoying as crap. At least there's a command line option to go back with backspace now. Hopefully they don't remove it. I may have to use another browser if they do...
Ah, they must have pushed that out after I was trying to restore this functionality a couple of weeks ago. Previously it was just some random that everyone was linking to.
They released an extension that you can use to bring it back - "Go Back With Backspace" - for some reason the Chrome store is erroring out when opening it at the moment.
I don't know when it was introduced, but the sideways scrolling history navigation thing has caused me to lose form input several times now. I use a trackpoint, so it's really easy to scroll sideways instead of up/down accidentally (middle button + trackpoint). I guess that's a very niche problem, but I've lost a lot more input that way than via backspace.
At least Chrome shows a helpful "Use Alt+Left to go back" message when mashing the backspace key and expecting it to go back.
As usual, they have chosen the worst possible "solution": removed the shortcut, didn't add an option. They did miraculously have time to flash up the two-key shortcut for back though, when they detect you pressing backspace multiple times.
Instead of, you know, taking that opportunity to show a simple popup of "do you want backspace to browse back?".
So now everyone has to install an extension that in the usual Chrome fashion can "read and change all your data on websites you visit."
I think for the next kind of feature they remove this way I'll add an extension that initially works and then have it auto-update to redirect people from everywhere to a petition site after a random interval. Just to point out the insanity in pouring lots of effort into security, sandboxing and even SSL only to force people to install auto-updated untrusted extensions that can access everything to bring back a minor keyboard shortcut. This is the exact kind of annoyance that will see people click yes yes yes on all kinds of red flashing security warnings.
"Never really remove anything, just wrap it in a default-off config option" is a horrendously bad way to build software. Every configurable option is an opportunity for bugs and an opportunity for misconfiguration.
You're right that it adds complexity. Every line of code contributes to complexity, and increases the number of places a bug could manifest. That's just the nature of software development.
Most software doesn't exist in a bubble of strictly-defined use cases. Software such as web browsers target a huge (potentially the broadest) range of users. Driving towards the lowest common denominator, as Google have been doing with Chrome by stripping configuration options over the years, doesn't result in a product people love to use. It produces software that performs adequately for the majority, and nothing more.
For features like "backspace to navigate back", throw them behind a flag. Make them default-disabled. Don't even worry about putting it in Preferences - tell power users who need it where they can find it (chrome://flags).
If you want an infinitely-customizable web browser which has everything available in a config option you're free to write one; multiple high-quality open-source engines are available to build around.
Not every feature is good or widely-used, and removing the ones that fail, rather than trying to keep them around but configurable, is simply the right thing to do.
You say "removing ones that fail", but surely that's the point here — it only fails for users who don't know what's going on.
If I deliberately reenable backspace as 'Back in browser history', I've no right to complain if I lose web app state; and if I get burned often, I'll disable it again. If I use it without any problems, what's the lose on Google's side?
Exactly. Taking your thought a step farther... You can enable the shortcut yourself via extensions! That way, there's no loss in Google's side. :) they don't have to maintain an obsolete feature, and any problems are yours, not theirs. You seem to have made their point for them.
Less code base to cover. Less tests. That's a win for the secs. And you're free to install an extension to retrieve the behavior of you want. Sounds like everyone wins.
I think it depends on the reason for the change. If the reason is primarily to reduce complexity or remove a buggy feature, it would make sense to remove the feature entirely from the code.
In this case, the shortcut is being removed because it's often unintentionally triggered by people who are not familiar with it, however there are also a lot of people who intentionally use it frequently. It could be reasonably argued that something like that should be configurable.
If you are going to argue this, you might just as well start arguing that no programmer is allowed more than a quota of 10 ifs per month. Every conditional branch in your program is "an opportunity for bugs and an opportunity for misconfiguration".
This is the equivalent of hoisting a white flag. Theres tons of code added to Chrome all the time, it doesn't add configuration options but it sure as hell has the very same effect.
An if is just an inconsistent goto, so, yes. if is often a code smell.
For instance, any code like
x = some_result()
if is_valid(x):
do_stuff_with(x)
is indisputably an opportunity for bugs. Better would be some construct like "if let" in Swift or Rust, where you can't use x without the condition. For instance, this was the fundamental cause of Apple's "goto fail" vulnerability: the language / API style required that they check each result and run a conditional branch on their own. (The proximate cause was bad language syntax, but the opportunity for bad syntax shouldn't have been there in the first place.)
Meanwhile, long experience has shown that making things configurable instead of just removing features leads to... bugs and misconfiguration. There's a reason why this is widely considered an antipattern in UI; it should be an antipattern in code as well. Not every feature needs to exist, and if not enough people use something, or if it interferes with other features more often than it's directly used (as I suspect is the case with backspace), then it should be removed.
Does that not depend on the software though — the likelihood that you have "powerusers", the difference in usage between novices & power-users, the learning curve, etc. etc.
Look at something like Photoshop — the level of configuration options is immense, but thousands of professionals use it daily without issue. It just has sensible defaults that can be restored easily.
This may be the first time I've ever heard someone seriously praise Photoshop for good UI or software design.
Most of the people I know who work with it just barely tolerate its UI and its incessant bugs. Wonder if that has anything to do with trying to support everything everyone ever thought of? :)
From G+ discussion where Chrome devs discussed this decision in May of this year.
The suggestion of rigging up monitoring to look for this was considered, but the case was seen as so obvious (user-state loss vs. a week or two to adapt to a changed shortcut) that it wasn't considered worth the effort.
IMO the data above is enough when coupled with anecdotal data. Given that it didn't seem worth investing the considerable engineering effort we would need to gather more data. Although there was disagreement on that point. As Peter said, this decision was only loosely based on metrics. Ultimately it was intuition based on a combination of the data mentioned above and anecdote.
One of the things it might be time for is for keyboards to adapt.
Copy. Cut. Paste. Forward. Back. Undo. Redo.
Is there a better way to achieve these things than CTRL-key and backspace? Pretty sure I use some of the above more often than "Q", to say nothing of "Scroll lock" or "Insert".
There are keyboard layouts that do this. I'm not particularly knowledgeable about layouts optimized for English, but I use neo2. It's optimized for German (primary goal) and programming and English (secondary goals). It's fourth layer (activated with the key right of the space bar or of left shift on a 105-key keyboard) contains a lot of navigation keys and a numpad.
Reading through most of the comments, I'm led to ponder what the cross-section of the "about time/let it go" and "use vim/emacs/sublime/$editor and configure your own key bindings" might be. Same with the "use mouse button x/gesture/etc".
Personally, as a heavy keyboard user, I prefer to not move my hand off the keyboard to use the mouse if I can accomplish the same task on solely on the keyboard. One benefit I've found is that I can "queue up" a key motion with my left hand while going back with my right on the backspace key.
Ultimately, everyone is entitled to their own wrong opinion! g
I never, ever have the problem of clicking on the wrong link, or going to a page I don't like.
Why should I be punished by all of these incompetent people who need to go BACK so often?
I can sympathize with the frustration of losing a convenient keyboard shortcut like this, but I'm surprised that more people haven't switched to using touchpad gestures to navigate back and forth. Your hand is there anyway for scrolling; I find it very convenient. I know this doesn't really help on a desktop machines with a mouse, though.
You are right, there are different input methods, some of which are just as convenient. I actually use a wacom tablet with a pen, so the change doesn't bother me that much. It's just as quick for me to point and click, as it is to press a keyboard button.
But the level of incompetence of chrome team in user interfaces continues to amaze me.
In Opera 12, and now Vivaldi, I got used to a really simple shortcut for going back a page: home down the right mouse button then click the left button.
Unfortunately, Mac's don't have two independent mouse buttons and I really miss that quick shortcut.
If you haven't run into this on a recent build of Chrome, just try hitting backspace a couple of times and you'll get a toast telling you how to go back. On Mac, that's ⌘+←.
We should have some top level key to do the back or forward actions on browser or file navigator, this is a so common action, Alt + <- needs 2 hands this is not acceptable.
I'm a very happy backspace user (to the point where I wrote an extension to bring it back), but alt+arrow (or cmd+arrow on a Mac) are one-handed on laptops--which more and more people are using on the regular. There are reasons not to remove it, but this isn't really one.
Chrome will show an overlay box if you press backspace a second time (seeing it not work the first time as you expected) telling you to use Alt + <- to go back.
The shortcut was invented by a Microsoft and came to browsers through IE. Firefox only does it by default on Windows and Safari has never supported it AFAIK
Not true. Safari used to support it and it was removed in Safari 6.
I remember when it was removed; I had been an avid user of the shortcut for many years. It hurt at first, but after a bit of getting over the muscle memory, I don't miss it at all now.
To everyone complaining; let it go, our browsers are better off without it.
In any case, this screenshot of Opera's keyboard shortcut configuration shows just how far browser configurability has regressed:
http://www.ghacks.net/wp-content/uploads/2012/05/keyboard-se...