i am creating a page with back button in corner. if the page launched for first back button should hide. if user navigates through page back button should show.
i used the code
(window.history.length > 1)?$("#back").show():$("#back").hide();
but my problem is,
window.history.length is keeps increasing.
But my requirement is when there is no page to go back then back button should hide again. how to achieve that?
you have more problems. what if the user came from google? there would be window history already. What if a user went to your site, then went to google, then came back?
If it's just a nav system as described by #Marc B, it's easy, you know where the user came from and how to get back (don't use the history directly). But if it is a back button no matter what link the user clicks into your site... it gets more complicated. Due to privacy restrictions, you can't access the user's actual URL history (just the length) and you can't access whatever url they are navigating to if you use capture the window.unload event. So you're left with limited options.
One option would be to record the window location on every page load to an array that you keep in either local storage, or a cookie. Then you should use this array to manage your history state rather than relying on window.history. When the user clicks your back button, you just pop off the last url on your site they visited and navigate them there. Keep in mind the first page load will put an item into your history array, so depending on where you check to see if you should show or hide your history button, you'll compare the length of your history array to either 0 or 1.
Related
I am writing a Single Page Application in JavaScript. The URL changes but there are no page reloads.
In my app I have a browser-like navigation with a back button, that actually runs window.back() . I also keep a backCounter variable (increased every time a user clicks on a link or goes back, listening to popstate) to make sure that the app back button doesn't let user go a blank tab.
I realise that ther are security implications when reading the history, and I have read answers here about it.
Question: is there a reliable way for me to know when the user has pressed "back" within the same SPA? I can think of two possible paths:
Neutralise. I could maybe neutralise the function of the back button by forcing a specific location on popstate
Integration. I would love to be able to know if the user has clicked on back or forward so that I can update backCounter accordingly.
...ideas?
I'm working on a mobile commerce website, and the nav pages have an annoying quirk.
The nav page for each product category shows links for all the subcategories that work pretty much as you'd expect, except for the "Show All" subcategory. If the user clicks that link, instead of navigating off-page, the subcategory menu collapses and the first page of products (which was there but cleverly hidden all along) is revealed.
The problem is that if the user visits a product off of that page and goes back, the page resets itself to its "Show-Nav-Don't-Show-Products" state -- not what the user is expecting. I could set a cookie telling that page to stay "Show-Products-Don't-Show-Nav" once it has been put into that state, but that creates non-intuitive behavior if the user navigates back via other means (such as the breadcrumbs, or re-visiting the home page) and would like to see the subcategories list instead of the products.
I tried setting a hidden field on the nav page that gets set when you expand the products, on the theory that it will retain its value if you visit the page via "Back" but will get reset if loaded any other way. That only works in Chrome; it doesn't work in Safari and other mobile browsers.
I'd settle for something that detects when the user is visiting the page via the Back button and makes what should be a pretty accurate guess about what state the user is expecting, but questions like this one (Can I detect when a user gets to a page using the back button?) make me think there's no good way to actually detect when a user has arrived via the back button.
Obviously, this is not a good design. But given that my job is hunting bugs, I'm looking for the lowest-impact solution I can manage to minimize both the time I spend on it and the chance of regression errors, so refactoring the code isn't a good solution.
Does anybody have any ideas for how they'd approach this problem? For what it's worth, I do have access to jQuery on this page.
I have a page where navigation is handled by hiding and showing preloaded divs when users click on links. But, the users think they've actually changed pages, so they click on their browser's "back" button trying to go back to the div that was previously hidden. But of course, they go back to the page from which they came.
What's the best way to handle this? 90% of the traffic is from a login page. Should I just sandwich a redirect page in between the two? How is this done? Can I just change the browser's back button behavior?
If you are already using jQuery, why not simply add a history manager like jq-bbq or the hashchange or history manager? (Or, if you want to really go all out, switch to a MVC JavaScript framework like Sammy.) That way, the back button will work as the user expects, rather than hacking around their expectations by blocking the back button or throwing in redirects. (Unless you have a good reason to, of course :-) )
If you use a browser history plugin like the jQuery UI one you end up changing the history so that the back button doesn't actually unload the page.
http://yoursite.com
-> User clicks something
-> new address bar reads http://yoursite.com/#/something
because of the hash mark when user goes back it goes back to http://yoursite.com which should inturn fire your show previous div function
read more about the available history manager plugins available for jQuery. There are quite a few. Most if not all provide available callback functions that you can specify.
On change of the state of your page, write a unique set of parameters to the hash of your URL. You can change this via JS without causing the page to reload.
Set a timer on the page that checks the current location hash repeatedly, and if it changes (i.e. the user presses the Back button) then update the state of your page to match the URL.
I have this scheme working to great effect in a local application.
The jQuery Address library is another great alternative.
http://www.asual.com/jquery/address/
You can set the URL for different application states, and get the URL 'parameters' when the page reloads.
Two ideas:
1) onbeforeunload. Ask the user if they want to really go back.
2) Sandwidch a redirect page. Login -> redirect -> your page. A single back click would take the user to your redirect page.
The second is kind of a pain in the neck for people who know what they're doing though. I think the Back button (and all standard navigational elements) should be messed with as little as possible.
I would go with onbeforeunload:
function sure()
{
event.returnValue = "sure?";
}
...
<BODY onbeforeunload="sure()">
How do I insert an entry into browsing history so back button goes to different page 1st click then original page on 2nd click?
So if you need a good explanation of what I want done, go to:
https://secure.exitjunction.com/howitworks.jsp
I just need a script that will allow me to insert an entry in the browsing history so when back button is hit, the user will be taken to my special page.
Here is a link to a jQuery Plugin:
jQuery Plugin
You can't directly manipulate the browsing history.
Such a feature would be seen as a security hole (and it would be), so I doubt that any browsers would ever implement it.
You might be able to hack around it however by doing something like this:
NOTE: This entirely hinges around the assumption that the referrer will get changed by the back button. I don't think this actually happens, so it more than likely won't work, but hey.
You have two pages, PageA and PageB.
The user hits PageA
The page (on the client, using javascript) checks the HTTP referrer, and if it is not PageB, then it immediately redirects the user to PageB.
Now that you're on PageB, if the user clicks the back button, it will go back to PageA.
PageA will check the referrer, it willmay be PageB, so there is no redirect.
I'm using an iframe to display content that has links. When the user clicks around in the iFrame and hits "back," it goes back in the iFrame. This behavior is OK. However, once they're back to the first page of the iFrame and they hit "back" again, the entire window is taken back to the previous page. This is unwanted.
To prevent this behavior, I've put a fake "back" button within the iFrame. (In most cases this is bad UI, in this case, it works well). I'd like this fake back button to only go back if the previous page is the iFrame's page -- not the entire page. When they hit the fake back button in the iFrame, it should only move that iFrame back, nothing else. Is there a way to do this? Does an iFrame get its own history object?
Something that might be of benefit: the domain of the iFrame and the main window can be assumed to be distinct. So, if it's possible to read the "global" history object, I can check to see if the previous page was mine by checking to see if the domain is mine. If the domain is not mine, the fake back button will be hidden or not do anything.
Help greatly appreciated, and happy holidays!
document.location.href = document.referrer;
You should be able to use the javascript history object to push the user back; but you won't be able to stop it when the iframe-clicking runs out and the main page wants to go back. And you can't stop it because that's intentionally locked down pretty well in most browsers to prevent people from messing around with it maliciously.
You could write your own history tracking code and have the back button pop items off that stack, stopping when the stack is empty...
If you're using some complicated nesting of links - perhaps some javascript-based tree menu? That way the iframe never has a page refresh?
Without having an example, I have to say your design seems like poor UI... when I hit back, I don't want the navigation to change; I want to go back to whatever page I was just on.