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 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.
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.
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.)
> 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.)
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.
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.
"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.
"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.
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.
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..
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.
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...
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.
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.
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.
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?
It turns out this extension does exist. I just used it to assign "shift+backspace" to "Go Back" and it worked.
> "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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
> 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.
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.
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.
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.
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:.
>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...
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 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.
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.
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.
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.
> 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.
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.
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'.
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.
> 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
>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.
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.
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.
- 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.
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 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
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.
"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.
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.
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?
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 :(
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 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.
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.
> 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.
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?
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.
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
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.
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.
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.
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.
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 ...
593 comments
[ 4.6 ms ] story [ 254 ms ] threadLeave my muscle memory alone please.
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.
It's especially pointless now that everyone has a touchpad or touchscreen and can swipe back and forth.
No?
One thing I like about my venerable x220 is the dedicated forward & backward keys that can also be used to switch buffers in emacs etc.
Use a browser that will warn you about losing un-submitted form contents before navigating away?
> It's especially pointless now that everyone has a touchpad or touchscreen and can swipe back and forth.
I think we have very different definitions of "everyone".
Most browsers don't do this. If you see a warning like that, it's usually triggered by javascript on the web page itself.
You live in your own little world, don't you?
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.)
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'm an avid backspace-as-back user, so I went searching for a solution as soon as they introduced focus-stealing.
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.
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.
I'm always a bit apprehensive to enable those sort of extensions.
This would be a very simple piece of code so getting no updates is actually better for security in this case IMHO.
https://support.google.com/chrome/answer/2811969?hl=en
EDIT: And prompts you to disable it at startup if it's unpacked.
[1]: http://i.imgur.com/qX8bNcl.png
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.
No seriously, if any Chrome devs are reading this, I will go back to Firefox tomorrow if you break Space.
So it would be hopefully possible to re-enable it via chrome://flags or something like --enable-backspace…
Edit: Or not –– "We ended up not having a flag for this. Even if we had it, it would only have been in place for a single release."
"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.
There is one, on KDE level. Any KDE app has generic-looking hotkey remapper under settings menu. It just works.
System Preferences -> Keyboard -> Keyboard Shortcuts -> Application Shortcuts -> [+]
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.
http://kb.mozillazine.org/About:config
Dumb.
I am surprised Apple hasn't encouraged users to do that, come to think of it.
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.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=565567
See all your data on all websites
cant wait
Extension: https://chrome.google.com/webstore/detail/back-to-backspace/...
Source: https://github.com/j-delaney/back-to-backspace
It turns out this extension does exist. I just used it to assign "shift+backspace" to "Go Back" and it worked.
https://chrome.google.com/webstore/detail/shortkeys-custom-k...
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.
And I'm using the word clever in its most negative way here.
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.
(2) The concept of a "form" is less and less clear in the realm of web apps.
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.
It's an application-level question, not a system question. Can only be answered with semantic knowledge of the importance of the user input.
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.
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.
[1] https://addons.mozilla.org/firefox/addon/betterstop/
This is a change that should've happened a long time ago.
Except for (guess who?) Chromium...
https://bugs.chromium.org/p/chromium/issues/detail?id=255
how would you correct mistakes? with the delete button?
Glad to see it removed, alt+arrow-left/right still exist so the keyboard can still be used.
If only Alt-Gr+Left or Right Ctrl+Left worked...
And if one includes North America and South America in "American" the same goes for the Canadian Multilingual and the Brazilian Portuguese layouts. (-:
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"
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.
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.
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'.
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 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...
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.
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.
(Unless I'm mistaken, the right-click copy uses a different clipboard, so you can't use that.)
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.
To me that address bar abomination is just an obfuscation of otherwise useful information with large clickable regions of functionality I don't want.
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.
I think there is also a "show breadcrumbs" option in the preferences for Finder, which may or may not give more of the functionality you want.
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.
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.
[1] http://twigstechtips.blogspot.com.au/2010/02/win7-remove-win...
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.
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.
Yeah, I remember doing it once and thinking it was extremely helpful at the time, but I only remember doing it once so far.
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.
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:.
You can also right click the bar to edit or copy the URI...
I use drag to scroll assigned to my right mouse button (works great in FF, so so in Chrome):
https://addons.mozilla.org/en-US/firefox/addon/grab-and-drag...
https://chrome.google.com/webstore/detail/scrollbar-anywhere...
I miss this so much outside my browser...
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.
If I wanted the entire URL highlighted I could just double click on it like in every single other piece of software.
Worst feature EVER. I can't begin count how many times I've had the following talk with users:
user: My password doesn't work
me: Did you copy it from Outlook?
Problem solved.
It's terrible. Really.
https://news.ycombinator.com/item?id=7943365
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 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'.
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.
Small things add up to big annoyances.
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.
https://xkcd.com/1172/
I think some of those complaints reaching the front page of reddit may have helped spur this into action by the Chrome team.
It's a race to the bottom.
Thankfully on OSX/Safari, this legacy behavior/cruft is not present.
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.
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.
I do find the spacebar behavior isn't super predictable when I am trying to pause things, such as youtube .
I've never managed to consistently replicate it by having had the player in/out of focus already, not/scrolled, etc. odd.
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.
I've never actually seen someone complain about it until now.
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.
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.
Or I could read a book....
> 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.
Fitts' Law.
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.
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.
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.
Wait, they removed that (I didn’t do the update yet, refused to connect to WiFi to avoid it).
I quite literally use that every minute – typing on UK layout German and British, and trained the dictionary to accept any mix of the two languages.
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.
[1] https://www.thestar.com/news/insight/2016/01/16/when-us-air-...
Any idea what could block it? Never seen this before...
Many CDNs can be configured to block access within a country. For whatever reason, that's what The Star has chosen here.
now if only our cars are as adjustable, given the almost-similar circumstances
In this case it's a minor thing which probably wouldn't require much maintainance, but you have to draw the line somewhere.
That said, I'm glad they finally did something to fix this bad UX design.
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.
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.
In this case, the right thing really is contextual, so a configuration or extant setting / default is worth the cost in complexity.
The quote "Everything should be made as simple as possible, but not simpler" comes to mind here.
This is a shortcut button … The maintenance argument is really a straw-man in this case …
> but you have to draw the line somewhere.
And this shows that they chose to place this line at «this product is our product, there is no customization options»
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.
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.
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.
Isn't Chromium opensource? I'm sure they'll accept your pull request.
- Make changes that annoy some users
- 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.
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.
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
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.
https://productforums.google.com/forum/#!topic/chrome/R-wESj...
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.
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 the first thing I'm always enabling on every new Firefox installation since they disabled it by default several years ago.
And with sufficiently large user base, even 0.04% means "lots of people being pissed off now".
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?
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).
http://kb.mozillazine.org/Browser.backspace_action
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 :(
https://bugzilla.mozilla.org/show_bug.cgi?id=986982#c6
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.
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.
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 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.
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.
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).
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.
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
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.
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.
I'm an emacs user. If Ctrl-c does something different from starting a chord, I'm gonna have a bad time.
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.
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.
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=608016...