The reason we’re making this change is that users regularly lose data because they hit the backspace button thinking that a form field is focused. After years of this issue, we realize we’re not going to have a better way to solve that problem.
I absolutely hate this change. I deeply, deeply, deeply hate this change. This is a classic case of instead of addressing the core problem – web forms shouldn’t lose their content when you navigate back and forth – you just try to hide it a little more by making navigation harder.
Emblematic of software development today, especially in operating systems: instead of fixing core problems, let’s just add more layers to hide the ugliness. You see it everywhere – from still relying on an operating system written for timesharing machines with punchcards, to trying to hide broken, complicated and obtuse file system layouts behind “just use convoluted cloud storage”.
People carrying around ugly battery packs just to get through a day of use on their devices running an outdated timesharing mainframe punchcard operating system from the ’60s tells you all you need to know about the complete failure of modern software development – and this tiny little change in Chrome only underlines it.
Good software does not exist.
Thom, I really don’t understand your comment. I agree that webforms should not forget their content if you go back and forwards again, but I also HATE it when my browser goes ‘back’ when I hit the backspace button. Backspace is for (deleting) text entry, and just because you don’t have a text field focused (accidentally), it shouldn’t start working as a navigation button all of a sudden.
Flawed argument. Tons of keys have double functionality – just look at tab or space.
Tab is sloppily executed in Chrome as well (there is no visual clue at all to what it does) and it should either be improved, or scrapped just the same.
Space just jumps around (down) on the page, that’s stupid (we have PgDn for that) but not as drastic as navigating back.
Edited 2016-05-20 11:36 UTC
Sorry Thom, but I had the exact opposite response. I read the headline, and literally pumped my fist in the air and said “Yes!”.
This seems ridiculous, but I’ve lost *so much* time in legacy websites I have to maintain (but not change, heaven forbid), filling in forms and then accidentally tabbing (which in the browser only moves around focus) out, and hitting delete, then losing it all.
For MacOS, there is ^aOE~[ for back, “delete” definitely shouldn’t do the same.
https://discussions.apple.com/___sbsstatic___/migration-images/187/1…
Also totally agree with Dryhte. Not that one shouldn’t have keyboard shortcuts for navigation but surely the right keys for this are the forward and back arrow keys, no? And then a short cut editor for those without such keys or like Thom who want to use funny keys.
Ps I think up down keys should operate tab volume.
/.
We already have navigation hotkeys, though: alt-left and alt-right. Super easy with both hands on the keyboard, and zero risk of hitting the wrong key.
You may say, “But, it requires both hands”, but generally speaking, people always have their left hand on the keyboard, removing their right hand only for the mouse. This isn’t affected by that.
You are 100% right Thom. Removing backspace to avoid disappearing form content is like removing the color blue to avoid Windows BSODs.
Sounds like a joke but It’s so sad and so true. Software engineering is joke.
It’s funny how little you understand about basic usability concepts with how long you’ve been covering the industry. The idea of backspace as back was terrible from the start. Good riddance.
You’re taking a key that is used for deleting a single character 99.9% of the time in every program (aka minimally destructive and undoable) and then you use it to do something completely different with no feedback as to what it will do at any given time. Then you make that other action (going back) potentially hugely destructive to content. That is terrible usability and it’s high time it was removed. This isn’t a matter of opinion, these are some fundamentals of user interaction that were settled 30 years ago.
Edited 2016-05-21 16:00 UTC
That’s not really the point. The backspace key is primarily to delete something, normally text.
The context someone is in, within a webpage can be very difficult to both identify and keep track of.
Removing the functionality restores predictability and that’s a great thing.
POLA is something HIGHLY missed on Browsers since ‘Dynamic’, ‘Live’ pages became fashion. Browsers are -before any private interest else- DOCUMENT Browsers.
When into a script, expecting it to have their own UI particularities. But not expecting -AT ALL- a change in the expected behavior and security of the Browser containing It. Create your own!
Gosh! that’s so ‘spooky’.
And that is my main complain with APIs landscape, users side perspective. Confidence require EXPECTANCY FULFILLING.
But on plug-ins suddenly -and sometimes stealthy- taking control of our applications. Make of them unreliable ‘meretr"A<
USABILITY is betrayed on allowing unreliability.
So, any API call should instantiate and initialize and create their own UI. Extreme, but necessary to regain user confidence.
Yes but if you don’t understand the _huge_ differences between deletion of a character and navigation you really shouldn’t comment on user interface related topics…
Backspace for navigation have always been a idiotic “standard”.
Totally agree with you Dryhte. I do believe that this is a change for the better.
Browsers should never have been designed to use backspace as a navigation tool!
I’m curious if it ever meant ‘go back’ before web browsers.
I do agree that website should have better information persistence, but that is not going to happen across billions of sites. Much easier to fix in a browser.
I don’t really want an alternative like the browser holding the information in a new cache. That would just be an exploit waiting to happen.
Good riddance to obtuse key functionality.
The original meaning of the backspace was to go back one character on the line without deleting it, so that you could over-type to get accented characters (that’s where the ~ and ` on the keyboard came from), while the delete key was used to actually delete the character under the cursor (which is why it deletes stuff to the right of the vertical line cursor in languages with a LTR text order). Both have changed in meaning in graphical applications multiple times (and it doesn’t help that different OSes have reported different keycodes to userspace over the years for these two keys).
Now, as far as browser key-bindings, they should have been customizable from the beginning, period. This whole issue is perpetuated by people like Microsoft who insist on UI consistency over user experience (Windows is the only major commercial OS today where you can’t rebind almost any key combination to do whatever the hell you want). This is actually part of the reason I avoid a GUI if at all possible, on the command line you almost always can customize your keybindings (and most things have an option for vi-like keybindings, which I prefer anyway)
Agree, Ahferroin7
I think the browser should keep the form data within reason (perhaps with a size limitation, as you can in theory store a lot of crap data in a web form.) if you just navigate back and forward. However if you do anything on the previous page even just scrolling or highlighting text you could in theory had changed the state of the original page and messed up the workflow for the next.
I much rather see a read-only back button where I can flip back and forth and look at the data on the previous page or even better follow back every change in DOM
I always thought this was just a perk of the ancient and horribly broken Internet Explorer. Never would have expected that Chrome is just as broken. Backspace has nothing webpage navigation, so it also should have no effect on it. Spacebar skipping a screen worth of content down is equally stupid.
Edited 2016-05-20 11:32 UTC
I actually kind of get the spacebar thing, it’s not trivial if you’re resting your hands in a typing position to hit the page down or arrow keys on many keyboards without significant movement. Of course, I still prefer hjkl for panning the page, but I almost exclusively use Vim as my text editor, so that’s what I’m used to.
It actually originated in Netscape Navigator.
You know what solves this issue for me? Customizable keyboard shortcuts. As in Vivaldi.
I absolutely despise the removal of customizability for the end user.
You can implement the defaults for the masses, but allow me, as a power user, to do things my way – the way i like or am used to.
Former Opera has the right approach. They have the right approach in a lot of things.
The same way you are able to select [or create] a Char Map.
I don’t know if you’ve noticed, but power users don’t matter any more to these companies. We are picky and expensive to develop for, as opposed to the millions of tech tards that’ll use whatever you put in front of them, as long as it looks pretty. (Why else do you think Google has a random hard-on for emojii these days?)
I don’t like it any more than you do, but it is what it is.
This is as it should be. Thom, perhaps not being a keyboard centric user and probably having little knowledge of accessibility concerns as a result of this, you don’t understand just how bad it can be when a form field appears to be focused and isn’t. This is a change that every browser should make, and a change I regularly configure for myself in all browsers I use when possible. Just because it doesn’t happen to you doesn’t mean it’s not a problem. You still have other keyboard shortcuts to go back (command-[ on OS X and alt-left arrow on all other platforms) so you’re not out a keyboard command.
That’s exactly what Thom ISN’T saying.
Instead of removing the functionality, Chrome (and all software) should be designed to NEVER LOSE USER DATA, even if the user makes a mistake. Even just a popup saying “The information you entered on this page will be lost. Are you sure you want to navigate away from the page?” would be better than just discarding information that has been entered and going back a page.
(…unless I misunderstood what you were saying, too…)
That already exists. At least in Safari, not sure about chrome.
Whatever one thinks about using backspace to go back (I, for one, couldn’t live without it), why not just make it optional? In Firefox, which removed this functionality ages ago, it can be restored in about:config. Why not do something similar here?
As for the rant: one could argue that removing an obscure functionality of a button could actually mean “fixing” an old “bug”…
Small nitpick, but Firefox didn’t exactly remove this behavior by default. What they did was change the default behavior based on what other browsers on the platform did. On Linux, for example, it’s disabled by default where as on Windows, it’s enabled. Setting the value to 0 in about:config restores whatever the default value of the platform is for this feature. I don’t remember what the Firefox default behavior on OS X is for it.
0 goes back a page on all platforms, 1 scrolls up a page on the current document on all platforms, and any other integer does nothing.
The behavior is identical on both platforms, but the default is different.
http://www.joelonsoftware.com/articles/fog0000000069.html
There is a reason why Fortran and other ancient languages are still in use everywhere, the code works and it is extremely well debugged.
To rewrite much of what already exists would provide almost zero benefit and will waste hundreds of man hours in developer time.
While I am a big fan of Joel Spolsky, there are also plenty of examples where staying on the same codebase rather than starting again is the right way to go.
An example is actually in the very same article (strangely used to make his point but in hindsight was incorrect): only when Mozilla decided to throw away Netscape code did they have success again (Firefox).
Note also that Fogbugz was completely out-innovated by Jira, imho partially because staying on vbscript and other outdated technologies – though there are other explanations.
One could argue that even Windows and OSX now suffer the same fate, largely tied by the history they have to carry, making it possible for Android/ChromeOS to capture some market share.
Edited 2016-05-20 12:37 UTC
OSX and iOS are pretty much the same OS and it would be hard to argue that iOS (tied obviously with the iDevices) isn’t successful.
Edited 2016-05-20 13:14 UTC
At the time there was the classic code that powered Netscape Communicator 4.x. The whole suite was rewritten at the time using a new stack based on the Gecko rendering engine. This product was the Mozilla Suite/Netscape 6+ and is now Seamonkey. The rewrite took a significant amount of effort and they had to release it prematurely because they were falling behind. They Netscape 6 with loads of bugs and compatibility issues which hurt the Netscape brand (the corresponding Mozilla release was version 0.6 for comparison).
Firefox was just the spin off of the browser from Gecko based suite. It had the advantage of being more streamlined, not having the tarnished Netscape name attached to it, and having a few more years of development allowing the code to mature. Also, it’s competition at the time was IE6, which while good when released had been neglected by Microsoft. Firefox is what Netscape should have been.
So eventually the rewrite was successful in the form of Firefox but there were several pretty rough years before it payed off.
So to me the moral of the story is: when you have a successfull product, start writing a new version early and use all the knowledge you gained to make the next gen, rather than banging on with the old version and realise very late that you have an old, non-competing product.
The morale of the story is never to write a new version that is why they lost market share in the first place.
Everytime I seen a new “platform” being made, it happens to be a slightly tidied up version of the old version and this is in the best case scenario.
I think there are limits to keep improving step-by-step.
You could argue that Windows 10 Universal Apps is a variant on this. MS spend a lot of time trying to make coding for mobile and tablets the same as Windows. Nokia held onto Symbian while they had Meego.
And Apple introduced major changes to the architecture at least twice (Lisa/Mac + OSX).
Maybe it all boils down to timing (no Osborne Effect) and execution.
Apple bought a rewrite (NeXT) when that rewrite had gone nowhere for more than half a decade already.
Nobody is saying that a rewrite cannot eventually become better than the original (i.e. OSX vs MacOS classic). The point is more that the cost of doing a full rewrite is always way beyond the estimate of those suggesting it, along with the fact you are dead in the water for the duration. And finally there’s no guarantee that the rewrite will actually end up better than what you originally had.
That never works if it creates any kind of incompatibility. People will keep using the old version because they are tied to it and the will never move to the new version. Then you end up supporting multiple versions forever.
abraxas,
It sure feels like forever, but eventually things do change. A few years ago there was still strong pressure to support the notorious IE browsers that we all hated. Today I don’t even have to think about them anymore.
Unfortunately many innovative developers may not have the resources to outlive the market lag to see their work bare fruit. One can only hope that their work is open sourced so at least someone else can see it through, like mozilla.
Edited 2016-05-21 14:50 UTC
One of the greatest arguments for open source.
It’s a totally different ballgame with most business facing commercial software.
abraxas,
Not always. There’s obviously a risk that an investment doesn’t pay off, but there’s also a risk of getting left behind in favor of those who do invest to bring newer products to the market.
“That never works if it creates any kind of incompatibility. People will keep using the old version because they are tied to it and the will never move to the new version.”
The issue I have with this generalization is that it’s stated as an absolute truth but glosses over lots of subtly important details and completely ignores the role of competitors. For example consider that when Intel invested huge sums into the “new” Itanium architecture, it was a miserable flop. Yet on the flip side, when Intel invested tons of money sticking to it’s “old” x86 guns in the mobile market, it was a miserable flop.
We can explain this away (because details), but by the same token it means simplistic generalizations are wrong (because details). Is there any way we can agree that the risk/rewards of investing in replacement tech depend on what’s going on in the market?
Edited 2016-05-23 03:43 UTC
Firefox did not just throw away Netscape code. Firefox was an interface rewrite to the gecko rendering engine. The rendering engine codebase did not get thrown away. When Phoenix was originally released it was basically Netscape with a GTK interface and without the other Netscape bundled apps.
Why user of some software has to be equipped with the knowledge about software engineering? I personally know the the price of writing some piece of SW from scratch but I understand the users don’t like to care about it at all as long as they got something they need.
Read the article rather than the quote.
“There is a reason why Fortran and other ancient languages are still in use everywhere, the code works and it is extremely well debugged.”
Very well thought your comment, Lucas_maximus.
Just adding that if “all that knowledge. All those collected bug fixes” never express beyond those blocks of code embedding them, then we are coding the wrong way.
When time comes to code that program into Rust we “will waste hundreds of man hours in developer time”.
….
Document, document, document… Code in Meta Languages, to the point were you are unable to keep at it, Then log every incident at the building, testing, deployment and maintenance of the code.
Programming should be evolutive. Code shouldn’t.
Don’t those ‘IDE’s integrate all the necessary tools?
“Microsoft almost made the same mistake, trying to rewrite Word for Windows from scratch in a doomed project called Pyramid which was shut down, thrown away, and swept under the rug. Lucky for Microsoft, they had never stopped working on the old code base, so they had something to ship, making it merely a financial disaster, not a strategic one.”
Now I know that MS Word shouldn’t never made into an ISO standard. [Is ‘that’ a standard?]
[Failed reproducibility (as all We know). Even internal reproducibility! (As Joel comes to tell Us)]
There’s something to be said for taking lessons learned, including new programming languages and better security practices and making something new out of it.
Point of order m’lud but UNIX (Unics) was developed on a PDP-7, which did not use punch cards (although it did use both magnetic and paper tape)
PERFECT software might not exist, but you seemed to be able to post all of that just fine through some CMS and I seem to be able to read it and comment on it just fine. Seems like good software to me
…that it’s not only form filling that’s the problem.
Modern continuous scrolling websites, and sites that load the page, then load the comments afterwards, are the worst. Navigate away and come back (or, if it’s Chrome for Android, switch to a few more apps, or pair a bluetooth keyboard (to, say, fill in that form field)), and you have to load everything all over again.
As someone with UI/UX design as my chosen career path, I’m going to have to disagree with you there.
While I definitely agree with you that forms shouldn’t lose their content, “backspace to navigate back” is a separate issue with two underlying problems:
1. Given that going back is a heavy action which may require HTTP requests, depending on the cache-control headers involved, it shouldn’t be tied to a single keypress. It makes more sense for it to be a chorded shortcut, like the existing Alt+LeftArrow which still remains in Chrome and Firefox.
(For the mouse, an equivalent principle would be “Don’t bind heavy actions to your WM’s hot corners”.)
2. Tying two actions of wildly different scopes to the same user action, separated only by an easily mis-set/mis-identified value (the input focus) is a classic example of bad UX design… especially if one of them trains users to see it as “either trivially undoable or a no-op” as pressing backspace in a text field does.
Edited 2016-05-20 12:58 UTC
I wish I hadn’t commented, so I could vote you up. You explain very clearly what I feel.
Shouldn’t pages containing anything not state-less disable back and forth? Once a ‘form’ is altered, isn’t scripter [server/client] duty to provide navigation?
My work-around on Mozilla family: Once passed the log-in page I open a new instance of the site on a new tab [clicking OSAlert logo, by example], which becomes my “read-only” navigational screen of that site.
[RIGHT-clicking OSAlert logo, by example]
You can also just set whether or not backspace works as navigation in about:config in Firefox.
There is always old-school Opera’s approach, which was essentially to always ignore cache control headers on forward/back operations, and preserve form fields. I don’t recall if it worked for sites that injected content into the DOM after loading (continuous scrolling, loading comments after loading), but it worked quite well for form fields.
How an OS needs to organize its data will always be complicated and obtuse, and you’re always going to need to hide the complexity with a layer. You can keep having brilliant ideas about how things should look and work, but the fact is at some point you’re going to have to translate those ideas into data structures. You can’t not have layers.
Ah so you’re one of the 100+ guys they hired to replace that 1 guy that already knew how to keep the system running but they fired him due to cost cutting measures! Nothing against you though! More power to you for learning old systems and keeping them running.
Bank of ‘Murca is guilty of this at the very least I believe it was… they pissed of the 1 guy so much he didn’t come back to maintain their systems once they did start failing so they had to hire tons of people to brute force the problems.
Not as such, no. Basically a bunch of us were hired, but instead of making plans for skills transfer, they’re actually trying to milk the old guys for all they can and then they retire and it’s like “whoops, we forgot about the skills transfer when we had the opportunity”.
kwan_e,
I also work for companies that have this mindset, using code from the 90s and mainframe eras. However I often think they’re guilty over overestimating the risks of upgrading and underestimating the costs of maintaining legacy systems.
Who are we to complain though, a job’s a job.
Truth be told, a lot of that code is buggy and could do with a rewrite. But sometimes, better the bugs you know…
With mainframes, there are hidden traps. For example, COBOL and PLI have way more datatypes than today’s languages. Many different number formats that can’t simply be replaced with ints or floats because that data is stored on backup tapes.
Then you have really complex structure definitions that are just there in the COBOL and PLI languages but would require reimplementing the compiler’s logic if rewriting in C.
But like I said, it is quite unbelievable how much source code has been lost because these programs were written at a time before adequate source control and you do not want to waste any time reverse engineering something.
kwan_e,
My personal involvement is usually integrating CICS transactions and mainframe datasets with external systems rather than writing cobal code myself. Those copybooks are neat
Some datasets contain binary fields, but I haven’t seen very many. More often numeric data is actually stored as EBCDIC text, making it possible for those “numeric” fields contain non-numeric garbage data. Modern databases don’t permit this.
Often times those numbers are stored in ones compliment to get them to sort in descending order. After a while you become trained to recognize one’s compliment dates 79839479. In all my years working on PC software I’ve never seen this because sorting is explicit and hexadecimal/binary numbers in twos compliment is the norm.
Edited 2016-05-20 15:58 UTC
I’m glad to see many people didn’t like the backspace navigation binding here. I’m also happy to see it’s gone on Chrome.
For so many years, I have a very weird feeling about that keybind however. I’ve always been wondering, if we go by the same logic of how the backspace behaves in a text field/editor, it should delete the current page so that ALT-<RIGHT ARROW> won’t be able to bring you back after (i.e. gone from history and cache).
Edited 2016-05-20 13:26 UTC
‘escape-from-pr0n-button’
Now in days before ‘incognito mode’ that would ‘ve been useful…
Thom Holwerda,
I hate loosing web form data (on FF). You are right it shouldn’t disappear on navigation.
However I generally don’t feel backspace should be overloaded anyways since I use and prefer keyboard combos to navigate/manipulate documents: ALT-left/right, CTRL-(SHIFT-)left/right, CTRL-pageup/pagedown, etc.
Do you edit text using mouse or keyboard? Here’s an untested theory. I’ve noticed some experienced users (usually on macs for some reason) use the mouse way more than I do for tasks that I never use the mouse for. This could make a subtle difference in preference, since my hands are usually in position to type the navigation shortcuts above easily & naturally (even more so than backspace). If I were more of a mouse user, then right-handed keyboard combinations could be more annoying.
Another theory is that some laptops have neutered keyboards, rendering them impractical for keyboard combos. I never want to use one again, but if I had to then maybe I would prefer things like backspace for navigation.
Immediate workaround: If Chrome focused on form window, a OneClick/OneEnter Message before any loosing data action?
Interesting comment about keyboard control.
It make me wonder whether this has more to do with when/how you were first introduced to computers.
I used predominantly macs since I was a child/teen in the 90s until about 6 years ago. I still haven’t regained the keyboard shortcut abilities I had on my mac. Maybe it’s just how I learnt things. Once I switched to other OSs I reverted back to more mouse because my shortcuts didn’t work anymore. I feel I kinda lost my power user powers
That said, since I installed a distro with i3 on my decrepit laptop, I’ve really enjoyed being able to do everything via keyboard again.
“…running an outdated timesharing mainframe punchcard operating system from the ’60s…”
My brother, “Comm and Electronics Engineer” came into computing with a pretty particular one of those Beasts [Fortran his first language].
He moved me into Basic with a totally theoretic approach. Only two Batchs of Punch Cards I got to Run at the Reader [One trowed an exception, never got to re-run the debugged code]. So busy that Old -Green Painted- Beast was. Those were thrilling times.
Time has come to new horizons both on OS and CPU architectures. To extend our very limited concept of computing.
What’s so hard about pressing Alt+Left (which exists since always)? It’s more consistent anyway because Alt+Right is forward. I welcome this change.
But then what would people on the internet rant about?
Personally, I would think that if the form contains non-default data, any attempt to navigate away from the page in an action that could potentially lose data might actually trigger a pop-up that says “Are you sure?”
Then again, Google chrome STILL throws “Pop-up Blocked” at me when I deliberately middle-click on a link, so it’s not like the google chrome programmers are that good at figuring these things out.
Because I have about 10 years of muscle memory dedicated to hitting that back key.
To navigate to previous page, the backspace could be replaced by: Ctrl or Alt + Backspace,
My two cents comment,
Nassos
It’s alt-left already.
I`m using www browsers since Mosaic and I had no idea, that backspace work that way! 0_o
This issue has existed ever since scripting was added to browsers. Hundreds of developers have tried to come up with a workable user agent solution – no one has succeeded yet…
Saving content on navigation sounds simple, but it does not make logical sense given the semantics of how forms work and the various ways scripting can affect them.
What if an input element fires an event on keypress that affects the state of another element? What if one of the fields fires an event when focus changes that affects state? What if the value of one field triggers a script to create another field? Forms are not static – browsers would essentially have to locally store and “play back” data entry – literally instrumenting the scripting on the page chronologically to recover the last state.
The browser can’t just “save the data”, the state of a form isn’t just the data it contains. The browser would have to save everything – literally every single event fired, in temporal order – all to maintain state for something that wasn’t designed for it.
Most developers do not and never have maintained state like this – because the whole point of the semantics of how html forms is that they are stateless by default. Forms were designed to optionally allow servers to maintain static state – having browsers maintain dynamic state is completely different…
Developers can (and do) add the ability to maintain state like this, but not everyone wants to turn a simple data collection form into a complex application they have to maintain.
There is no way to implement what you are describing in a way that would work reliably – i.e. it would break a significant portion of the forms on the web. You could certainly add another kind of data collection paradigm, but it would have to work quite differently from standard forms if you want browsers to automatically maintain state for them – probably meaning no dynamic behavior at all (i.e. very limited or no scripting support).
“…The browser would have to save everything [from the beginning]…”
Come to mind the myth of perfect REVERSIBILITY, indetermination of the historic status of the Server Session [as seen by the browser] and randomizing|encrypting functions. [Not to dismiss the full journey of interactions with other, competing agents, and forms -if users decide to interact with several at once-].
This issue is about our limits as scripters to anticipate all possible combined scenarios, as thrown up to the server by the users’ navigational wanders.
[Maybe with Erlang?]
Yet another option for browsers is that when backspace is pressed in any non stateless page, a lateral tab is created and historic previous is delivered in -read only- mode.
Of course, if the previous page is non related to the Session, then the Read-Only is irrelevant
…a lateral tab is created to the left of the actual half filled form, gaining focus also.
That child tab inheriting the history of the father.
That should go also for the “back icon” as Alfman points…
galvanash,
In firefox:
1. Open the test page.
2. Navigate to “A”.
3. Type A in both the textboxes and click on 1.
4. Navigate to “B”.
5. Type B in both the textboxes and click on 2.
6. Press the back button.
7. Observe that FF remembers the state of the first text box “A”, but forgets the second textbox.
7. Click on Alert, observe that FF outputs “1” proving that it saved the state of javascript.
8. Click on the forward button.
9. Observe that FF remembers the state of the first text box “B”, but forgets the second text box.
10. Click on Alert, observe that FF outputs “2” proving that it saved the state of javascript.
In firefox, the field behavior can be toggled by setting autocomplete to on or off as demonstrated above. For some pages it seems to default to on, and others (like osnews) it seems to default to off, and I don’t know what heuristics FF uses to make this determination and I find this inconsistency annoying.
It is unfortunate that that FF has overloaded “autocomplete” for two purposes, the other being to control the MRU list that shows up under text boxes. This means that on some search pages, the MRU list must be disabled because it conflicts with an AJAX autocompletion, but doing so results in all the search fields being remembered *except* for the main query field. The impossibility to get the correct behavior in all cases is a FF bug as far as I’m concerned.
This saving of state is *locally* consistent and behaves exactly as a user would expect. It also works with .net “viewstate”. Things could get out of sync with server side session variables, but that’s often a problem for the back button in general whether or not the fields are saved.
Edited 2016-05-20 17:55 UTC
That isn’t what I was talking about exactly. I probably should have been clearer.
What you described works fine (in Chrome too), but only inconsistently… It is simply the browser leveraging it’s internal runtime state in memory when it can to service history requests. State is different from history – history is just remembering where you went. There is no guarantee (or expectation really) that it also maintains state like this. The browser is simply offering it up when it can as an optimization, problem is it often can’t.
It is certainly nice when it works, but it isn’t reliable. Pages still active/pinned in memory certainly do have maintained state, but it is not recoverable state. If the page in fact needs to be reloaded, or memory is low and its flushed, or it has a no-store directive on it, etc. etc., this doesn’t work and the user ends up losing their data. This happens almost as often as not…
My point was really about the fact that form state (what the user did to the forms data) is intimately tied to the page’s state on the whole – all of it. They are inseparable.
What I was talking about were attempts to build a mechanism to fix this, maintain form data state independently, in a way that would allow it to be recovered even in the event of a full page reload. No one has managed to do that yet. It would use far less memory and you could store it efficiently, even across sessions if desired. This would be useful on mobile for instance (Where simply relying on it being in memory almost never works).
Edited 2016-05-20 18:55 UTC
galvanash,
Ok, I see. I agree the problem you are talking about is complex. However it isn’t necessary to solve it just to restore the fields after accidentally navigating to a page and immediately back. I think FF and chrome already handle this ok, or at least they would if it were always enabled by default.
I’ve encountered requirements similar to what you are talking about when trying to build analytics to follow what a user did while on a website. I haven’t found a way to do this efficiently in a generic capacity that can be reused everywhere. To make matters more complex navigation isn’t always a linear progression (with forward/back buttons, multiple tabs, etc).
The heuristic isn’t much of a heuristic, websites can hint the browser to not use auto-complete (if I remember correctly, there’s at least two ways to do this, although I don’t remember the specifics), although the browser of course does not have to honor this hit, but most do.
This.
The best browsers could do is to ask if you really want to lose a wall of text you just wrote, and even that would break javascript heavy forms.
Fixing the core problem would require getting rid of html and starting over with something that is not a static TEXT document at its core. At the same time we could get rid of css, javascript and http, and replace them all with something fit for purpose.
Sometimes I’d be typing out a long form and the page would go back. *What the fuck!? FUCK!* It must’ve been caused by this ‘Feature’.
Point here is that tabulator navigation is often handled by the scripter. And to easy to bug it. So many times the path is broken and suddenly you are OUT of field focus.
Trash! all of your capture if you missed that few pixel of cursor real state derailing and those tenths of second in between keyboarding.
The completely STUPID REPETITION, is that all this has been FULLY RESOLVED since beginning of times.
Never has happened since I’m on computing, on form interfaces.
But all that knowledge is embedded AND FORGOTTEN in old code. Good Code Badly Commented, Logged and Documented.
Safely betting most of this inconsistencies are on JS ‘enhanced’ forms.
Good. This has bit me so many times, and it’s so rare that I want a keyboard shortcut to go back, that I just disable it in Firefox whenever I am setting up a new install.
This isn’t 2003 anymore, and I’m sure we’ll see hundreds of addons to restore the backspace-as-navigation binding.
FlyingJester,
Thank you for mentioning that, I wasn’t aware such a setting existed but I’ve also been bitten many times.
http://kb.mozillazine.org/Browser.backspace_action
Also, Thom, maybe you should consider setting your forms to autocomplete=on to save the form state on osnews. I’ve verified this also works in chrome. So this might be a solution at least for osnews.
Edited 2016-05-20 17:52 UTC
Autocomplete defaults to on, and in Chrome, afaik, it has nothing to do with maintaining form state, it is for maintaining MRU values, not state.
I use Chrome, and the forms on this site already survive history navigation (assuming they are still pinned in memory when navigation occurs).
galvanash,
I see you are right. I didn’t notice because I normally use firefox. Unlike FF, it looks like chrome always defaults to on. How I love browser differences /sarcasm.
Edited 2016-05-20 19:48 UTC
The problems aren’t with the backspace key, per se, but with the underlying websites and web apps.
There’s nothing Chrome (or anyone else) can do about their behavior. Following a link and reloading the page are heavyweight events. But they can embrace the “Principle of least astonishment” by not having the BS key obliterate state, by removing the effect in the first place.
The BS navigation is more of a “power user” feature, as are most keyboard short cuts.
I’ve never used the BS for navigation, and more than once have lost state by pounding on the BS key. But not enough to make me want to pop the keycap off of it or anything.
Having it configurable, and by default OFF I don’t think is a crisis of conscience.
And we’ve always had an alternative shortcut which doesn’t interfere anyway. It’s even less of a problem, since we don’t lose functionality from the keyboard and we gain user interface consistency on top of it.
UI consistency is great in theory. The problem with it is that too many developers take it way overboard and force things on people. Most of them don’t get that a majority of users for everyday graphical applications like Chrome won’t change almost anything from the default settings unless they have to, and just providing defaults gives more than enough UI consistency. This whole stupid insistence on UI consistency over configurability is most of the reason I only use Windows for gaming (Modern game developers understand the importance of customizable controls) and use Linux for just about everything else. On Linux I can bind whatever key combination I want to do whatever I want, and I can actually work around stupid applications like most web browsers that don’t let you set keybindings.
Thom, your solution requires everyone to rewrite their websites.
Chrome’s does not and doesn’t have any bad side affects.
HTTP 1/1.1 is not supposed to have state. We’ve only given it state by throwing on the layers you say you hate.
Maybe the w3c or google should start on a stateful version of HTTP, but that’s outside the scope of this change. We can’t have nice things if we’re trying to save up to buy the Moon.
Good software does not exist.
Enough hyperbole there to make the architecture of advanced roller coasters jealous.
Okay if people haven’t already gotten irritated with Backspace issues, then they don’t use forms that often to begin with.
Personally I’ve gotten used to Alt+LeftArrow and Alt+RightArrow for Back/Forward functionality.
“Tons of keys have double functionality” you say. But Functionality has double shortcuts, as well. I’m of the opinion Backspace to go Back is in itself a flawed position forced upon us by earlier browser usage, and most modern browsers need to alleviate the baggage of the 90’s by offering better solutions, not by copying things that often aren’t user friendly.
I’ve learned how to browse without EVER hitting backspace except while in forms, and if a form EVER goes back a page while I’m hitting backspace, that page isn’t worth my filling out of the form. If they can’t get their own site together, why should I use it? Google is, if anything, nipping this problem in the bud.
Who in heaven’s name wants Google as an OS purveyor? They are a marketing company pure and simple. They do not have a clue about what makes a good OS. I go back to CP/M and yes I understand the punch card mentality. It has no place in today’s computing environment but a dinosaur is a dinosaur and they are really hard to get rid of. (BTW The analogy really fits – big, ugly, stomps around, eats everything in sight, impossible to control, cannot be restrained, crashes hard when things go just a little bit wrong, etc. etc. etc.) Try BeOS (Now HAIKU) or one of the new clones of AMIGA/OS (or even Commodore OS) if you want a clue about what a real microcomputer OS could possibly become.
Server OS is something else. A lean workhorse server would be nice.
If I get a vote, The best ever OS was the one developed for the IBM S/36; which morphed into AS/400 & iOS (before the name was co-opted by Apple). It was the best server OS ever built and was easily layered into a GUI. It made the best use of the hardware, was fast and intuitive. Unfortunately, not even IBM saw the potential and while still around (and secure, by the way!) it never caught on – too proprietary and like so many other developments in this industry, too good!!!
Oh please. If you want to run an incomplete, niche OS maybe. If these systems were so superior they would have taken off but they have not. They have some nifty features for some people but that’s about it. I tried BeOS when it was the all the rage and while it was a fun little system that’s all it was. Since then a lot of features were aped from it for other systems.
People care about programs. They don’t give a shit about operating systems. Look at all the people who would rather keep INIT in Linux than replace it with something sane. Why is that? Because they don’t care about advanced OS features. They care about advanced program features. Since you and I are posting on a site called “OSAlert” we are obviously not most people.
In fairness, the sort of people who would rather hang on to traditional init systems in Linux are also the sort of people who would post on a site called something like “OSAlert”. Indeed, there’ve been a fair few systemd debates here. People who don’t care about OS features, in contrast, typically won’t give a rat’s gluteus maximus about the process that gets their OS loaded.
I’ll bite and reiterate that even those of us who care about OS features don’t care about niche OSes for more than toys. There is nothing spectacular about BeOS or other niche systems. As I said initially they have some nifty features that have mostly been copied into more mainstream systems.
BeOS far from ‘toy’. Just not Internet ready -and wishful never will-.
Good OS not teether-able always needed.
If you want your phone’s battery to last for more than a day, buy a Oukitel K10000.
If you prioritise the wrong things when opening your wallet, you have no right to whine about battery life later.
No OS, punchcard-y or otherwise, will save you if you buy a phone with a humongous screen, hexa-core CPU with extra peanuts and whatnot and only 3000mah worth of battery or worse.
And even low-end SoCs run today’s OSes just fine.
Edited 2016-05-20 19:08 UTC
I use backspace to go back every day, and I don’t know how anybody screws it up. We’ve had like 20 years to get used to it
How can you NOT screw it up? It’s not like most people don’t know it is a shortcut for back but it’s necessary to press sometimes when form filling. Unless you are a perfect typist, and/or never accidentally click outside the form/accidentally tab, etc you will have made that mistake at some point. It’s a brain dead shortcut key for going back in the browser. Alt-Left is fine and rarely used anymore anyway. We’ve had tabs for a long time now.
Shrug. I guess the “never accidentally click outside the form” thing is me
Even if you are a perfect typist, you’re doomed if in fast capture and the page JS ‘enhanced’ page contains bug(s).
Removing backspace fixes the core problem, which is bad shortcut selection (as backspace is routinely used in text entry). The embarrassing thing is it took them so long.
Form contents can’t be reliably persisted across navigation, as it can be (and often is) generated dynamically from Javascript. Autofilling without website developer co-operation will always be sort of a hack that either works or doesn’t.
vivainio,
As long as you snapshot the DOM/javascript variables/field state together, then everything will be locally consistent when you restore them. The local page will be as though you never navigated away.
Firefox actually does this already, see my other post:
http://www.osnews.com/thread?629145
So the question isn’t really whether it’s possible but how many levels of navigation is it worth snapshotting like this and for how long? I’d say it’s worth doing for a least one level so that you can undo an accidental navigation.
Of course, even if the back button works totally fine locally, it’s often incompatible with server maintained state, such as trying to go back after committing a transaction. Many web sites say “don’t use your back button…” because there’s no way to disable the back button. Given that “GET” is supposed to be used to fetch resources without changing them and “POST” is supposed to be used to submit transactions, then arguably snapshots history should be kept for GETs but deleted for POSTs. However some platforms like .Net use POSTs even when there’s no server side transaction at all, so the back button is one of those things that neither the user nor browser knows if it is supported by the server ahead of time.
Edited 2016-05-20 22:23 UTC
This is only true if you are using ASP.NET WebForms and have wrapped everything on the page in a <asp:Form> tag.
Modern ASP.NET web frameworks don’t work that way they regular HTTP. Stack-overflow is built using something similar to ASP.NET MVC.
A better alternative is that developers use the new history API.
https://developer.mozilla.org/en-US/docs/Web/API/History_API
A lot of Websites could use pushstate, however this requires JavaScript to be enabled.
Edited 2016-05-21 09:39 UTC
lucas_maximus,
Ok, this gives an HTML5 webapp the ability to change the URL without performing a server navigation. To this end, you are absolutely correct that the loss of state is prevented. However the vast majority of web apps still depend on server navigation. So even if this is the better solution the point is kind of mute until all the websites get rewritten to do that.
So, given the lack of evidence that restoring fields breaks real world websites that would otherwise work, I can’t think of any strong reason for field values to not be restored. I’m confused about all the disagreement given how browsers like chrome are already doing it by default. Is your position that this should be removed from chrome?
Any dynamic forms can be problematic. It is somewhat of an annoyance when programming forms that even though you say the field values should be empty they are not. Also if you have specific requirements where the user should not auto fill the form it is another annoyance.
Sorry I don’t understand. Only older .NET websites that wrap everything in a form tag would have the behaviour of doing work on POST. However newer .NET frameworks work like RoR or Django.
lucas_maximus,
Well that’s kind of what I’m getting at. The back button used to be very predictable because all websites worked the exact same way. The proliferation of different kinds of web development models has rendered the back button fairly unpredictable in practice. Dave_K brought up the bank example, which I’ve seen too where instead of going to the previous page, it just logs you out completely.
You can rightfully argue that HTML5 features allow web developers to handle these problems, which is good, but how many web developers are actually going to do that?
Also how does this work with CSRF tokens? Because it must break forms which require time based tokens. That break any form that uses them (anything account based should be using them.
lucas_maximus,
Since the user doesn’t manipulate hidden fields, they’ll work like before. However it’s a good question because maybe some anti-CSRF implementations might not work with the back button in general.
If it’s a one time use token, then clearly it will break if you go back and try to submit again. That may or may not be desired. For the strict purposes of cross site request forgery, just having the token verified against their session is proof that the request originated from the correct website. So I wouldn’t think you need a one time use token nor a time limit unless you had other requirements in mind.
Edit: This is not exactly related to our discussion, but I found it interesting that these security guys found flaws in some frameworks using anti-CSRF.
https://blog.qualys.com/securitylabs/2015/01/14/do-your-anti-csrf-to…
Edited 2016-05-22 10:34 UTC
“… instead of going to the previous page, it just logs you out completely.”
..transmuting in a ‘logout button’, stealthily, without change to the UI. Like a monster
And every one of millions of users learn this the hard way. Confidence lost. Usability detriment.
Why hate on Unix? it works fine. You’re better off placing Your hatred at the Graphics stack/Java framework stuff. If phone code was written in C/C++ and assembler optimised for the hardware, the battery pack stuff you’re writing about wouldn’t exist. Relying on a virtual machine to short-cut your code writing time adds obvious unnecessary overhead.
I discussed the possible structure of a new ledger based OS titled “Pervasively Ledgered Encryption Based Secure Network OS (PLEBS NOS)” and submitted the set of articles to OSAlert 2 months ago. No feedback yet on whether the articles will be reviewed by OSAlert. In it I laid out the possible structure of a brand new OS using all the latest technologies. It is doable and I urge people who doable in Operating Systems to join the forum there and discuss.
So I don’t expect people to continue complaining about crufty OSes anymore and urge you to start coding for this new OS.
“http://lifestir.net/groups/12“>Pervasively “
A task beyond my very limited capacities. Nowadays wishing you best luck on finding interested ACADEMIC reviewers, as an excellent start.
Don’t repeat mistakes and design respecting Law Frames.
What.. what the hell does this even mean? I dont’ understand.
He is saying Unix was originally written in the late 60’s and a lot of the things still based on it just trudge behind a lot of legacy things and are full of unnecessary bloat.
The fact that smartwatches have more RAM than the desktop I had in 2001 running 2k advanced server tells me he probably has a point. The minimum requirements for windows 2k were 133 MHz CPU and 32 MB of RAM.
Modern smartwatches are using efficient 1Ghz CPU’s and 512MB of very fast RAM to do a fraction of what old desktops used to.
Windows 98 could be slimmed down onto a 100M zip drive removing some useless stuff. Creating a modern operating system for under 100M today would be considered an insurmountable feat mostly.
Edited 2016-05-21 08:51 UTC
Ever heard of Damn Small Linux? 50MB.
Most people on the go are indeed very light users. Big exception being Browsers at issue. [and welcoming Opera initiative].
But Browsers can be ‘Per Site’ administered to be very low drain [among many other due power duties]. Just disabling JS and auto-reproduction here drops my wattage to a breeze.
So additional battery packs UNDESERVED PENALTIES on the user.
That was my take on Thom comment.
“…the complete failure of modern software development…”
To WHO are developers being complacent?
Not US consumers and users. That’s for sure.
It just means Thom is pissed because his edge-case use-case was removed.
I’m glad to see Chrome do this. Using backspace to both delete text and navigate back in a browser would make my list of the top ten most utterly moronic UI decisions of all time.
It’s particularly annoying when using some secure sites (e.g. online banking and credit checking), where hitting the back button throws you out of the website completely.
On some sites it can be less than obvious whether certain fields are directly editable (e.g. date and title fields that auto-fill then have a little drop down menu for selecting an alternative). You tab your way through a form, spending half an hour filling in information, then lose the lot because you hit backspace in the wrong field.
I’ve found it a particular annoyance when using certain laptops that are prone to registering a click if you brush your palm on the trackpad while typing. I can think of few times when I’ve hit backspace before noticing that focus has left a text box.
Of course I can disable this “feature” on my own PC, but most of my online form filling is done at work in Internet Explorer, running on a terminal server accessed remotely through an encrypted laptop.
Yes, there are other keys that have dual purpose, like using space to scroll down a screen, but none are a potential self-destruct button like backspace.
I don’t understand people who don’t like this change. Backspace to go back is probably the absolute worst shortcut EVER created. I think everyone has been bitten by the backspace issue when filling out a form and who the hell even uses back in the browser that often where using the button or alt-left is that big of an issue? With tabbed browsers back is generally used very sparingly but form filling is extremely common in this day and age of internet forums, new comments, facebook, twitter, etc.
Wait.. lets go back a moment.. what’s wrong with punched cards again?
For all who find using backspace for navigating back a good thing; how about using Enter to submit a form (unless you are in the text field of course, where Enter just goes to the next line)? :/
I’ve never used the Backspace key for other than backspacing in a text field, and if I lost a huge pile of data (e.g. a job application entered into one of those online job app forms) because I hit backspace, I’d be mighty pissed off. I can’t remember the last time I used a browser that had this ‘feature’. Though I do find losing the contents of forms because I scrolled back by mistake (you can do this also by swiping wrong on some devices) annoying, and it happens on some forms but not others, and yes they should remedy it, but getting rid of the Backspace feature (at least make it an opt-in feature if people desperately want it) is not a bad thing.
As for the punchcard thing, I vastly prefer any Unix system (smartphone or desktop) over pretty much any Windows OS. If anyone can develop an OS for today that’s as good, let’s see it. The model may date from the 60s, but how much original code remains and does it matter? If you’re using Linux (as does Android), there’s not much that dates back from before the 80s (the 90s in the case of the kernel).
Actually whole IT world is going… backward.
“The Cloud” madness is just another reincarnation of “mainframes” or “big machines”. People just have very short memory.
PS: but to be honest I’m not using backspace for navigation for many years already. I’m using mouse gesture or “back” button.
Edited 2016-05-22 12:54 UTC
Yeap, but “the cloud” runs on huge distributed clusters of commodity hardware instead of one big centralized proprietary iron.
Also, all the software to run “the cloud” (OpenStack) is open source and vendor neutral. It’s exactly the opposite to the mainframe world.
And to me, that’s real improvement, not going backwards, this is a huge forward.
“Good software does not exist.”
I don’t always agree with you, but on this, you and I are in complete and total agreement.
Silver lining? Once the rate of chip improvement dies down a bit, at least the more general purpose aspects, we’ll be more or less forced to transition to software that sucks less. If we’re lucky, it might even be good.
For a guy who runs a website dedicated to software Thom you have turned out to be a complete whiner about software. If you said “no software is perfect” or “this is a mistake and here is why” that would be perfectly reasonable but your melodramatic declaration that there is no good software is just ridiculous.
Whiner or not, software is a mess… Thom is just telling the truth guys!!
The solution to permanent data loss in web forms cannot be “hey, we changed the shortcut! Problem solved.” That’s not serious, in fact, it’s hilarious!!
And it’s not a matter of “perfection” is a matter of common sense. Thom is the innocent kid telling us: “hey! the emperor is naked!”.
And the biggest problem is computer people don’t get it, We really don’t get the problem. Just take a look to all this thread… I’m gonna cry… software needs more Thoms and less “computer geniuses”. We suck.
1) No one claims this is a solution to permanent data loss in web forms.
2) No one claims the problem has been solved once and for all.
What this is:
1) There is a behaviour that is causing more pain than its worth.
2) There is no existing solution that will be accepted by everyone or every webapp or every browser.
3) While this behaviour exists, it will continue to cause problems.
4) When you have a fire, you use the fire extinguisher. Not sit around debating an update to the city’s fire and building codes. You can do that later when the fire’s out.
word. that this is the end-all of software fixes is a strawman for, again, *whiners* so they can keep talking about how chrome, which works well in 99.99% of other ways, is “terrible”. Give me a break.