It's my first HTML/javascript question which I raised on meta without results yet,
On Stack Overflow I reload my tags page which displays questions related to my selected tags.
If I want to go back to the previous results/page with a reload, then a question I wanted to check isn't possible because it's going back in history to a different page (or a blank page).
Can I go to the previous view? Is it impossible?
Sometimes questions are deleted or have changed tags so it's hard to find them.
Is it possible in javascript/HTML to view last results?
I've been in the same situation many times, wishing to see what I just saw but the internet has changed out from under me. (It actually happened while I was researching this answer...) Obligatory XKCD: https://xkcd.com/1309/
Let's talk a little about what this question is actually asking? The example given in this question is this very site, SO. But the purpose can apply to any website with dynamic information. As a user browses through information, an often used pattern is to link into more specific details. When the user moves back to the general list, it sometimes occurs that new information has been added, or old information removed, or just generally moved about. In those cases, it can be difficult for the user to navigate back to information they may have wanted to look at or they have looked at but now lost the link to. We ask what can be done to make this UX better both in the user habits and the website design.
I think this question truly does apply to both meta and non-meta, since there are many aspects: what can SO specifically do, as website, to improve their UX (the meta question); what could developers of sites do in general to improve UX in this regard; and what can user do to better utilize their technology or improve their workflow to improve their UX without special consideration from a website. Let's talk about what the user can do first.
What can a user do?
In some senses, this should be a simple task. All the browser would need to do is keep a record of the current DOM in it's cache when moving to a new page, then on back press, load the cached DOM as it stood when you last looked at it. But what do browsers actually do?
Browsers won't consistently help you right now by default. The answer by Stephan P gives us some insight. Essentially, going 'back' could result in a number of different things from loading the cached resources like I described above, to reloading some of the resources, to just refetching everything. And this is all decided by the arcane machinations of your browser. You have basically no say in what happens. (Except of course when you use one of the many methods to forcibly skip cache and reload all the recourses, but there doesn't seem to by any method to forcibly load from cache). So, no dice there.
The closest browser functionality I was able to find is the setting to load from cache when offline in Chrome. But this would require us to constantly switch between connecting and disconnecting from the internet while browsing. Which is not very helpful.
The above point actually just proves that this should be 100% possible,
if we could just look at our browser's cache of the page. Which we can! GolfWolf lets us know about the handy chrome://cache address that let's us view the complete contents of our browser's cache! Unfortunately, it is all in hex, so not super useful for browsing...
There are tools that will convert the hex dump to a viewable webpage as Senseful points us to. But I think, going into your cache, finding the old page, copying hex over to a translater, then viewing your page is not a very friendly workflow for regular browsing.
So, our browser is basically useless for what we are trying to accomplish. We only have a few options:
Write our own browser
Something very custom...
A. One potential would be to set up a proxy of sorts, that hard caches all the pages that went through it and returns from cache when you went back in your browser. Perhaps a simple browser extension button to click to send a message to the proxy to clear its cache?
B. While we're talking about crazy ideas... It could be possible to make a webpage that loads pages in iframes and attempts to intercept link clicks and instead of opening in the same iframe opens a new iframe to the new page and just hides the old iframe in its previous state, so when you go 'back' it just unhides your old page. But that is super cludgy and will break a lot of stuff with all those discontinuities. (and don't forget, not all links open a new page, there's a lot of ways this plan could go wrong).
Outside of actually solving this, what could we do to mitigate or work around our problems? ...Never leave a webpage... ever...
In all seriousness, this is my workflow: open the main page, open all links in new tabs (You can usually cmd/ctrl-click to quickly open a link in a new tab), keep all the tabs open until I've finished.
What can a website do?
Several things. There are many strategies that can be used to make information traversable, and they all have their own benefits and ramifications. This is not an exhaustive list:
The site can implement custom urls with parameters for everything that could affect rendering of information. Google search does this. In this way going back to a link (or just sharing a link to a different person) will result in loading the page in the same deterministic way as before. This can be used to great success, but also can result in inordinately long links.
The site can use cookies or local storage to keep track of where you are to restore your state when you return to a previous page.
The site can create its own history for you to browse. This is similar to what SO does now in other aspects, but taken to the extreme. Basically, record every action, every comment, every view, every post, absolutely everything. Then let the user browse through this history of things (obviously with lots of sorting and filtering options) to let them sift down to what they are looking for. i.e. "What was that post I was looking at yesterday? ...searching... Oh here it is!"
Each of these are huge topics on their own. Way outside scope of an answer here on SO.
TL;DR
A user can't do much of anything that isn't either a lot of work or breaks flow in one way or another, or both.
A website can do a lot of things to ease the user's pain. But there's no silver bullet. Only lots of work to make a good UX.
You can try to play with the ids to go back only with the browser, but if the question is deleted I think there's no way to catch its content if you don't use a web crawler software :/
https://stackoverflow.com/questions/48630484/
https://stackoverflow.com/questions/{ID}/ (it's an autoincremental id)
Related
Situation:
I have a sensitive website about domestic violence with an EXIT button that directly links to Google. So that anyone visiting that website can quickly jump to Google if the visitor feels unsafe or uncomfortable.
I would love to be able to clear any references to this website from bot the history list and the back button functionality. Basically, remove any proof of visiting that website. Keep in mind that not all people know how to browse anonymous and some people just cannot even get out of the house to browse the internet. Yes, this scenario is for seriously bad situations.
I've tried using location.replace instead of regular links to keep them from being saved into the history, but they just keep being saved in the history.
I've also tried to use browser.history.deleteUrl({url:"https://thewebsite"}), but this gives error on browser being undefined.
Is this even possible from a website? Or are there other options?
Thanks for thinking with me!
As you state in the question, you can use window.location.replace() to prevent your site from appearing in the window’s history (back button). Of course, this only works if your site had only one entry in the window’s history to begin with.
As you also state, there is a bigger problem: this does not prevent the site from appearing in the browser’s history. I believe you cannot solve this problem with scripts on your website: you need some external solution, like a browser extension.
(This does not really answer your question, but you could try using URLs and titles that disguise the nature of your site. I have heard of that being done with this sort of resource.)
In response to my idea of disguises, someone asked for examples and asked about discoverability. I was referring to the Aspire News App, featured on Dr Phil’s TV show. On that show, they made a big deal out of not showing what the app looked like, to avoid tipping off abusers. They also said the app is disguised as an ordinary app.
When I was researching this answer, I learned that disguises are indeed a terrible idea. I had no trouble finding information about the app online, and one review said the app is “pointless” because “with all of the media cpverage this app has gotten sbusers know exactly what it is and what to look for”.
I also learned that the app still had a fundamental security flaw 7 years after it was released. This shows that even supposedly reputable apps, dealing with sensitive matters, cannot be trusted. And perhaps it means that supposedly reputable websites looking to hide themselves from the browser’s history cannot be trusted either.
A newbie friend of mine thought of attempting to "secure" the website and protect the assets through something like this. I explained why it's not going to work but it got me thinking if there are actual legitimate reasons to disable right clicking in the browsers.
Off the top of my head:
Security is obviously not one as any determined "attacker" can simply disable/override the javascript, inject their own javascript/use Chrome's Developer Tools as they control the client. At best, it'll stop non-technical users.
Attempts at protecting assets such as images obviously won't work either as they could simply save it using their browser complete with the images, use View Source and grab the assets from there, simply do a screenshot, among many other things. It'll only really stop the really non-technical and lazy users.
Preventing accidents such as say, running a transaction again by right click -> back would simply point to a deeper issue with the site code so would be a band-aid solution at best. I suppose one could make an argument that this is one use until the underlying site code is improved.
For some more desktop-app-like pages, I've sometimes used right click for actions specific to the application. For example, a custom context menu or modified drag/drop action. This provides what mouse users expect in a convenient way. (Touch users still need an alternative, however!)
I would like to know if there is a way to prevent an html page with jQuery or javascript to be modified by the user to change its behavior.
A user can modify it using tools such as FireBug or the Google Chrome developer bar to hide or show divs, add event listeners to page elements and so on.
I've seen some web pages showing a blocking div when the page is loaded and a pop-up telling to answer some question. If you answer it, the div hides and you can see the page normally.
But if you try to hide the blocking div using FireBug, the page reloads and there is no way to see the page correctly if you don't ansewer the question asked in the pop-up.
I want to know how could I prevent user from doing such things.
Thanks a lot.
It is not possible (which is a very good thing).
To defeat the method described in the question:
You can use the keyboard shortcuts to the console/tools (Ctrl+Shift+I in Chrome)
You can use the resource/net panel to see the source
You can see it at any other level, e.g. Fiddler
You can use a bookmarklet for easier access
No, you can't prevent people seeing or modifying your source/script if they want to...the ones you most want to prevent are the most able to circumvent any deterrent (and that's all anything you do is, a deterrent, not a stop) you put in place.
The only way to do it (in my opinion) is not have the page content load until the user does your desired action. After he answers the question (or whatever) you send an AJAX request for the content (of course, as thejh said, you should also validate the answer on the server, preferably in the same request). So you load page header, banners and anything not critical, but the actual content (say an article on a blog) should not be loaded until the user does your action.
Everything that a user's browser receives belongs to the user, so you can't enforce anything on that.
For sure you can't prevent anybody from doing what he wants to, but you can make changes more difficult.
Take a look at the DOMEvents, especially the Mutation-Events.
Those give you the ability to see when something has changes(attributes, removed/inserted nodes, data in textnodes ...). For example you could build a function that watches some special attributes you would'nt have to get changed and reload the page, if this happens.
As others have already said, it isn't possible to control what the end user does with data you've sent them.
It may be possible to detect the console object that Firebug and others use, but what can your site do with that information once you've got it? You can't disable firebug or prevent it from being used, or even know whether it has been used.
The bottom line is that once the web page and javscript code have been sent to the browser, it is out of your control.
The closest you can get to what you want is to move some of your code out of Javascript and to the server, where it will be untouchable by the user. However you'll still have to have some client-side code, which will still be at the mercy of malicious users.
The other alternative is to move to Flash or something similar, where the end user doesn't have direct access to the code or the object model. This has it's own downsides though, and you'd be bucking the trend, which is to move away from Flash toward HTML5 and Javascript.
It's impossible. When you send code to the client, the client can look at it and modify it. Only code that runs on your server is protected aganist that.
I don't think it's possible to do that unless you can make sure (or force) users to use browsers that don't have developer tool.
Use ajax to get remote information don't send the user all the information such as answers to polls etc get the answer after he picked a choice from the server using ajax for example. Client-side validation is never a good thing hell thats how I used to delete other stupid people's databases due to that unless people learn properly how things REALLY work they should get taught the hard way such as losing everything in a case of root access vulnerability.
I don't know why HTML has to be blocked it wasn't blocked since browsers came out he'll I could make my own browser with a socket and get HTML transfered right to some textbox and see it in my favorite notepad/editor etc..
As for javascript you can simply send javascript commands in browser address bar (how convenient of browsers in supporting hackers hehe but it's also used for inter-op communication with other technologies such as flash so it has a evil/good side to it as everything.)
If you didn't know you can just do
javascript: alert('hi');
or if your javascript game or whatever has globally scoped variables you can modify em easily
javascript: score=9999;damage=99999;
etc etc like i said it's all good it weeds out the bad programmers and gets em fired or teaches em a lesson in the future.
I've seen many big sites still fall to a SIMPLE XSS attack (Cross-site scripting) which is just baffling how these programmers get a job, I'd do a better interview or some shit it's ridiculous
I am creating a website which uses jquery scrolling as the method of navigation that never leaves a single html page.
I have noticed that some websites are able to change the URL and have looked at posts/answers (such as How does GitHub change the URL without reloading a page? and Attaching hashtag to URL with javascript) which refer to these changes being either push states, AJAX scripts or history API's (all of which I am not too savvy in).
Currently I am looking into which method is best for my website and have been looking at some examples which I like.
My question is why do the websites below use /#/ in the path for the changing URL. The only reason I ask is because I am seeing this more and more often with jquery heavy websites.
http://na.square-enix.com/ffxiii-2/
http://www.airwalk.com
If anyone could simply shed some light on what these guys are using to do this, it would be much appreciated so I can possibly create my own script.
My question is why do the websites below use /#/ in the path for the changing URL
If we discount the possibility of ignorance to the alternatives then: Because they are willing to accept the horrible drawbacks in exchange for making it work in Internet Explorer (which doesn't support the history API).
Github take the sensible approach of using the history API if it is available and falling back to the server if it isn't, rather then generating links that will break without JavaScript.
http://probablyinteractive.com/url-hunter
This has a nice example on how to change the url with javascript.
I've not tried it myself, but read many reviews/opinions about History.js
It's supposed to have the "# in the path" option as you said (for older -- incompatible -- browsers) and the facebook-like direct changing of URL. Plus, when you hit the back button, you will get to the previous AJAX-loaded page with no problem.
I've implemented such a feature (AJAX tabs with URL changing), but if you will have other javascript on the pages that you want to load dynamically, I wouldn't recommend you using AJAX-loaded pages, because when you load content with AJAX, the JavaScript inside the content won't be executed.
So I vote for either HistoryJS or making your own module.
Well, they're using the anchor "#" because they need to differentiate between multipla bookmarkable/browser navigatable places in the site, while still having everything on the same page. By adding browser history events of the genre /mySamePage.html#page1, /mySamePage.html#page2 when the user does something that Ajax loads some content in the current html page you have the advantage of (well, obviouslly) still staying on the current page, but at the same time the user can bookmark that specific content, and pressiing back/forward on his browser will differentiate between different Ajax loaded content.
It's not bad as a trick, only issue is with SEO optimisation. Google has a nice page explaining this http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html
At my company most inventory tracking is done via an ASP.NET web application. The application is poorly conceived, poorly designed, poorly implemented, and somewhat of a hassle for a user to work with. These are things that are my opinion though and management has its own thoughts on the matter.
Such luxuries as the browser's back button and bookmarking pages are already not an option because of heaps and heaps of ancient Ajax code and now one of my bosses has the idea that he would prefer for the URL bar and browser buttons not to appear at all.
At first I told him that it was impossible but after thinking about it I suppose it could work if you used Javascript to create a fullscreen pop-up and run the application in that.
I personally am against this idea though since I'm the one who would do the work my own subconscious motivations are suspect so I'd like to gather some opinions on running an application in such a manner.
In addition, has anyone had any experience with transferring a regular webapp to such a setup? I'd like to know how much work could be in store for me.
Next time, for the good of the world, keep these kinds of ideas to yourself. It sounds like your boss is not qualified to make such a call, so make the call for him.
If your boss believes the url bar and browser buttons are not suppose to be there, then convert it to a stand alone app. Don't try to cram it into a web platform if its not suppose to be one.
You know the issues, so fight for what you think is right. Don't implement anything you are not going to be proud of.
You may find Prism intresting
Full Screen, no bars, just WebApp
I'd be tempted to simply add a button that allows you to pop out the app, without removing the normal mode.
If necessary, sell it with some waffle about users getting confused or not being able to reopen it or something. Or even pretend its not possible to do it without it.
That goes some way towards user friendliness. Salve your conscience anyway