I'm going to take a somewhat contrarian view and say, "Thank you, Chrome developers."
It's always easy to tell apart the people who know shortcuts from the people who don't, if you watch them use their computers. Someone with a few shortcuts on tap will zoom around their monitors, switching between mouse and keyboard only when necessary.
But there are a few shortcuts and user interface quirks that are too outdated and weird, and only serve to surprise and annoy us. They herald from an earlier age when people were still figuring things out in new UI paradigms. For example, these days, you expect the scroll wheel to scroll up and down in a scrolling view. However, my coworker was changing some project settings in Visual Studio the other day, and he tried to scroll through the settings while a drop-down menu in the settings had focus. It scrolled through the menu options, selecting them, instead of scrolling through the view. He had to cancel the changes he was making and open the window again, because he couldn't remember what was originally selected.
This is the worst kind of surprise. Something you thought was just supposed to let you look at different parts of the interface instead modified the data you were looking at. Backspace to go back is a similar surprise. It's supposed to delete text, but instead it can navigate away from a page entirely, if you are in the wrong state when you press backspace. For the same reason, I'm even getting sick of the old middle mouse button paste, since it's too easy to press when I'm scrolling.
Forward and back navigation are already mapped to alt + left and right arrow. Let's reserve backspace for deleting text. (I'm not happy that it sometimes means "navigate up a level", but that might tell you what kind of computer I had growing up.)
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 solution: Make it harder to move away.
> The correct solution: Cache tab history completely and make it easy to move forward and backward in a tab's history by reusing cache and maintaining form contents.
Safari does this, for instance, and yes it does happen that I accidentally the whole thing by hitting backspace, but it's OK because I know if I just go forward again, it'll all still be there – fully intact.
> > 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).
> 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).
So make them an option and stop taking the Chrome route of stripping out everything that more advanced users use regularly.
Of course, this is why I run Firefox. I can do things like force OCSP enabled and get error pages when it fails - Chrome's solution was to call OCSP useless because their less technical users couldn't understand it.
Even Firefox has buried the option behind about:config and the scariest thing for me now is that we'll lose the control we get with current FF options and extensions as they "modernize" the browser.
There's a cost to this too, in terms of development effort. Yeah, one option isn't a big deal, but multiply this by the gajillion times that developers have to make a choice between something < 1% of their users want and what > 99% of their users want.
Backspace-as-back-button is not an "advanced feature". It's a hotkey that essentially no other software uses for the same behavior and one which conflicts crappily with the fundamental behavior of that key. It will take you, generously, a day to relearn the new hotkey. Instead you'd rather the developers maintain indefinitely an option and corresponding logic to support your existing use-case.
If you can't tell, my level of empathy for this kind of griping is roughly zero. Adapt to the new hotkey and save the complaining for something that actually matters.
Backspace on Windows Explorer goes up one directory, not back in your history.
In a not-at-all shocking turn of events, it turns out Alt-Left and Alt-Right are in fact the hotkeys for navigating backward and forward through history, so Chrome aligns perfectly with Windows Explorer in this regard.
It goes back in history on windows 10 too. I never actually knew that, but hey.
I definitely believe removing backspace-to-go-back in the browser is the right choice. I did know about that one, solely because every so often I do it by mistake. The problem isn't that I lose data -- I don't. The problem is that this shortcut does nothing but cause me problems I don't want. I never want the functionality, and yet it keeps happening to me anyway because it's so easy to trigger unintentionally. There's no case for this shortcut continuing to exist.
prof_habart is pressing backspace while clicking entries in the tree view, which indeed treats backspace as going one level up, not one back in history. But that's not really relevant to this thread.
Sure, I understand your argument, but this is what addons are for.
Users who want it can install an addon for it.
Chrome on the other hand has such weak addon APIs that they are often unable to achieve what's needed. Firefox seems to be moving in the same direction unfortunately.
I think it's worth it for those developers to at least maintain full addon APIs, even though there's a trade-off here it greatly increases the flexibility of the product.
Is it not actually possible to implement this with an addon? It seems possible with a small script embedded in each page. If an addon can't do this, what could it possibly actually do?
* alert if any form filled by user wasn't submitted (in case site doesn't do that already)
* let 99% of user who don't know what they did (they are in minority compared to number of times backspace is pressed to actually navigate back) retype their form if they don't navigate forward (which recovers their input, or should)
* add a third hand to human race so it doesn't take all the hands to navigate back from keyboard
* lure lenovo to restore the back / forward keys on thinkpads and make that implemented on most keyboards
> ... my level of empathy for this kind of griping is roughly zero. Adapt to the new hotkey and save the complaining for something that actually matters.
It's absolutely amazing how many comments (500++ as I write this) that this "news" generated.
I disagree here. Some shortcuts simply suck. Backspace to go back is one. This is because backspace is very useful and means something different when a text field is focused. It would be like using just plain Q to quit.
> Chrome's solution was to call OCSP useless because their less technical users couldn't understand it.
OCSP introduced a non-trivial delay (cited as ~300ms to a second) and there are also privacy concerns with it as well[1]. There's also the fact that it's set to soft-fail when the OCSP servers can't be contacted making it useless in that case[2].
Even if we ignore the above reasons for its exclusion from Chrome they do provide CRLSets which provide similar functionality but are pushed via browser updates (supposedly it's updated daily which makes it faster than OCSP). I'm not sure it's fair to say that they called it "useless because less technical users couldn't understand it". How else can CRLSets be explained then?
> There's also the fact that it's set to soft-fail when the OCSP servers can't be contacted making it useless in that case[2].
Yes, notice that I called for OCSP force/required, not just OCSP soft-fail. I've been running OCSP required for years and never had any noticeable slowdown. Maybe there's one on the first connection of the day to a site or something?
Chrome's CRLSets are extremely limited and cannot begin to capture the full number of domains which have been revoked. They can get the most popular sites and that's about it.
OCSP stapling is the superior solution which will solve this in Chrome and other browsers, but for now OCSP is the only reasonable solution in a world where millions of SSL certificates have leaked and been revoked and you care about your privacy. CloudFlare alone revoked millions of certificates. These have indeed not all made it into the CRLsets.
There is still a non-trivial privacy issue with the OCSP checks although OCSP stapling does address that problem. The Chrome situation does leave something to be desired although I can sort of understand where they were coming from from the aspect of it being confusing. It is worth noting that only the setting on the settings page has been removed. You can still enable OCSP checks and OCSP forcing through the enterprise settings[1][2]. Also worth noting is that I believe they have only disabled OCSP checks, OCSP stapling should still work correctly if the server supports it.
> So make them an option and stop taking the Chrome route of stripping out everything that more advanced users use regularly.
Did you really use backspace and "move back" on regular basis? Why? You most likely aren't browsing the web with just your keyboard, so unless you are a leftie it requires you to either move your hand back to keyboard or move your hand across the whole keyboard and why would you do either of these when you can just move back with your mouses thumb button?
As a ThinkPad external keyboard user it's my primary navigation to go Back. TrackPoint, no mouse. Primary scrolling navigation is the Home/End/PgUp/PgDn group. Backspace for Back fits amazingly in this workflow.
Well, maybe it's time to stop using inferior shit products and buy a proper mouse. Any $20 mouse from your local department store has at least one button to press with your thumb.
110% yes. I've been playing Stellaris, and they actually put hotkey references in the tooltip! I can't do everything with the keyboard, but I'm doing way more than I was. Hotkeys are great and we should encourage more tooltips & labels with them. Not just in videogames, but in anything that could benefit from hotkeys.
Stellaris is magnificent! It's incredibly deep and complex, but it has a great user interface, and they've been totally thorough about putting helpful color coded pop-up tooltips everywhere there's something interesting to point at, giving you information about every icon and button, revealing keyboard shortcuts, and telling you one or more tasks that you need to do to first to enable disabled buttons.
I really hate the cargo-cult tradition of disabled menu items that don't tell you anything about why they're disabled, or what you can do to enable them. That's so frustrating, it's like the computer knows something you want to know to do what you want to do, but it won't tell you, because you have to guess.
Even better: Clicking on a disabled item should start a dialog to help you satisfy the prerequisites before performing disabled the action, instead of just ignoring you or telling you to go somewhere else.
I was able to trade alien pets to a highly advanced xenophilic civilization who wouldn't otherwise talk to me, in exchange for civilian access to their space! I felt like Harry Mudd sneaking through Klingon space with a space shuttle full of tribbles!
Apparently a game called M.O.R.E. is lurking around, promising all kinds of crazy depth (I'm super sad how bad SotS 2 was :( )
I totally agree that Stellaris kind of falls flat atm IMO - the foundation is rock solid, the game looks gorgeous and the music just blows you away...but then you play on Hard and literally nothing happens for 6 hours.
Eventually a war happens and instantly degenerates into a massive my-blob-chasing-your-blob-benny-hill-nonsense :/
And you can't even achieve anything because of 100 warscore limit!
Apparently there are serious improvements coming soon though(Allegedly a lot of content wasn't polished enough before the deadline so minimal viable product happened)
I would go out on a limb and stipulate that letting an enemy army free reign behind one's lines is a sure way to get rekt.
It's just in Stellaris it takes a year for anything to happen from bombardment...
It really needs some improvement to wartime movement
Emacs has a nice way of teaching people shortcuts. If you invoke a command via some menu or M-x full-command-name that has a shortcut bound to it, you'll get a message in the minibuffer saying "You can also run full-command-name with: shortcut". It's a very non-invasive way to teach people shortcuts just-in-time.
Huh, that is awesome. As a novice vimpire I'd love to figure out a teaching tool like that for vim. Vim doesn't really have a menu-- but maybe something that recognizes what series of edits you just made and suggests a shortcut?
(I.e. "You just traveled to the end of a line and deleted a ". You could have done 'A[esc]dw' or whatever it is. Like I said, I'm bad at vim over here.)
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.
"Backspace" to go back was new to me, and just sounds like a terrible idea, you'd be accidentally deleting things all the time.
Firefox does not have "Go back" accessible through the menu, although the "Backspace" keystroke works. Chrome also does not have a "Go back" accessible through the menu that I can find. Hovering over the Back button shows how to click to access history.
Does not work for me, FF 38. This feature used to throw me out of forms all the time, there has been a couple of years that it stopped.
Now the only FF keystroke that annoys me is the CTRL-q for closing the window, that conveniently is just by the side of CTRL-w for closing the tab, and does not save the window state.
> Does not work for me, FF 38. This feature used to throw me out of forms all the time, there has been a couple of years that it stopped.
Are you on Linux? Backspace to go back only works on Windows and OS X because this behavior was apparently un-Linux-like. You can change this behavior with the browser.backspace_action about:config pref:
Do any of these options work to get your state back after accidentally closing the browser?(1) Is control-w significantly different than pressing the x on the Window? Just curious.
Weirdly, these commands are in the menus for the Mac version (they're the second and third commands in the History menu), but the versions for Windows and Linux don't seem to have them.
Intrigued by "This is not a solution for the majority of users." - do we really know what percentage was intended? If we're going by anecdotal, then everyone I know fully uses backspace to go backwards, including parents and non-technically minded colleagues. Would have assumed that if you go backwards by accident, the obvious solution is to go forward again, no?
> 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.
If this is true, it's a very convincing argument – I'd buy it for a dollar. In any event, my personal preference is to keep this backspace behavior, and my browser of choice (Safari) implements this caching perfectly.
At this point, not only am I ok with the accidental back navigation, but also I actively rely on things working this way. For instance, here on HN I routinely hit back and forward to see what people wrote, and Safari keeps my drafts perfectly well.
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.
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.
I'm not sure why it'd be hard. "If there's a dom element that's an input of any time, and the user has focused it at any point, ask for confirmation on page exit" would work fine. The only case where I can see it being an issue would be a site that uses a select element as a menu, but I've not seen any do that in years.
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.
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.
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.
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.
> 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.
I don't know how Safari does it, but it works, is incredibly fast, and eats much less memory than Chrome. (My browsing habits suggest Safari is about 30-40% cheaper in terms of memory, but that's anecdata so truck loads of salt required.)
In any event, there are way too many replies to keep count of in this thread, but all I can say is that however Safari does it – it just works(tm). Accidental backspace has literally never been an issue for me since they implemented this. There are convincing arguments why backspace as a short cut is a bad idea to begin with, but old habits die hard, and I for one am very happy that Safari makes this work.
Last night I watched 19 engineers use my application to work collaboratively, in real-time, on a single canvas, to design a transport network for a city. That kind of functionality has never existed before, anywhere, and is a damned sight more important than preserving the idiotic "delete === go back" keybinding that 99% of the population doesn't even know exists and only ever triggers accidentally.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
I'm going to agree with you. Backspace is a totally weird shortcut for navigation and I can't say I've seen it used anywhere else for "get my back to where I was" outside of a browser (it's almost always escape or some function key or other combination).
Alt/Command+Left/Right Arrow has been my go-to for navigation in the browser for years now, especially since "forward" has no other shortcut.
I appreciate when a product group is brave enough to strip away a traditional behavior to accommodate such a common and annoying case. They knew they were gonna catch holy hell for this one from the small but vocal group of people who use keyboards for absolutely everything and opted for a more user friendly behavior. And I fully believe that people don't know what they want until they're shown it, so I rely on data (common error case) over feedback (vocal backspace users).
> the small but vocal group of people who use keyboards for absolutely everything
That's a mischaracterization. After all, for the people who use keyboards for absolutely everything, there are still two keyboard chords for "go back a page".
Completely agreed. This (hitting backspace suddenly changing the page) is the kind of thing that catches older people totally by surprise and makes them think they have no idea what their computer does or why. Long overdue, but: "Thank you, Chrome developers"
> instead it can navigate away from a page entirely, if you are in the wrong state when you press backspace
This happens to me far too frequently. It's all to easy to mis-click with a track pad (another example of bad HMI), and if you defocus a text box suddenly backspace has a very different effect. Good riddance.
I really understand why TotalBiscuit slams games that have dual-bindings. It works against muscle memory.
For example: "F" as an action button as well as to pick up ammo. Ammo full and next to a door with ammo lying on the ground? You might not be able to open the door. The action of the bind changes depending on the context that you are in - exactly like backspace in browsers.
I agree with you. The only thing backspace to go back has ever done is make me accidentally navigate away from pages where I am entering data. It's just not ergonomic for my typical use.
Alt-left arrow is harder to type, but it's also harder to mistype. Plus, it's a web browser, my hand is on the mouse when I'm navigating anyway.
... then the dedicated buttons are the "forward" and "back" keys on the top row.
In 554 comments discussing "power users" and "people who use keyboards for absolutely everything" I think this to be the first mention of the forward and back keys on "multimedia"/"internet" keyboards. Do "power users" not lust after keyboards with lots of keys any more? (-:
Here's one with a telephone, as well as "forward" and "back" keys for WWW browsing:
Real issue with this is that AltGR (which I'd assume most users don't really understand the difference, two Ctrls, two Shifts both do the same thing, why not two keys called Alt?), rotates the display...
Works on mine. Use a Magic Trackpad, I've used it and I'll never go back to a mouse. Force sensitivity and haptic feedback is amazing in programs that support it. Helps against RSI too.
> I'm going to take a somewhat contrarian view and say, "Thank you, Chrome developers."
While I agree with you, the problem is that keyboard shortcuts aren't completely configurable. If they were, the Chrome developers could just tell the whiners to go pound sand and configure it themselves.
The problem is that the Chrome developers don't want to put in the hard work to make keyboard shortcuts properly configurable. They want to take the shortcut of just removing the functionality and everybody to go away.
The problem for Chrome developers is likely priorities. Tough to sell that hard work you do for a small minority when there are likely a lot more pressing tasks to be done.
Conversely, I'm absolutely infuriated by sites that grab my keyboard focus and prevent me from going back with the key. This is extremely surprising because it's going against well established UI paradigms. Backspace as worked on literally every browser and operating system I've used for over a decade.
The middle mouse button paste is one of my favorite Linux features. When I discovered that nuance, I was shocked that Microsoft never included it by default in any of the Windows systems I'd used throughout history. Having access to two separate sections of the clipboard has proven invaluable to me time and time again.
The difference with that feature and the topic at hand is that, should someone in X/Wayland decide to rip it out, there will be a config file I can easily modify to turn "middle_mouse_paste=0" to "middle_mouse_paste=1" and keep a very precious piece of functionality, indefinitely.
>Backspace to go back is a similar surprise. It's supposed to delete text
Spoken like someone who never used a typewriter. Backspace is not an eraser key, it historically does what it says. Takes you back a space. Making it an eraser key is what was "weird...when people were still figuring things out in new UI paradigms."
Having backspace take you back, may be closer to the original function of the key.
I concur with this. I know about the shortcut, but I've never intentionally used it. Instead, it trolls me a lot when I'm typing comments and I lose them when trying to edit something.
Chrome / Chromium have a habit of making these arbitrary changes that seriously annoy some (arguably small) percentage of their users, while claiming that it makes it simpler / better for everyone else, while explaining impatiently why it's infeasible to make the now missing feature a configuration option.
Evidently the kinds of people that can't be bothered going into the Advanced Configuration Settings page would be confused by an additional item in the Advanced Configuration Settings page.
I never used the backspace button for back (though it's probably what's mapped to my mouse button #8 - I'll know on the next upgrade), but I did get mightily annoyed by two changes a while back, and am always happy to bring them up whenever there's a story about Chrom* devs doing this kind of thing.
1. snap-to-mouse - while dragging the scrollbar, if you move the mouse further than ~80 pixels away from the scrollbar column, the page jumps back to the original location - apparently MS Windows users love this feature, but chrome/chromium is the only application I've found on GNU/Linux that does this, and
2. clicking inside the URL bar selects the whole contents - apparently MS Windows users are used to this feature, but chrome/chromium is the only application I've found on GNU/Linux that does this.
No idea what the defaults are for OSX, and, really, it doesn't matter - these features should be sensitive to extant defaults on whatever desktop environment the browser finds itself running on.
The problem with configuration options is that they need maintaining indefinitely to accommodate a small proportion of the user population. That means testing behaviour with the flag on/off, and taking into account the possibility of that flag being on when dealing with bug reports.
In this case it's a minor thing which probably wouldn't require much maintainance, but you have to draw the line somewhere.
This. Configuration flags increase complexity. Every time you change the feature in question (or add something that uses it) you will have to take into account every possible flag combination.
That's not true. It's like whenever you change a line of code you need to take into account every other line of code in the project.
If option for backspace behaviour suddenly starts interfering with some unrelated feature, it means somebody seriously fucked up the architecture of the project. Nothing else. Configuration flags aren't scary, and should not be used as a rationalization for dumbing down software.
Agreed. Especially in a case like this where it's actually pretty trivial to write an extension for this behavior. This change decreases the maintenance of chromium, removes a non-obvious data-destroying keyboard shortcut, and still gives users the option of bringing the feature back if they want it.
It's inconceivable that this should require any maintenance. I don't need a "backspace key goes back" checkbox, I just need to be able to customize the keyboard bindings. Decoupling the actions a program can perform from the key combinations which trigger those actions is basic stuff.
From the maintainer's point-of-view, having the option to bind "backspace" to "window.history.back" shouldn't require any more maintenance than having the option to bind "alt-left" to "window.history.back" does.
It is Google's fault that they didn't make Chrome work this way. It also means I can't unbind "ctrl-shift-q" from "quit_immediately_without_asking", because Google refuse to add an option to make it so that I can't accidentally fat-finger a C-w into something that ends my entire session. All keyboard shortcut problems disappear instantly if key bindings are configurable, however, without adding new options for each command.
In most cases that makes complete sense... but this behavior has been around so long. Adding a configuration option means they can track data on if this feature is being used and worth continuing to support.
That said, I'm glad they finally did something to fix this bad UX design.
>Adding a configuration option means they can track data on if this feature is being used and worth continuing to support
leaving it enabled also allows them to do this, which they have done for the last couple years and clearly their data says that it's not worth supporting, because now they're dropping it.
Reminds me of the "flaw of averages" article [1] that was posted here a few month back. This seems like a general attitude in Google products features development, they try to find the simplest set of features that will please the most users, but that set probably doesn't exist, each user needs their own tweaks, and in the end their product becomes less useful for everyone.
That page is not readable in Germany:
ERROR.
The request could not be satisfied.
The Amazon CloudFront distribution is configured to block access from your country.
Any idea what could block it? Never seen this before...
I'm primarily on Windows and that first feature annoys the heck out of me. I would rather scrolling stop or continue, but the snap-back when the mouse leaves a zone is irritating.
I think the second is more of an optimization because when you click on the address bar you're most likely either copying or overwriting the URL. It's much less common to modify it.
If you want a supremely annoying address bar, you should check out Windows File Explorer from Vista/7 onward. Each component of the URI is a drop down menu item and only by clicking on whitespace to the far right can you get to the actual URI.
The file explorer address bar was one of the best features that were introduced in Vista IMO.
If you're in folder "C:\foo\bar\baz\boz\" and want to go to "C:\foo\" it's just one mouse click. Or if you want to go to "C:\foo\bor" that's just two mouse clicks. Much faster than clicking "back" or "up" multiple times.
Well, to be fair if you have the much older tree view enabled on the left side of the explorer, it's only one click to go to C:\foo\bor.
I agree with parent, the adress bar should be the adress bar. Also better for sans-mouse-use. Just F6 and end, ctrl+shift+left arrow until you get to before "bar" and then backspace, enter.
Sure, it's more input but it's still way faster than reaching for your mouse.
(old guy here) I'll never understand why the left-pane tree view isn't the default. Not having it follow the current directory makes it a waste of screen real estate.
>if you have the much older tree view enabled on the left side of the explorer, it's only one click to go to C:\foo\bor
No, it's unpredictable amount of clicks, drags and scrolls to unpredictable places, if C:\foo\bor is not immediately visible in the tree view. And worse, if there is "bor" in every one of 100 "foos" you have on C:.
To add to this, I believe in Windows 10 (possibly 8?) you can actually move files to a grandparent folder by dragging it to the associated button in the breadcrumb bar.
Going from memory since I couldn't reproduce this behavior in 7. Could also be wrong about 10; someone else should try it and confirm.
> If you want a supremely annoying address bar, you should check out Windows File Explorer from Vista/7 onward. Each component of the URI is a drop down menu item and only by clicking on whitespace to the far right can you get to the actual URI.
Actually, I’m one of the people who like that so much, I enabled it even in KDE Dolphin.
EDIT: Due to submission restrictions, I can’t answer right now – I’ll have to wait about an hour before I can answer comments, sorry.
How do you use it? I understand how it works but I see no advantage to it over the tree view. I always enable the "expand to location" option so that my tree view is exactly where I am.
To me that address bar abomination is just an obfuscation of otherwise useful information with large clickable regions of functionality I don't want.
I think you are in the minority here. For most people, navigating from one folder to another is not "functionality I don't want" in a desktop folder browser, but is the main thing you want to do. I'd much rather have UI that lets me navigate efficiently than that makes it efficient to copy-and-paste arbitrary substrings within a folder path. I do the former almost every time I use the file browser and the latter basically never.
My main computer is a Mac and I very much wish its "Finder" had navigation tools as nice as the "breadcrumb bar" you are describing in Windows.
>My main computer is a Mac and I very much wish its "Finder" had navigation tools as nice as the "breadcrumb bar" you are describing in Windows.
It's not completely the same as on Windows, but:
- Shift-Apple-G lets you enter a directory path to open (including bash-like completion with tab).
- Option-Apple-P shows/hides the "path bar" at the lower edge of a window where the hierarchy of the current folder is displayed (including a spartan context menu).
On Windows I mainly use the explorer address bar to go to those hidden folders like ProgramData.
Thanks for the right-click on title tip... doesn't seem to have a show breadcrumbs option that I can find... still in yosimite on my work laptop though.
> How do you use it? I understand how it works but I see no advantage to it over the tree view. I always enable the "expand to location" option so that my tree view is exactly where I am.
Well, the tree view in dolphin is small, and mostly hidden by the bookmark menu.
So I have to resort to using the breadcrumbs as a poor (wo-)mans tree view.
>If you want a supremely annoying address bar, you should check out Windows File Explorer from Vista/7 onward. Each component of the URI is a drop down menu item and only by clicking on whitespace to the far right can you get to the actual URI.
You can also right click the bar to edit or copy the URI...
I have to use Windows 7 periodically, and it annoys the heck out of me too, given the feature applies to every application on that platform.
It's the fact it's inconsistent on my platform (KDE on Debian GNU/Linux) exacerbates the annoyance. I should not have to consider which application I'm in, in order to preempt the way the scrollbar / mouse will work.
With the second - I appreciate that for many people, for much of the time, you're wanting to type something else into the address bar. However, on MS Windows you have to type ctrl-c / ctrl-v to copy / paste. On real operating systems <tm> you just have to select the region -- so having a whole line selected for you when you click near it is unwanted.
But ultimately it's the inconsistency. I need to consider if I'm clicking in the address bar, or another text box, in order to predict what's about to be selected.
And, yes, the Win7 explorer bar has moved me to tears also. I can highly recommend the breadcrumbkiller [1] - even if you don't install it, the rant on that guy's page is well worth reading.
I believe the name of the feature is called "breadcrumbs" and i also dont like it very much, as one poster stated it is nice to go up several levels without making many clicks but i prefer to see the entire URI and be able to modify it as oppose to breadcrumb "directory buttons"
Which doesn't help in the most common case (for me): editing down a URL that's way too long on sites that love to jam absolutely everything they can think of into a query string, extending the URL many screen widths out to the right.
Nope, they actually thought about that. When you click on the url box the selection isn't replaced. So you can totally select an URL elsewhere, click on URL bar, press backspace to clear the bar, and middle-click-paste the selection.
On the other hand selecting the text in the URL bar in any other way (with mouse drag, triple click, or keyboard) will update the selection.
This does mean that copying the whole URL is a pain - click to highlight the whole thing, then click a bunch more times until the whole thing is highlighted again.
(Unless I'm mistaken, the right-click copy uses a different clipboard, so you can't use that.)
Yeah I can see how that would be annoying. I'm so rarely in X that I don't always appreciate some of the features it offers. Scrolling the window under the cursor though is one I always hope will find it's way into Windows.
> I would rather scrolling stop or continue, but the snap-back when the mouse leaves a zone is irritating.
I liked it (back when it existed on Mac OS X): By moving the mouse horizontally to the vertical scroll bar I could instantly return to where I started scrolling. Use case: Read something (web page, source code...), scroll around to look for related information, then return back to the exact position I was before.
> Each component of the URI is a drop down menu item and only by clicking on whitespace to the far right can you get to the actual URI.
And you also have the confusing "copy address" / "copy address as text" context menu.
There are programs like DisplayFusion which take care of scrolling in non-focused windows. I highly recommend it, although it is paid after a while. There must be other tools out there that can do it!
I use the first feature constantly. If I'm reading reddit comments at the bottom of the page, I can scroll to the top and a part of the original post and then snap back to where I was. I think Chrome actually removed this for a day or two and it really annoyed me.
The backspace thing has gotten attention more than ever on sites like Reddit. I have routinely seen posts complaining about it and the spacebar key doing behaviors that users never ever intended. For example, pressing space and then accidentally scrolling down which wasn't their intention at all, but is the behavior of space.
I think some of those complaints reaching the front page of reddit may have helped spur this into action by the Chrome team.
I'm gonna be majorly pissed if they disable space bar scroll. I use that quite literally constantly while I'm browsing. It is the scrolling method I use 99% of the time.
Backspace to go back, OTOH, I was aware of, but I doubt I ever wanted. Alt-Left is easier to use because it's less modal. Still bothers me in general when devs screw with established defaults.
The most confusing thing is that Youtube and Netflix seem to occasionally toggle pause when you press space; other times Youtube scrolls, and Netflix does nothing (there'd be nowhere to scroll).
I've never managed to consistently replicate it by having had the player in/out of focus already, not/scrolled, etc. odd.
Chrome is lately behaving even more unpredictably when scrolling with the spacebar, because now if you click on either the back or forward buttons it puts a focus rectangle on them and now pressing space will go back/forward again instead of scrolling down like I wanted.
Right hand on mouse, left hand on WASD. The spacebar is always easy to hit your thumb, but you have to move your right hand away the mouse to hit Page Down. Plus it mixes well with Vimperator-like extensions, to the point that I can do 90% of my browsing with one hand.
EDIT: and before anyone points out that if I'm already using extensions I could easily add another, yes and I would if I had to, but it's not ideal, because 1. Extensions crash, fail to load, or aren't allowed by internal browser pages, and 2. You sometimes have to use other peoples' machines and it's annoying when basic functionality is locked away.
All keyboards have a spacebar. Not all keyboards today have dedicated page up/page down keys. So potentially more keystrokes due to the function layer.
Spacebar scroll is standard on many Unix utilities, starting with pagers such as less and more. Given that paging down a screen of text is very likely to be one of the most common things you'll do, and that it's a well-established motif, as well as the fact it doesn't destroy user-state (as back-nav on backspace does), it's quite defensible.
I've never actually seen someone complain about it until now.
People complain about it all the time on anything having to do with video playing, because when the video player has focus space is used to play/pause the video, but when the player is not focused, it scrolls down the page.
Frankly, I would be perfectly happy if space to page went away entirely. I exclusively use two finger dragging on laptops and scroll wheels on desktops to browse websites. I never use space to move down a whole page at a time, and that's a jarring action anyway because it inevitably causes me to lose the context of where I was reading in the document in a way that smooth scrolling accomplished through other means does not.
Most of my desktop use is on a Thinkpad laptop with no mouse and the trackpad disabled.
I don't have a scroll wheel or a touch screen.
The gaming instance is a failure of Web controls to adequately adapt to context. I can see how that would be distracting. I am not willing to sacrifice my space-to-scroll capabilities on that account.
As with Fitts' law, the spacebar is a very large target. Easy to hit. Frequent action. Well-placed use.
You do raise one other point: scrolling tends to make re-aquiring reading point difficult. That's a fair gripe and one that annoys me.
I'm particularly sensitive to it in DuckDuckGo, which smooth-scrolls a pre-set amount in the SERP when scrolling (I forget if by up/down, pgup/pgdwn, space, or other). I absolutely cannot figure out where I was and where I want to be, and have reported this multiple times.
For long-form text, I've taken a strong preferene, in portrait display devices (my tablet when reading) to fully paginated text, and a page flip mode. Much as PDF is an abysmal format in many ways, I find the capability to retain a spatial memory of where content is on a book or in a page is useful, and generally prefer this to smooth-scrolling.
Pocket, which offers a page-flip mode, makes it both brittle and of limited utility. Any up-down motion whilst flipping a page "breaks" page-flip mode and returns to scroll.
Page-flip doesn't clearly indicate location within the work as a whole (Pocket also mutes the scrollbar indicator generally).
And lastly, the pages aren't consistently presented -- effectivly Pocket repaginates a document whenever and wherever you enter into Page Flip mode. I'd prefer it had a sense of what the pagination breaks were for a given viewport size and font selection, and stuck to that.
> Most of my desktop use is on a Thinkpad laptop with no mouse and the trackpad disabled.
> I don't have a scroll wheel or a touch screen.
I use the middle button + trackpoint for scrolling - works great. That's the default on most Linux distros/desktop environments, might require some configuration on Windows.
I don't think that's particularly applicable here. I doubt that any touch typist has problems finding the vast majority of the keys on their keyboard (or mouse). Also, how often do you hit space while reading an article anyway, a couple of times per minutes? It's nowhere near being time-sensitive. Even if it somehow took you ten seconds to find it each time before you hit it, your finger would have found it and be settled on it by the time you reached the bottom of the page and were ready to go onto the next.
But the middle track point button is just the right distance. When I relax my hand muscles and place it on the keyboard so that the tip of the index finger is on the track point, the thumb is on the track point buttons. Perfect distance. Using the space bar would be uncomfortable.
I use space-to-scroll very frequently when reading long passages of text. I consider it a valuable shortcut.
I don't find it jarring at all to read that way, because I know where to resume reading after hitting space. There is one exception: a lot of websites with absolutely-positioned headers scroll incorrectly when you hit space, such that the point you would resume reading at ends up behind the header, and you have to scroll up a bit to reveal it.
A few websites with headers get it right, and your resume point is below the header after hitting space. This makes me much less sympathetic to the websites that screw it up.
That header issue is especially jarring to me too, and it's one of the reasons I don't use space to page, because it doesn't work consistently everywhere. Two-finger dragging always works, as does scroll wheel.
I do use paginated reading on my Kindle, which always gets it right. It doesn't quite work properly on the web often enough though.
Do you think it actually makes sense to keep the backspace as "page-back"? It's literally lost me dozens of form entries over the years (some of which were very hard to restore).
Thankfully on OSX/Safari, this legacy behavior/cruft is not present.
Seems like change for change sake, like so many of Google changes.
Unilaterally changing 20 year behaviour that effects less than half one percent of users isn't an improvement it's rearranging chairs on the titanic.
Also, Lazarus is an old plugin for Firefox that saves forms between sessions/refreshes. Too bad goog want to capture new users at any expense. If it doesn't work because the latest hotness is js forms that's a problem with webdevs.
Do you really feel like the majority of PC users want backspace to navigate in a web browser? I seriously doubt the majority have ever intentionally used that shortcut. It wouldn't even surprise me if it were more often used unintentionally than intentionally.
Most users don't want shit. They take what is given to them and learn to use it. Which means every feature you remove from your software is one less thing your users can do now. Good if you're lazy, but the point of software should be to empower people to do more.
Yep, their power-user-ness or the fact that they frequent a particular enthusiast forum does not make them any less of a minority when the software we're talking about is used by many millions of people (the silent majority).
> No idea what the defaults are for OSX, and, really, it doesn't matter - these features should be sensitive to extant defaults on whatever desktop environment the browser finds itself running on.
I think there's an argument to be made in either direction.
I use Chrome (and other apps like Sublime) on three different platforms and would much prefer to have commonality on the application level. Since it's a big part of my workflow, having it work differently from OS to OS would definitely slow me down.
The problem, I think, comes down to this -- more people use lots of different applications on one platform, than the same application on multiple platforms.
If you're going to use one application only, on multiple platforms, then I could see how a consistency in the way that application behaved would be useful. But I can't see how anyone's workflow wouldn't involve interacting with some number of other applications on each of those platforms.
At that point you could assert all applications on all platforms behave consistently. This is not likely to be a well-received suggestion. Or you could try to make all applications on a particular platform behave consistently. The latter seems to align with people's UI expectations, and, for the most part, is what we have out there now. The pain point is where expected behaviour from one platform bleeds into applications running on different platform where that behaviour might best be described as 'surprising'.
It really should be an option. Like how Sublime lets you pick between DOS and Unix style line breaks. Because that's how you handle cross platform discrepancies.
> clicking inside the URL bar selects the whole contents
This is one of the annoyances on Windows. On Linux/OSX you can click and drag on the URL to select a portion of the string, but on Windows it auto-highlights the full string completely, forcing one to reclick again (slowly!) to highlight a portion.
Also: right-clicking on a link in Linux/OSX auto-highlights the full link text so you can `Copy` or `Search on Google` the highlighted text. In Windows you must manually highlight the link, then right-click on it.
> On Linux/OSX you can click and drag on the URL to select a portion of the string
Works fine on Windows. Just don't click into the address bar before dragging and everything works as you'd expect. With clicking first you have a selection, though, and dragging that will do drag & drop of text instead.
Speaking of annoying things Google has done lately, they recently updated Android's Google Keyboard completely changing the layout, keysize and removing most of the secondary (press and hold for more characters) keys. It has become almost impossible to type with it but I haven't found another keyboard with a good theme, haptic feedback and good suggestions. I miss the days Google used to cater to power users.
If you press and hold on the comma key and go into languages, enabling languages such as French or Spanish will bring back the ability to press and hold for diacritical marks. As for your complaint about key size, I wouldn't know because I use swipe typing exclusively and have found the update a significant improvement. I also really appreciate the new gestures for deleting multiple words by swiping left on backspace and for moving the cursor by swiping on the space-bar.
You don't even need to do that much, if you just enable the "Long press for symbols" option in the preferences you get back the all of the previous behavior of long-pressing letters.
The long press is still there, it's just disabled by default. You can change it in the settings. You can also change the layout in settings, although I don't know specifically what changed there that you dislike.
It's not free to add a configuration of this class to the advanced configurations; items in that list must be tested, maintained in future versions, etc.
The kind of people who are willing to go to the Advanced Configuration Settings page are also willing to tweak their keyboard mappings to map any modifier key they want to to the "go back in history" accelerator for Chrome.
My defence here is that the test matrix for the way it worked already existed.
And the change would have included some unit tests.
Further, neither the way it worked, or was changed to work, is an especially complex mechanism.
Developer explanations in the bug reports for both were not 'this is going to be hard to maintain', but instead were 'having this configurable will confuse users'.
It wouldn't surprise me if the defaults on OS X are the same. #2 in particular, I consider that to be sensible autofocus behavior. If you don't want to replace the URL but instead modify it, just hit an arrow key. Partly this is because there are shortcuts to select the address bar to begin with, so I rarely use a mouse. It's generally consistent on mobile platforms too, to select the entire URL. You have to hold your finger a second time to position the cursor because the most common interaction with the URL bar usually means jumping somewhere entirely different.
Edit: they could maintain a flag to change these behaviours though, if they were a concern. You could also build your own copy of the browser, patched as you wish... ;-)
>It wouldn't surprise me if the defaults on OS X are the same. #2 in particular
It used to be different, but that behavior unfortunately has made it to default in OS X now. It annoys me to no small extend, since I very frequently want to edit URL's to remove session ID's or reference tokens. Of course, the average user is to daft to double-click...
Add mandatory auto-fill in the omnibar to the list of grievances.
If you do a search for "JavaScript" and then later perform a search for Java by typing "Java[Enter]", it will do a search for "JavaScript" instead, possibly before you have time to react. To prevent this, you have to stop before pressing [Enter] for each search to make sure it doesn't auto-fill, then press backspace if it did.
This feature cannot be turned off, and the faster you are at typing, the more aggravating it is.
In Chrome, obscure configuration options are called "extensions". Instead of searching for them in "advanced settings", you search for them in the extension gallery. The great thing about extensions is that anyone can write them, so you aren't limited by whatever the Chrome team decides to provide.
>while explaining impatiently why it's infeasible to make the now missing feature a configuration option.
There's been a general trend in computing for a while now to not have any kind of configurability. You can see it in most of the major UIs now. And from what I've read on tech discussion forums, techies themselves absolutely hate configurability: they complain that they don't want to have to slog through a bunch of configuration options for everything, they want things to be set up to their preference out-of-the-box.
- For fear of annoying anyone, keep adding without ever removing, increase the number of settings, in other words bloat. Until a new, "lighter" alternative products comes and everyone moves out from your bloated product
So yes, by removing features that they realized weren't good one, they're keeping the product simple.
At one point I forked Chromium over the click-selects-all in the URL bar. In OS X, this was the only application that behaved that way (until Apple recently followed suit with Safari...). Now I just use FireFox because they give me the option to override the default. I edit URLs far more often than typing in new ones. If I am going to a new URL, I generally type command-l or open a new tab...
The point of highlighting the URL with a single click isn't just to replace it with something else, but to copy it fast, and all kinds of users, including true power users, copy URLs much more often than edit them.
2. is a lot like Outlook (at least on Mac), oh you highlighted something, I'll just go a head and assume that that's the only part of the original email you'll want quotes in the reply... WHY?
If I wanted the entire URL highlighted I could just double click on it like in every single other piece of software.
It's infuriating trying to highlight anything in Outlook. Oh, you're dragging to select part of a word, or a huge long URI? Let me go ahead and automatically expand your selection to cover the entire token, with the trailing whitespace. Haha, you're trying to circumvent my helpfulness by setting the cursor and shift-right-arrowing? Haha, no soup for you! Break down and copy it into notepad instead!
Disable 'smart paragraph selection' and 'automatically select entire word' in the edit options. I turn these off instantly in Word every time I have to reinstall them.
Lots of systems email users an initial password which must be changed at first login. It's not the world's most elegant solution, but it's also not terrible and basically does an implicit email verification. I'm not sure that it's any worse than sending a URL with an embedded token that takes the user to a password-change page.
iOS is also staggeringly bad at this. Often you highlight part of a webpage and it decides you wanted from the top to that point, which is stupid. Like one paragraph in a reddit comment or wikipedia -> the whole page, menu and all.
I was going to see if it happened here but I can't highlight any of your comment while typing mine.. I can only highlight inside this text box. Good job I don't want to quote anything.
I've never heard of #1 and nor do I see it in any other app (Win 10)
and for #2 I think that is how it is done on osx as well. I believe that a majority of google works off of macs so its likely that most of the chrome devs are on macs.
Re #2: my brother once released a fork of chromium where the only change was fixing the stupid "select the whole url bar on single click". People feel really strongly about certain features.
This was done deliberately after lots of user uproar - it used to auto select the contents of the URL bar AND set the primary selection. This meant that anytime you did anything with the URL bar, it would wipe your primary selection, which was pretty annoying.
What Linux users wanted was for it to behave normally - i.e. not auto select, but set primary selection if you selected something in the URL. The auto select was apparently non-negotiable, so we ended up with the current compromise.
It does set the primary selection if you manually select some/all of the URL though.
I might be the minority here, but I think that using the backspace to go back is counter intuitive. In my mind backspace is to delete something, and I always worry about that.
This is great news. For some use cases, backspace-as-back is a disaster waiting to happen, for example, in a complex web app used in some time-critical task and that requires occasional deleting of text but can lose state or take a while to reload if you accidentally hit back. If you hit backspace without having a text field focused, the whole thing dies and needs to be reloaded and possibly checked to make sure it's still working right, while hundreds of people are anxiously watching and waiting. I have seen laptops with the backspace key physically ripped out just to prevent people from accidentally triggering its back-button behavior.
Giant web forms have been a usability disaster since day one. Accidental back button, link click, window close, session timeout, etc, increase the chance of a failure and need to re-enter the entire form. Whereas for at least 40 years desktop software has given you a "sure you don't want to save?" option.
I've lost HN comment data 10-15 minutes into a reply by using a laptop with an overly sensitive touchpad. Multiple times. Not something I particularly enjoy, and that's just a single input field.
Plain old web forms are actually not so bad these days, since browsers are pretty good about keeping any entered text around if you accidentally hit the back button (or even if the browser or computer crashes). It's really the big fancy web apps with lots of stateful javascript that are a problem, since the URL doesn't necessarily describe the state of the page and the form fields the browser tried to preserve may not even exist anymore.
In the specific case I'm talking about, it was a big (and rather buggy) pile of stateful javascript, and whose failure would leave a crowd of angry sports fans and player waiting for it to start working again before the game could continue. In retrospect, not using in the the first place would probably have been the better option, but ripping out the backspace keys seemed like a reasonable compromise at the time.
Yep, delete button or else just use the default behavior of highlighting the full contents of the field to be changed. Mind you, these were dedicated machines that were specifically used for this one purpose and not something anyone would be using for, say, writing emails.
It's an edge case, but we recently asked for this 'feature' to be removed from a framework we use because the app opens programs in the browser and does not modify the URl, so backspace took the user to the last URl in history, which was the login page. In other words, while the user was in the middle of some complex task, backspace logged them out and ended the session.
Glad to see it removed, alt+arrow-left/right still exist so the keyboard can still be used.
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).
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.
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.
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.
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.
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.
Backspace to navigate is bloody hell. I don't know how much work I have lost because all I wanted was to remove a couple of characters. ALT-left arrow!
We're creatures of habit. In this case it's a behaviour that existed for two decades or so. Sure, it doesn't make much sense, but the same goes for various functions of the middle mouse button, depending on context: open new tab, close tab, open new application, close window, scroll, paste. Yet you don't see anyone changing those.
Incidentally, Esc used to stop GIFs on a web page. Doesn't seem to do that (anymore?) in Chrome. (Oh, or Firefox, or Edge. IE is the only browser that still does that.)
IIRC there was some tedious justification for firefox about this being 'more correct' since escape would close websocket connections and pause javascripts and other fancy modern cruft sites rely on.
There's an extension (SuperStop I believe?) that partly restores it if you shift-esc, but recently I've found that invasive keybindings in pages (Slack, I think?) can intercept this and stop it working.
I'd really like a whitelist somewhere of what keys/combos I'd like the page to be able to catch, vs those which I expect and rely on to perform native functions, and which shouldn't be hookable (Github trying to cleverly intercept '/' and take you to the search field would be great, if / wasn't already a shortcut for searching the page, etc.
The ridiculous thing here is that it's perfectly possible to make Esc stop animation without also stopping network connections. It's literally just a different argument to the stop function, and you can configure it just fine in BetterStop. But Mozilla couldn't care less, of course.
Haha. I'm an avid vim user and I don't get backspace. The normal key to move back by character is in the home-row. Why would I use backspace instead? Am I missing something?
Huh? In insert mode, the backspace does what it does in all editors. We're referring to the behavior in normal mode, where backspace is equivalent (I think?) to 'h', or left arrow in most editors.
Good. I always set browser.backspace_action to do nothing in Firefox, because this is SO infuriating. You think you have a text field focused but you actually don't (e.g. accidental mouse click removed the focus), you press Backspace and BOOM! suddenly you're on the previous page.
Because the guys who made Mosiac had no idea what they were doing because everything was so new. At first there was this idea that you'd constantly be going back and forth between pages, similarly to how people used gopher back then. You'd always have your hands on the arrow keys and you'd fly past various pages to find what you wanted. But, of course, terminals didn't really have scrolling, but GUI windows do, so html pages were just written longer and longer and we got used to scrolling down instead of moving between pages.
Recently, Andreeson said that he never expected the forward and back buttons to last this long. He assumed they were temporary measures until something better came along. Nothing ever did it seems.
Worse, I tried MS's Edge browser and found that the spacebar is now a back button. I am completely baffled by this. I am so used to the space bar as a scroll down, I can't think what misappropriation of ideas and user testing must be going on at MS right now to make this change. Its truly bizarre and really killed my faith in MS finally getting browsers right.
Yes, and for what it's worth, I feel Space to page down is another oddball one. I guess it's for the supremely lazy who don't want to have to move their finger to the Page-Down key.
Call me supremely lazy, but I use the spacebar all the time (Thinkpad), since my thumb already rests on it and it's so big that I can't miss it. I even prefer it over scrolling.
Page-Down means I have to almost move my hand away from the keyboard (middle finger to the top right corner, can't hit it with other fingers because display) -- that feels like grabbing for the mouse...
The laptop I'm using doesn't have a page-down key. I have to contort my hand to press two buttons to hit page down. I can feel the difference in my wrists. It's not laziness, I'm avoiding RSI.
Right hand on mouse, left hand on home row... moving either hand to hit the pgdwn key requires an arm movement from the shoulder. Whereas space is already under my thumb, and if I'm not in a form field, has no other use anyway.
Historically, space is also the hotkey for 'more'.
But at least when you are entering text but mistakenly don't have focus on the text box, you can just scroll back up. Where with backspace, sorry bud... gotta enter all that text again.
Thank you so much for reminding me of CMD+[ and CMD+]. I use backspace to navigate all the time and was initially really annoyed, but I remember learning that habit, and this is a usable alternative that I will learn in time as well. To boot, I don't think I ever used a shortcut to navigate forward, and now I have a new shiny.
We're humans, people, we can intentionally learn new things.
Thanks for saving me a hunt to find the about:config option.
Worst thing in a demo/presentation to accidentally lose all your inputs and are forced to retype while a) people are watching and b) you might also be recorded.
I'm quite the opposite opinion and use Backspace to go back extensively, because it means that I can browse the web with one hand on my laptop with trackpoint.
If you're accidently clicking on things, maybe learn to use a mouse better.
P.S.: Oh and if it's a crappy touchpad making unwanted inputs, then I share your concern (and probably a good time to look at other laptop keyboards; turning off the touchpad on this Lenovo was among the first things I did). But still, they really should make this an option...
> If you're accidently clicking on things, maybe learn to use a mouse better.
Oh, give me a freaking break. You never accidentally click the wrong things? And you never visit a page that "helpfully" plays around with the default focus behavior?
Not with proper input devices (as said, I wouldn't count a regular touchpad as such, given that it's often unsuitably placed/configured) and well, focus is a really crucial UI abstraction, so I automatically pay double attention before I use the keyboard.
In the end I find this Chrom(e|ium) change to be the wrong solution to a questionable problem and a regression (a proper fix would introduce fully/mostly rebindable keys).
That's an ergonomic nightmare. The right-click->Back approach works too, but some sites like to mess with that and I must watch out to not click the wrong element, so backspace is still my go-to choice.
"Building an extension for this should be very simple."
Why on earth isn't there just a generic keyboard-shortcut preference where I can control every possible browser action and its associated keyboard shortcut? In fact, why isn't this available at an OS level? Surely it would remove a lot of unnecessary duplicate code.
They really don't like preferences. I remember before Chrome's new preferences page it seemed to have many more options. I called them out on a few important ones disappearing and the answer was always "Not many people use those, and they confuse new users".
For a long while it was impossible to view TLS cert information on Chrome Mobile. One day they just disabled the UI for it. Too confusing for new users if they stumble in there.
Same thing with Firefox. It's really frustrating. The options are incredibly sparse. I feel like there is a complete lack of creativity on the part of browser developers are to features that it'd be nice to have
Chrome has chrome:flags but it's not as useful (mostly about turning ON new experimental features than restoring established behaviour). And with both cases, you can't rely on it being there at the next mi or update..
Ah, yes. On OS X, Ctrl+Q and Ctrl+W (well, their CMD equivalents) are system-wide and it drives me crazy if I hit Ctrl+Q by accident, or that devs prompt to quit because of how easy it is to accidentally press it instead of W. I'm so glad that tabs and state reload in pretty much every app I use these days...
A while back while looking for solution to this, someone told me a way to map splat-Q to "invert video," which is a great way of training yourself out of hittig splat-Q.
Neither Windows nor Android have a (generally-used) concept of quitting an entire application at the user interface level. You can force-quit a process, but that's a rarely-used feature intended primarily for debugging purposes (and accessible through a side-channel; Process Explorer for Windows, app settings for Android). Some applications implement such a concept, but they're generally "single-window" apps, where closing their sole view is equivalent to closing the entire app (games usually fit this category).
Nowadays, you can generally trust your OS to page an app in and out and devote no resources to it if the resources aren't needed. Quitting an app is for misbehaving apps, which isn't assumed to be the common case.
That's the thing... from an architecture level, a modern Mac can already handle this. The fact that an app can have zero windows open (or minimized) but can be brought to foreground to interact with an app-level menubar attached to no window can be thought of as a bit of an anti-feature, depending one one's point of view.
For my work laptop, the same ~6–8 apps are always running. No need to quit anything ever.
At home, where I do a wider variety of things (coding, photography, video stuff) I do quit apps, but there's still a baseline of ~2–3 apps (Chrome + Music + one more) that are always running, which I would guess is pretty typical for most users.
In Dvorak, CMD-T and CMD-W (K and ',' in QWERTY) are a nice middle-finger curl pair on the right hand. Far away from Q. Easily paired with a right-thumb press of CMD. Strange to remember that two of my easily most-pressed keyboard shortcuts are in different (and I'd say worse!) positions for the vast majority of people.
"Why on earth isn't there just a generic keyboard-shortcut preference where I can control every possible browser action and its associated keyboard shortcut? In fact, why isn't this available at an OS level?"
There is one, on KDE level. Any KDE app has generic-looking hotkey remapper under settings menu. It just works.
> "Building an extension for this should be very simple."
Which is then followed, amusingly, by a developer who has tried to do it saying that in fact, it's not that simple (without ridiculous permissions).
But now it seems to have turned into a face-saving thing where the Chrome developers won't ever reverse the change or put in a configuration option because to do so would be to admit a mistake in public.
Yeah, it is an OS level thing on OSX. "Quit Chrome" mapped to cmd-shift-control-something-Q instead, for example. As long as it has a menu item to match on.
Of course it does. For some reason, I always forget about this - maybe it's because it doesn't work in the most-intuitive way (hunt down system prefs pane, enter menu text exactly as it appears), but it's good to know they're trying to make this work. Unfortunately, backspace is one of the keys that can't be used as a shortcut.
> Why on earth isn't there just a generic keyboard-shortcut preference where I can control every possible browser action and its associated keyboard shortcut?
It turns out this extension does exist. I just used it to assign "shift+backspace" to "Go Back" and it worked.
It is chrome team we are talking about. They are the only browser that nukes all of your settings when it thinks they are tampered with and it is impossible to move profile between installations just with copying. And there is no way to disable that :( They force you to use their (useless) cloud sync.
"We have UseCounters showing that 0.04% of page views navigate back via the backspace button and 0.005% of page views are after a form interaction. The latter are often cases where the user loses data. Years of user complaints have been enough that we think it's the right choice to change this given the degree of pain users feel by losing their data and because every platform has another keyboard combination that navigates back."
Personally I am shocked that the Chromium team ignored years of user complaints before they decided to fix what their own usability studies found to be a worthless yet painful gimmick.
I'm shocked they reacted to the complaints at all. Chrome is infamous for painful UX blunders that Google refuses to acknowledge, let alone fix. Mouse thumb buttons are permanently bound to forward and back, the only workaround is to use your mouse's driver or a third-party input mapper to bind them to something else. The Android version cannot re-order tabs (or use extensions. Seriously.) The Google product forums are a sad wasteland of people with simple problems shouting into the void. Here's a thread from 2010:
These advanced power users want the unfathomable ability to install Chrome in a different directory. The only solution involves downloading the Windows "Junction" utility and creating a symbolic link. Surprisingly, an actual employee (uh, "Googler," whatever that means) deigns to appear, but only to inform everyone that there is no solution except to download Chrome from Google Pack. The Pack version won't let you pick a location either, but its default is different, or at least it was until Google Pack was discontinued.
You know what, I think I'm just going to see how Firefox has been doing. I can't even remember why I switched.
Firefox on Android. Been using it for a few days with uBlock origin and it seems quite worthwhile.
In general I've found that FF have been proactively fixing their perf, memory and usability stories. With exception to the rare occurrence such as this, Chrome has been on a steady decline.
It's a tradeoff. There are already keyboard shortcuts for 'previous page' and there will be extension support to re-add 'backspace as previous page', it just won't be on by default.
If you were a drugstore and had a drug that was functionally identical to aspirin but caused day-long projectile vomiting in 99.96% of people who took it, would you think it was a great idea to hide the aspirin in the back and give the drug that is almost guaranteed to cause harm to someone as the default?
IE compatibility across platforms is why most if not all browsers behave this way. And even then, it probably started with Netscape or actually it probably pre-dates the graphical web, I think Lynx uses it to go back. I remember being frustrated by this "feature" as late as 1997 on dialup.
Though I am a frequent user of backspace in Chrome I'm inclined to agree with their decision. Almost no one is using it and casual users are confused by it.
I'll just wait for someone to implement the feature in an extension.
Wait someone to implement it then extract source or implement it yourself, but rather than going through the store, add the code you inspected/wrote to the browser by enabling "Developer mode" in the Extensions (chrome://extensions/) then clicking "Load unpacked extension".
This would be a very simple piece of code so getting no updates is actually better for security in this case IMHO.
Well, yes, having a popup[1] on startup can be less or more annoying than submitting the thing to the Chrome store yourself depending on how often you restart your browser.
That fucking popup is the thing that finally drove me to drop Chrome and go back to Firefox on my home PC. Of course, now Mozilla is starting to go all in on extension signing too, so the joke's on me.
I use Backspace back quite a bit myself and was confused when it stopped working but I think it's the right decision to remove it. I'll just switch to Alt-Left rather than switch to an extension (and endure the week or two of annoyance while I adapt).
I actually use Page-Down instead of space which I suspect makes me weird but I feel like Space should be next on the hit-list as long as they are cleaning up confusing shortcuts.
This is going to sound hyperbolic, I'm sure, but backspace-as-back is enormously important to my browsing experience. When I recently installed Ubuntu I had a small moment of panic when I realized that hitting backspace in Firefox performed some Ubuntu-specific thing rather than navigating backwards (as it does in Windows), but fortunately there's an about:config pref to re-enable the behavior. Just my two cents.
I went through literally the same moment of dread as you a month ago when I installed ubuntu and realized backspace didn't go back in firefox... then I installed chrome and all was well. Might sound odd but I probably would have stuck with firefox on ubuntu longer just if that had been the default. I use escape and backspace keys regularly without even thinking about them until they don't do what I expect.
Third party or first party ?
Third party cause trust issue, and could change to behavior depending on the owner whim.
First party would be fine but need to be maintained.
Also extension have a discoverability issue.
I am pretty sure that the chrome team got the telemetry data to justify this "feature" removal. But I am really more in the "use a flag camp"
You can write one pretty easily I'm sure if you're worried about the trust issue. I suspect it is a few lines of code at most. I realize this is not ideal, but it would work. Use a flag is the ideal case for me as well.
Not OP, but the extension mentioned in the bug tracker requires permission to read and change content on all websites. That's just not right for something like this.
In France at least we have an Alt-Gr key (roughly equivalent to holding Ctrl+Alt) on the right of the spacebar instead of an Alt key. And unfortunately Alt-Gr+Left does nothing. So we have to use two hands to press Alt+Left, that's why I personally prefer using Backaspace
It's not the keyboards. It's the keyboard layouts that are configured in software. And not all "American" keyboard layouts make that key an Alt modifier. The Microsoft Windows "United States International" keyboard layout makes it level 3 shift, for example.
And if one includes North America and South America in "American" the same goes for the Canadian Multilingual and the Brazilian Portuguese layouts. (-:
Alt-[ and Alt-] also work. And they work even if a text field (including the address bar) is selected, whereas backspace or alt-left/right change to their text-editing behavior.
I think this is very good. I can't tell you the number of times I've lost form data by hitting backspace.
For those wondering how, if you do control backspace to erase a word etc igs very easy to miss, especially as you transition between word delete and single character delete.
The other common use case for errors is when u think you're in a field editing and you're actually not, bam, you just lost all your form data.
I also like the idea that backspace is for text editing and not for a second feature such as navigation. For enter yes but not backspace
This feels a bit like how Esc was nerfed over the years in Firefox and others until it essentially did nothing. It used to mean STOP. All sockets were closed, the page stopped loading, and I think way waaay back, even animated gifs stopped cycling and JavaScript timeouts and intervals were cancelled.
Single-page webapps were the death of Esc, it was too confusing to users to have a page suddenly hang because they pressed Esc for some reason and all the XHR connections silently closed. "Stopping" just no longer made sense.
Just going to need to train the old timers on the new key strokes. It is sad though when convenient controls are taken away.
Is there any replacement for that Esc=STOP functionality? Every now and again I run into a site that will display some content, and then 1-2 seconds later, cover it up with a full-page ad or signup modal or whatever. I wish I could just refresh and hit "Esc" really quick, like the good old days.
At the time that Firefox killed off Esc, I was part of the old school crowd that complained.
After the smoke cleared, I came to the conclusion that Firefox had crossed a threshold and transformed from being a networked document display application to being an operating environment that was a platform for applications. Javascript, the DOM and CSS had advanced to the point where keyboard controls biased towards convenient document browsing no longer made sense.
I'd be all for Firefox removing the Backspace default keybinding even though it would slightly inconvenience me since that's the key I use to go back.
Or maybe, it is well past time for browsers to have two concepts: “page” and “application” windows.
That way, web sites that are really trying to be applications can have one set of logical keystrokes, default security models, etc. and plain web pages can have another set. They could be further distinguished by some kind of difference in window frame.
I like this idea, but I feel like it would be hard to make sense of in practice. Many things that people would think of as "plain web pages" might have to be classified as applications just because they have some AJAX components. That would satisfy some curmudgeons who don't like what JavaScript has done to the Web, but it would be confusing to the point of worthlessness for everyone else. The alternative is to be extremely liberal about what you classify as a "page," which seems like it would basically be the status quo.
That could be true but consider that on the desktop we have had “files” and “applications” for years without much of a problem. In fact, any time a document tried to do too much (ahem Adobe Reader) it turned into a bloated mess and we preferred simpler formats.
I would like that kind of distinction to be made too somehow for battery life and security/privacy reasons.
I suppose your concept is partially implemented by the "Reader" mode that Safari introduced which I took was an attempt at "zen-ifying" the browser.
I think Reader Mode is largely a flop because 1) it is confusing in that it isn't always on offer by the browser/is context sensitive, which seems like an odd choice, and 2) some pages don't/can't always render sensibly in reader mode for absolute positioning/layout reasons.
My solution to this problem is to give content creators and web application developers better tools to separate between the "page" and "application" use cases.
For "page" content creators, it would be great if they had a framework that poured their content into the browser in an automatically screen-reader accessible way AND was formatted prettily. It's my personal theory that an optimally readable site also happens to read well to a screen-reader, so we can kill two birds with one stone if we abstract the content delivery a bit and force it to be rendered accessibly.
For "application" developers, it would be good to have the framework provide more/better standardized widgets than what the stock HTML5 offers. I'm thinking twisty trees, multi-select lists, streaming infinite scrolls tied to data sources, etc. These widgets would be screen-reader accessible and standard hotkey-enabled where the hotkeys would function the same from site-to-site (mandated by ToS or license).
Finally, the "application" side of this framework would include widgets to display inline "page" content where the user could toggle the "page" content to go full window or full screen and provide that zen reading experience.
> Just going to need to train the old timers on the new key strokes.
Ironically, that's probably the reverse of reality. Looking at the comments here, for starters, we have people espousing views that things have "always" been this way, and quoting their experiences of "the past ten years". It's the young people who are having problems and need to be re-trained here.
The "old timers" will, conversely, have experienced data entry on terminals or in MS-DOS programs like (say) Borland Paradox, where of course things like a backspace key will at most have moved from field to field on a single page, if indeed it caused inter-field motion at all. (The CUA Guidelines give no indication that autotab applies to backspacing from the first field position, i.e. auto back tab. There's a COMPSEC83 paper that talks about it, though.) Backspace certainly didn't switch forms.
This is most annoying. I have used this for the past twenty years and have not lost form data using it. In any event, chrome seems to remember form contents upon navigating back to a form page.
I lose form data by accidentally using backspace like once a month. Glad to see it go. It's the worst kind of UI modality because it does different things depending on whether you've reached the beginning of the form. I like to mash backspace to clear out a form. Imagine if pressing "CTRL-S" saved if there were edits, but deleted your file if you'd already saved. People who mash "CTRL-S" habitually would be screwed.
It's especially pointless now that everyone has a touchpad or touchscreen and can swipe back and forth.
I didn't say it's available everywhere I said there is another solution (already working in another browser) besides removing a very long lived keyboard shortcut.
> It's the worst kind of UI modality because it does different things depending on whether you've reached the beginning of the form.
I've never seen backspace act differently once I'd deleted everything. If a form field has focus -- even an empty form field -- backspace doesn't make me lose the page.
(On the other hand, I started this morning hating Chrome for getting rid of the functionality I've used since last century, but I'm now coming to accept it.)
To this day, I still regularly copy posts to the clipboard before submitting them, because of all the times I've been burned hitting the wrong button and losing it. (Losing the post, not my sanity! Well, that too, actually.)
I actually find Google search annoying to use because the search box hijacks backspace.
I'll search for something, decide to go back, and now I'm deleting my search term instead. And the fact that Google searches based on what's in my search box (without having to hit enter) I've actually "lost" search results that way.
I would expect the opposite behaviour to be annoying though, I've "lost" searches by hitting backspace and unexpectedly going back when I thought I selected the URL bar and waited to delete what was inside. Try to use alternative shortcuts rather than the overloaded Backspace.
I'm pretty sure it was Internet Explorer that started this horrible, terrible user interface fiasco.
Backspace (despite the name) is for deletion, should only be for deletion, and avoids confusion by only being for deletion. Period.
I don't see what's so hard about control/command-leftbracket or left arrow or whatever you want to assign to "go back". At least you won't accidentally wipe a form.
Anyway, this isn't about you or me, as someone else said, because forward state could be theoretically preserved. The problem is the 99% of "regular people" who will hit Backspace, not realize that they DIDN'T just lose their form and can just hit Forward again, and will redo the work and get frustrated.
I think I use backspace about half the time and cmd-left (osx) the other half. I quite like the cmd-left/right because of the symmetry; as far as I know, there is no backspace equivalent for forward.
What's still really annoying is that cmd-back doesn't work if a text input is focussed, so navigating back through several pages becomes a game of repeated cmd-left, interspersed with left clicks on a 'non-active' part of the page, or a series of TABs to leave all inputs.
Thank GOD. So many times I've been filling out forms and sometimes I hit backspace to delete something, and maybe I clicked on a dropdown, but it goes back one page and I lose everything. Not the end of the world, but pretty annoying and I'm glad they're removing this.
Not everyone really understands the concept of forward/back. In my experience, back is fairly well understood, but forward is a bit trickier. I guess a number of people, having accidentally gone back, either don't understand that forward will 'undo' their mistake, or just don't understand they've even gone back. That number, and the negative result, probably outweighs the number of people who will be annoyed by this change, especially since - as many point out - there are many alternatives to the backspace shortcut.
Finally! It's about time. I don't know who ever thought having a command that didn't use a modifier key was a good idea -- it's not just about losing form data (even if that's protected against), a webpage can have all sorts of "state" you don't want to lose.
Also, what's so hard with tapping Cmd+Left or Ctrl+Left to go back? It's all I've ever done, incredibly intuitive, and simply to do with one hand (using the right Cmd button), at least on most keyboards I've seen.
Cumulative time wasted using 'Command+[': none.
Cumulative time wasted due to overloading of the backspace key: hours.
Relying on current context to determine the behavior of backspace was a terrible idea from the start. To hell with your muscle memory. Re-learn a shortcut that makes sense, and which will save you time one day, rather than insisting with hacker-machismo that you've never lost data in a form.
If you can fill out a formular field correctly without losing focus, you are not part of Chrome's target audience.
edit: Had to type this four times due to accidently going back.
Hah, that's funny! But also, comment #35 is on point:
> The problem: Moving away from a form can result in data loss.
> Your solution: Make it harder to move away.
> The correct solution: Cache tab history completely and make it easy to move forward and backward in a tab's history by reusing cache and maintaining form contents.
> I never have this problem in Safari, and I use backspace all the time for navigating back.
That's funny, because I've got a brand new install of El Cap in from top me, and backspace does nothing in Safari. Maybe you turned on an option or accessibility feature somewhere?
Ditto...this (along with the fact that the width of tabs expands to fill the entire bar) is one of the main reasons I stopped using Safari and went back to Firefox.
...but seriously, if I had a dollar for every time I've tried to hit "delete" (backspace on mac) to delete something I had selected in a web app and had it navigate back losing my unsaved changes I'd have a couple bucks.
I can't count the number of times I've noticed a typo in a form, hit shift-tab one time too many or few, hit backspace and ended up losing all of the info I filled in. The forward button mostly just leads to "resubmit form data?", instead of bringing me back.
I've personally always used alt+left to go back. I know backspace does the same thing, but the only reason I know that is because I seem to hit more frequently than you'd expect while not focused on a form field causing my browser to go back unexpectedly. I've never lost data, though, it always seems to persists when I go forward.
I can't tell you how many times I've lost data because of backspace! Good riddance.
Now, please also get rid of pull down to refresh in iOS Chrome because that has also lost me data a ton of times as well. I don't even know who uses that feature. I don't need to refresh most pages and if I do there are better ways.
"How is someone who grew up in terminal times expected to navigate back when using a two-button mouse?"
I grew up in terminal times. I was lucky that, while growing up, I had access to my father's Unix account through the university. Not only that, I do all of my development work on the terminal (via tmux, vim, and spacemacs). I like the terminal. I love keyboard shortcuts. Keeping my hands in the home row -- awesome!
The backspace in the browser has always struck me as misfeature. I've lost data when typing in forms.
In contrast, when I browse a page, I rarely hit the back button. I'm more likely to open a link in a new page when I am doing serious research.
Times move on. Some things are lost, and our civilization is not for the better. This is not one of those cases.
My first instinct was to bemoan it's loss, but after thinking about it, I make this mistake far too often.
I actually just lost a draft of an annual self-assessment to this. I wanted to delete some text, but I guess I didn't have focus in the text box, and hit back. The form was created by an awful website (PeopleSoft/Oracle), so hitting forward didn't bring my data back.
Sure, it was just 20 minutes of work. Sure, a better website would have had the fields autosaved, or at least not have broken the browser autofill. Sure, I could have written it in a different program and then pasted into a browser.
But seriously, that should never happen. Not like that.
They say 0.04% of page views are a result of pressing backspace. 0.04% sounds small but imagine how many page views per month there are, globally, with Chrome. That's. Significant number.
Backspace sure is an unusual navigation choice these days, and perhaps wouldn't make sense to code in new software. But in browsers, backspace to navigate back is expect behaviour.
This isn't the first time the Chrome or Chromium teams have made sweeping changes based on usage stats, pissing off the minority who use those features and pushing ever closer to a browser with only the lowest common denominator features that everyone uses.
I wonder if this is in any way related to the exceptionally annoying thing on google.com, where if you hit backspace it doesn't navigate back, but starts removing characters from your search. It does this with other keypresses too, presumably so you can just keep typing till you find whatever you're looking for, but it's a flagrant disregard for my action of moving focus from the input field.
In any event, I use backspace to navigate back all the time, so this is sure to annoy me to no end. Especially since I use multiple browsers, and it'll be hard to break habits. Ah well..
Yeah, Chromium on Linux comes without the backspace history navigation for quite some time and I configured it to do the right thing for me: going back in history.
As a web application developer, I second the motion to officially thank the Chrome development team for this. "Backspace" triggering "back" is a usability disaster, and not only for inexperienced users. We recently had issues with a 3rd party editor widget losing focus due to a bug, which led to people accidentally triggering "back" and losing their data (it was a rich text field, so you can imagine how much of a problem that was). Sure, the problem here was the widget, but using such a commonly pressed key as the shortcut for a potentially destructive operation is a recipe for disaster.
More advanced users have the option to use a custom extension, or even mouse gestures. Just develop an "Advanced Chrome" plugin and the problem will be solved.
As a side note, it's interesting to see how such a small change (which, as mentioned above is even reversible) can trigger such an outcry. I've read stuff such as "I've been using this shortcut for 20 years" or "I don't want an extension"... are those even arguments? Yes, applications should be "user-centred" but the "user" here is a collective of thousands or millions of people with their own incompatible opinions. There is a (very good) reason for this change and I've seen zero achievable solutions that would not imply it.
I think I found out about Vimium through an HN post/comment and I've been using it ever since. It's pretty much the first Chrome extension I get after a fresh install, along with uBlock origin.
Good fuck that was annoying. I actually came up with a new work flow for all browsers because of this. I always open links in a new tab so if I want to go back I have to close the tab and if I want to go forward I will middle click to open in a new tab. This only falls apart when I run into a multi-page form or application that requires text. When that happens I hate that backspace goes back.
Well done Chrome. While it's the way that I go back and I now need to change my habits, this is the kind of hard decision that you need to make to have a really great product. They weighed the upsides and downsides, and pissed off a small subset of people (esp on HN who are likely to be the backspace-as-back users) to make a better experience. Bravo!
So they applied the wrong fix, to a problem that had been solved a decade ago.
The problem: Moving away from a form can result in data loss.
Their solution: Make it harder to move away?
The actual solution implemented more than a decade ago: Cache history completely and make it easy to move forward and backward in a tab's history while maintaining form contents.
The problem with that solution is, at least in my experience, that it doesn't really work reliably for most "rich" web apps , which are more and more common. (I understand that this is a controversial topic in its own light.)
I can understand where they're coming from, and I'd be fine with a browser extension. Hopefully the one a Chrome developer is working on[1] will be available before this Chrome release hits stable.
I seem to have read this as "that extension won't be a content script (i.e. require access to all websites, like the existing extension)" initially, but on second reading, that might not be the case (and might, in fact, not be possible at all with the current APIs). Not too happy about having to add that kind of extension unless it's released by some trusted publisher ...
I guess I can uninstall Backstop now (a Chrome extension that literally exists only to disable backspace to go back). I've been running it for years now.
For you 1% of people that actually use the Backspace key for going back, I'm sure someone will come up with an extension to re-enable it, don't worry.
I've never used backspace for nav intentionally, and it has caused annoying data loss for me a few times.
It's never made sense to me why this behavior was ever added to browsers. The logical choice would have been the left arrow key (since there is a corresponding right arrow).
> The logical choice would have been the left arrow key (since there is a corresponding right arrow).
Without some sort of modifier key, this would come with the same set of problems, i.e. failing to focus a text field while using it to move the cursor would trigger navigation. It's also used to scroll horizontally, so it would break other functionality. Alt + LeftArrow already works.
Having a friend who often operates their keyboard by the old stick between their teeth method, I'd like to see an analysis demonstrating that the breaking change improves accessibility. Particularly since the alternative posed in the thread is the chorded alt-left.
I've known Tim for almost twenty years. He's been on the web as long as I've known him...and given he was making money as a freelance CAD jockey when we met, I suspect longer than that. We'd been in school together a couple of years [me continuously, Tim off and on as being a quad comes with a raft of issues beyond asshat developers breaking the web] when we were both working in the computer lab of the college of architecture. Needless to say, the lab wasn't uniformly equipped with special keyboards nor all the machines loaded with custom adaptive software. Interface standardization and a resourcefulness I am utterly in awe of, allowed him to just do what needed doing.
This is breaking a standard interface. One group of people upon whom it most likely places a burden are those who are likely to have other shit to deal with already. Google ain't mailing out special keyboards to everyone who might need them. I don't imagine you're stepping up to fill that need either.
If there was really a problem with data loss, the better solution would seem to be warning the user before navigating away from the page. Removing a widely-used single-key behavior in order to protect users from themselves seems like a bad prioritization.
It'd be nice if we could still have software that is unashamedly not trying to target some sort of Archie Bunker "low information" user. Even the big Linux distros seem obsessed with making things easy for some hypothetical moron-in-a-hurry, at the expense of actual users who know what they're doing. It's unfortunate, and it seems to be a sort of antipattern that's infected a lot of software design. It wasn't always this way: there used to be an expectation that users would learn to use software, and that like any tool, if misused you could mess things up. Somewhere along the line, we've decided that it's unacceptable to tell users that they need to learn how to use software instead of blindly stabbing at it and expecting it to protect them.
I'm not against sane defaults or warning users before they really do something horrible, but the current trend towards ripping out anything and everything that might possibly be 'confusing' seems to be far overstepping the mark.
Firefox isn't much better, but at least they haven't Nerfed the back button.
Oh I'm entirely serious. Obviously nobody thinks that nobody else has ever lost data by accidentally pressing backspace, but I think most people can agree that it's simply not a good enough reason to completely remove such an established feature.
If you read the comments on the bug it's lots of people's position that losing data isn't real ("I've never had it happen", "Chrome remembers form data", etc). That's a silly position since it does happen, and this kind of error is the one that generally affects novices the most who are the least capable to deal with it or understand what happened.
If you've ever lost data and especially don't know why/how, then you know that super sucks and shouldn't ever happen period. Removing this prevents data loss, that's a UX win.
It's bizarre that it's happening in 2016, but better late than never. You still have power user alt/cmd-left so the keyboard can navigate, and if you're super duper keyboard person then you can install one of the vim navigation extensions or use an extension that preserves the backspace.
You say established feature, but I bet if you surveyed something like 20% or less would know about this.
About time! I've been seriously annoyed a number of times when doing text/data entry (on this very site!) where somehow I removed focus from the input, and then tried to erase some text, only to find it going back a page, and my input is gone when I browse back forward (this problem is exacerbated by inputs that don't exist until Javascript creates them from some page event).
When using a laptop with a sensitive touchpad, this can get really bad.
Great News! I have never intentionally hit backspace to go back, and yet I've hit backspace on accident and been taken many times. Quite annoying when it happens.
but the fact is that the browser is the one that decided to navigate away. Now what's very interesting, is that even in this, HN's, thread we have people saying "Yes!!!" and people saying "No!!!" to the change.
So people who simply have never used backspace for navigation, like me, have many times accidentally touched backspace or thought we were focused on a form, and ended up losing data (because the page didn't throw up a confirmation window after navigating back, and after clicking forward the page is blank again.) While other people, who have no convenient single key they can use to navigate back, have come to rely on it. I'm not sure what the solution is, but here's the current situation so everyone understands it.
We have UseCounters showing that 0.04% of page views navigate back via the
backspace button and 0.005% of page views are after a form interaction. The
latter are often cases where the user loses data. Years of user complaints have
been enough that we think it's the right choice to change this given the degree
of pain users feel by losing their data and because every platform has another
keyboard combination that navigates back.
We're doing this via a flag so that we can control this behavior should there be
sufficient outcry.
oOh dear lord, that's a horrible idea. You make a change to your software to fix a
problem that is not caused _by_ your software? If a form is confusing enough
that the user thinks they have focus when they don't and ends up losing data
then that's an issue with the form, isn't it? Not the browser and not the
button.
What makes you say that the problem is not caused by Chrome? I mean, Chrome is the user agent here, it handles both the form display and form input.
However, I agree it's a poor solution. They could have chosen to track modification of form fields on the page and display a confirmation dialog when backspace is pressed.
This is actually a no brainer, many times I have accidentally tapped on my mousepad while typing and took the focus away from a textarea then noticed a typo and tried to delete it and baaam you're no longer on that page and possibly all the text you typed has gone into the abyss.
Positive change in my book. This key was always overloaded, leading to unintentional usages. Using backspace as a "navigate back in history" shortcut never worked reliable for me in any of the browsers I've used extensively (Chrome, FF, and IE).
I welcome this change, because I've lost a lot of form data with the backspace key. Not specifically in Chrome, because I remember having the same problem with IE 6 at the time when Firefox was still in alpha and was called "Phoenix".
Now I wish that the Thunderbird developers also remove or change their single letter shortcuts that are easy to mis-type. E.g. "A" for archive, which creates an undeletable "Archive" folder in your mail account. There's a bugzilla issue for it here:
https://bugzilla.mozilla.org/show_bug.cgi?id=615957
This is why I switched to Vivaldi. All the shortcut keys are customizable. It also includes mouse gestures for quick back/forward with the mouse. I prefer having the choice than someone else dictating.
Here's the thing about Chrome... They don't want power users.
Remember when you first switched to Chrome? That sleek little pastel colored window elegantly fast. It worked on most websites. It was notably fast on Gmail, which at the time was the slowest website you spent a lot of time on.
You didn't mind that Chrome wasn't configurable. You might even have thought that it would become more configurable over time.
You were wrong. You were never the target audience.
I once had a infuriating (to me, at the time) argument with a Googler who was responsible for an internal app which performed better in Firefox than in Chrome. He said "Use Firefox!". I didn't get it at the time. He was a power user, all his co-workers were power users, and thus the internal app was only used by power users... They all used firefox! At least for real work... (Pretty sure they all had Chrome on hand for Mail and Maps, etc...) Anyway, the internal app correctly targeted firefox.
Meanwhile, back in time, when Chrome came out, Firefox started hemorrhaging users. Mozilla reacted. Today, it's as fast or faster than Chrome for most sites I use. And it's configurable!
If you are reading this, and don't have the latest beta or Nightly FF installed, you should go do so now! Really, trying firefox after being away from years will make you smile and renew your faith in humanity. :)
But unfortunately, this story doesn't end there...
I think some firefox devs see Chrome as a rolemodel... Maybe they want to compete with Google for those users who are not you! As a small example, I offer this: https://bugzilla.mozilla.org/show_bug.cgi?id=1118285 Note the posts that are marked "Comment hidden (advocacy)". You can click the [+] to show what was hidden (comments from power users).
There are niche browsers for power users, and there are extensions... But there isn't a mainstream browser for power users because power users aren't mainstream.
I'm just describing the problem (well, I hope!), I'm sorry but I don't have a solution.
ffs this is stupid. backspace has always been "back" in browsers and it really vexes me when some versions of firefox on some linux distro's do this.
two hands have to be used to action this because the right alt key is either not mapped ( on some os'es ) or is alt-gr.
backspace works well when moving quickly too - one finger from home row and bam.
Rather then this be the fix they should probably look at the bug thats causing the user to go back when the form element is focused.
Whats next ? take away space bar for moving through the page ?
A about:config thing needs to be present for this to allow the user to switch between what they want. Sure extentions are possible to fix this too but i dont really want a 3rd party extention to re-enable whats a tried and tested keyboard shortcut. Additionally what happens if that dev's account gets hacked and the extention modded for malace ?
Or if the dev pulls the thing in a way similar to the node.js module issue a month or so ago.
This part is worrying though:
We have UseCounters showing that 0.04% of page views navigate back via the backspace button and 0.005% of page views are after a form interaction.
Where is that data being gathered from and how?
Additionally what is classed as a form interaction ?
I am glad they are making this change. I've lost my form data by accidentally going back while trying to erase something in a text field so many times.
On OS X, Command-left bracket has worked on Chrome, Safari, Firefox (and probably more) for years. Not sure about Windows or Linux, but keyboard shortcuts are very well established across browsers in this way (like Command-L, and all of the Emacs bindings like Control-A, Control-E, etc.).
As someone who constantly gets screwed by this: finally!
Example from literally one minute ago: a cool thing was going on in a Twitch stream and I wanted to hype in the chat, misclicked the chat box so backspace went back to the stream list instead making me miss the moment.
This is one of the reasons I first moved away from internet explorer - this seems to happen constantly on that browser. I've never had a problem on Chrome or Netscape/FF, but I'm generally supportive of getting rid of this concept.
I would very much like them to revert this change. Using backspace to go back has been in my browsing habits since I began using the internet. Atl+left or right is annoying. Either give us a checkbox or revert it. Please. Pretty please.
Big thanks to the Chrome devs for this, I applaud and personally appreciate the decision but wonder why a navigation shortcut like this couldn't be made into an option for others to enable or disable based on their preference?
>Are you suggesting that the only remaining options are Alt-Left (a two-hand key combo for that I have to move my mouse hand towards the keyboard, and then back)
I guess no one told this guy that a standard keyboard has two ALT keys.
Thank you so much for this. Accidental backspaces have been s o frustrating to me at times. I'm glad sharing my telemetry was able to assist you in seeing these problems.
I don't mind removing backspace, but this better not remove the functionality of my back button on my mouse. That's one of the worst things about having to boot into OSX at work.
on the topic of annoying details that browser makers overlooks.
In safari, when opening a new tab, the focus is not on the address bar. I have to always to Cmd+L before start typing. The address bar focus works when you don't have a homepage defined (so a blank page), but who doesn't configure a default home page? arrghh
Sometimes, it's better without these features. E.g. on Mac, dragging left in the browser is a gesture for going back to the previous page, and I can't count how many times I've accidentally triggered that while filling out a web form or interacting with a page. Isn't the back button and the keyboard shortcut enough?
Good riddance! This is such a terrible double-purpose binding. When bindings seriously are common typing commands, that are not just bound, but bound in a way that is often destructive, it just needs to die.
Anyone who thinks this shouldn't die is basically a bad person. It was an affliction, and one of the poorest design choices in history. :-p
Because adding customizable keybinds is too difficult? Hell, if configs looking scary to normal users is a problem why not just have a json/sqlite/whatever file in the profile directory?
Google Chrome have fixed a longstanding UI/UX bug and state overload of the Backspace key
Backspace key in Chrome browser no longer navigates backward, but instead is limited to its initial and rightful role: deleting the previous character under the pointer (mouse / text cursor).
I swear by His Noodliness I'd ranted on this at G+ some time, though unfortunately since Microsoft Bing Search isn't available on Google+, I cannot actually find shit in a useful fashion.
That said, I applaud this change, thumb my nose at the fuckwits who are bitching about it, and note again the Flaw of Averages: One Size Fits None.
As to the justification of not relying on Backspace for Navigation
I ordinarily take exception to blame-the-user / taunt-the-user practices, and should hasten to explain my own here.
Learning a New Backward Navigation Method is a Temporary Training Inconvenience.
Repeatedly losing Vast Quantities of Newly Composed Content is an Irrevocable User State Loss.
Among the canons of human-computer interface design is this: Thou shalt not fuck with thine users' State.
Which by definition makes those who fail to make this distinction fuckwits. Perhaps only ignorant fuckwits, a curable state, though quite possibly and regrettably stupid fuckwits, a State of Extreme Durability in my experience.
The larger fault is arguably for the lack of a clear stateful separation of editing from _ browsing_ modes in Web browsers. Editing involves creating novel user state which can be easily lost through capricious client behavior, such as, to draw on a randomly selected example, fucking overloading the backspace key with the behavior of "delete my highly considered and Very Important Message to the Univers by immediately and irrevocably moving off this page.
It's with some irony that I note that console-based Web browsers rarely have this problem. The w3m browser, for example, when editing a text field, dumps the user to a local full-powered editor, and in fact defaults to that one specified by the users environment ($VISUAL, $EDITOR, etc.). The result is that a "primitive" browsing tool actually has an exceptionally powerful editing environment.
(At this point, the Emacs users in the room are of course laughing and pointing at me, but they in fact entirely substantiate my claim in doing so. And, my dear good friends, I've given not inconsiderable thought to actually joining you, as it seems that via Termux, a commandline environment for Android, emacs and all its capabilities are in fact available to me, and may vastly surpass the Android applications environment in capabilities. The fact that Viper is a well-established and long-standing component of the Emacs landscape means that the One True Operating System now does in fact have a useful editor.)
Chrome has other utterly unredeemable failures on Android, including an utter lack of ad-blocking capabilities. But for the task of composing and editing, this is a nice touch.
But it does raise one futher point: why is editing via Web tools so abysmally poor?
Despite various deficiencies, the G+ app actually does favourable compared to a number of other platforms, and virtually all Web editable tools. Reddit and Ello stand out particularly. As much as I love the Reddit Enhancement Suite full-screen editor (it's a browser extension for Firefox and Chrome desktop), it's not available on Android. Meaning I've got to jump through Multiple Divers Hoops in order to compose long-form content on Reddit. Android's various content-creation deficiencies make this a tedious process. This accounts for some of my Diminished Output in recent months.
In particular, Firefox/Android has proven Exceptionally Capable at Losing My Shit, at least in memory not exceptionally distant (considering I've owned my present Samsung[tm] Infernal Device[r] only since October last), a characteristic which makes me Exceptionally Leery of Embarking on Enterprises of Extensive Prose Composition within that context.
Given the, shall we say, exceptional advancement of text-composition in other contexts, I find this particular failure mode of the Browser Development Community in General most unpardonable.
Never lost data on firefox by going forward after going back for accident while writting on a form, but whatever...
Google only wants dumb users who can't see past what they're doing.
My Firefox has browser.backspace_action set to the default value (zero), and it goes back to the previous page when I press the backspace key.
It's been less than 36 hours since I lost several hundred words of work because of this, so I'm pretty sure the default behavior is "go back" as of the latest stable version (46.0.1).
It seems like 0 (go back) has always been the default on Windows builds. On Linux it used to be 1 (scroll up) but they changed it to 2 (do nothing) in 2006.
I made a half-assed attempt to migrate my Windows Firefox profile to Linux a while ago, which probably explains why I'm seeing the Windows behavior on both platforms :(
Browser still has the top part of the window containing navigation buttons. There will always be at least one way to "kill a website" if something bad happens. All other controls should be offered to webapps to let them give users a better experience.
It makes it quite difficult to write a terminal emulator web app.
Chrome, at least, can resolve this issue by bundling up your web app as a Chrome app; apps launched from the Chrome App Store can launch into a context where the standard Chrome modifier keys aren't mapped.
Why don't you define an alternate button that acts like ctrl? It's the same as how in Windows remote desktop you have to use ctrl-alt-end instead of ctrl-alt-del because the software can't override the handling of that keypress
Probably for similar reasons to the ones people have expressed in this thread about not wanting to have to re-learn backspace. ;) Perfectly doable; doesn't solve the problem of not mapping to what one is accustom to.
I'm an emacs user. If Ctrl-c does something different from starting a chord, I'm gonna have a bad time.
I switched from using a Mac keyboard to using a Windows one when I was still a heavy emacs user; I think you'll get adjusted much faster than you think.
It's always easy to tell apart the people who know shortcuts from the people who don't, if you watch them use their computers. Someone with a few shortcuts on tap will zoom around their monitors, switching between mouse and keyboard only when necessary.
But there are a few shortcuts and user interface quirks that are too outdated and weird, and only serve to surprise and annoy us. They herald from an earlier age when people were still figuring things out in new UI paradigms. For example, these days, you expect the scroll wheel to scroll up and down in a scrolling view. However, my coworker was changing some project settings in Visual Studio the other day, and he tried to scroll through the settings while a drop-down menu in the settings had focus. It scrolled through the menu options, selecting them, instead of scrolling through the view. He had to cancel the changes he was making and open the window again, because he couldn't remember what was originally selected.
This is the worst kind of surprise. Something you thought was just supposed to let you look at different parts of the interface instead modified the data you were looking at. Backspace to go back is a similar surprise. It's supposed to delete text, but instead it can navigate away from a page entirely, if you are in the wrong state when you press backspace. For the same reason, I'm even getting sick of the old middle mouse button paste, since it's too easy to press when I'm scrolling.
Forward and back navigation are already mapped to alt + left and right arrow. Let's reserve backspace for deleting text. (I'm not happy that it sometimes means "navigate up a level", but that might tell you what kind of computer I had growing up.)