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.
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.)