On product list page in pressing the reference "buy" , I add the article to cart with a help of Ajax and put down Article Id to document.location.hash.
When I delete the article from the cart and return with a help of the button "back" in the browser , I need to delete product Id from location.hash on product list page.
Is it possible?
Nope. You can't modify history in browsers by design, imagine what security impacts that would have? You could, for instance, push something in to the history and issue a history.back() to send the user wherever you want!!
You must handle the back-button stuff in the session server side with some state controller.
Add: when user hits the back button, the page is retrieved from cahce or from the server, depending on the header information etc. The browser has already rendered the page whenever your code will start running. Modifying the location object then would result in an additional page load/reload. If you KNOW that the ID is invalid, there's no need to delete it from the location hash, you might handle that within the server code.
Related
I have a line of code:
location.href = 'payments/basic.php';
It works fine, but a user can simply press the Esc key to cancel the operation. I tried to use an event listener to prevent the Esc key from being pressed, but it only works while the user is on the initial page. As soon as they are being redirected, it stops working and they can quickly press the Esc key or the big X beside the address bar in their browser to cancel the redirect.
Is there a way I can completely prevent that?
Edit:
The reason I want to do this is that upon login, they are automatically sent to the index page. I have a flag in my DB which checks if a user has made payment. And then on the index page, I have a little script that queries the DB to check if the flag is true or false. If it's false, they are immediately notified that they are being redirected to make their payment. If at this point of redirection, they cancel, they will be able to remain on the Index page without payment.
I think the only way to prevent the Esc key from stopping navigation is to not navigate away from the original page at all. Instead of doing
location.href = 'payments/basic.php';
make an XHR or fetch request to basic.php, and populate the current document with the results, instead of loading an entirely new document - just like how a SPA works.
(You will almost certainly want to make some changes to basic.php - eg, have it return easily-parseable JSON containing the data to populate the page with instead of an HTML document)
Regarding the edit
upon login, they are automatically sent to the index page
If at this point of redirection, they cancel, they will be able to remain on the Index page without payment.
If you're trying to prevent access the the original page, then just don't serve the original page until you've checked the flag in the database. Don't serve the index page to begin with until you've validated the user's credentials. If they aren't authorized, redirect them in PHP (not in JS) to the payments page. No need to mess with the user's escape key.
Why not do it the other way around?
Default to the payment page, if payment is already made, then redirect to index. lol.
I am working on a website, where url parameter gets updated based on user action, according to which I update the webpage without refreshing.
Consider the scenario of E-commerce where url changes when user clicks on filters and then updated products gets displayed.
Now the problem is, when user clicks on Browsers's back button the browser goes back to previous url-parameter, but page did not gets changed. I want to change the page also based on url parameter that gets changed after back button clicked.
I have tried this solution:
$($window).on('popstate', function (e) {
// Update the page also
});
The problem with this code is, this gets fired as url changes, means it does not care about if browser back button is clicked, or url is changing using the jQuery. So if I am changing url based on user interaction, the popstate callback will be called and my custom function also. To update the page I am using https requests, so http api gets called two times.
Is there any way to check if only "Back button" is clicked?
I would recommend you to change your design a litle bit and trigger all content updates (the product list in your case) by listening to url changes, not only url changes caused by the back button. So instead of triggering any re-rendering on click events, let these buttons be regular link to the url that represent your content and trigger the functionality from the popstate event.
This is how all MVVM-frameworks like Angular.js, Backbone etc are designed and meant to be used.
By doing this it will also be so much easier for you to maintain the application in the long run.
Good luck!
You can do this with sessionStorage! Below is the relevant part of an answer I always refer to for stuff like this https://stackoverflow.com/a/45408832
sessionStorage is a storage type like localStorage but it only saves your data for the current tab.
Session storage can be used like this.
sessionStorage.setItem('key', 'value'); //saves the value
sessionStorage.getItem('key'); //gets the saved value
performance.navigation.type is the browser is the variable that hold users navigation info.
if(performance.navigation.type == 2){
//User is coming with back button
}
So to put it all together, you can set/update a sessionStorage item as part of the callback of the click event for your filter, then performance.navigation.type to check if they used the back button to load the page and apply the data!
I want to know what is the best way to store and retrieve datas only after clicking the back button Browser ?
In my case, you have a list of items (different for each categories I have on my website) that appends in angularJS with the ng-repeat directive, and you can filter these items by clicking on the checkbox inputs. Obviously, each checkbox has a specific value corresponding to a filter.
When the user click on an item, it redirects you to an article (such as a blog post).
May be the user doesn't like this blog post so he clicks on the back button of his browser to go back to the item list.
But for now, I don't store checkbox tags that have been checked before and the items filtered.
I try with localStorage and sessionStorage in JS but datas are too persistants with this method.
I could make a trick like retrieving the datas if the REFERER matches with a specific url pattern, but it seems to be too tricky..
So any of you has a better idea ?
Thanks in advance.
You can use the state object for this purpose. This one is accessible via history.state and will change when a user navigates to somewhere. It will also be restored when using back button etc. It is can be seen as a storage object that is linked directly to the url.
I have a few divs on a form that are hidden by default (style="display:none;"). When the user clicks a certain radio button, an onclick event executes and exposes the divs. The user is then taken to a review page upon form submit that shows him any errors. If there are any, he clicks the BACK button on his browser to go back to the form and correct them. Caching is enabled so that all of his form contents are there. The problem is, since the form is looking for an onclick event, all of the previously exposed divs are hidden again. Is there any way to make sure they stay exposed when the user clicks back to the form from the review page? I thought a document.ready function would do it, but no joy.
As Yair mentioned, you can use cookies. It cannot be done with pure JS. However, you can also use PHP.
Before the user is transferred to the second page, have JS scan the divs in question, and find which ones are visible. (I'm assuming they all have individual IDs). Store these IDs in a comma-delimited string, or array, and send it as a _POST or _GET to the new page.
Have PHP store it as a hidden value somewhere. You could use a hidden input, or a data-x on something ... as long as it's there.
Have JS on that page that watches for the back click, stops it, and then redirects the user to the previous page, and sends the string or array back to it. Have PHP on that page print it as a JS value, and have JS on pageload show all divs with matching IDs.
Cookies or localStorage if you aim for only modern browsers:
localStorage
Is there any way to make sure they stay exposed when the user clicks
back to the form from the review page? I thought a document.ready
function would do it, but no joy.
You can use cookies in order to manage state in a web-browser. Cookies will help you save the desired user's state.
All javascript code is reinitialized on browser reload. You cannot identify whether the user comes back through the browser.
You can use cookies or local storage to save a value when initial display happens and show/hide the div later on document.ready.
I am building a small web site, and on one of the pages there is a d3.js/highchart visualization demo. The visualization is interactive, and can be modified by the user.
When the user leave this page and enter another html page by following a link in this demo page, the content of the page is not saved, and when he comes back, he has to modify the chart again. My question: is there any way to cache this demo page so that as long as the user does not close the browser page, it can be recovered?
My simplest idea is to have each client page a unique ID. So that I will save the status of the page when the user leaves, and when he comes back I can cover its content based on this ID. Then the question is how to implement this ID for client pages.
You can use History API here.
When a user changes the state of the chart, the page URL is updated with all the parameters needed for rendering the chart (via history.pushState call).
On page load you get the initial state (chart parameters) from the url and render the chart correspondingly.
A good thing with that approach is that you even can send such URL to another person, and they will see just the same customized chart.
You could also try storing the page state locally using either sessionStorage or localStorage (DOM Storage guide)
If you have two or more tabs I don't think there is a way to differentiate between then once they are closed. I would use Steve's idea about storing the ID in DB+cookie and when user come back to page I would provide them with a list of all their past modified charts based on cookie and DB query. Then they can choose which chart they want to reopen.
I can think of many ways to do something like this.
If it was me, I would simply store the users chart settings in a cookie, so when they navigate back to the page, you can simply read the cookie for the settings and use them to re-display the chart.
If you want to persists this longer, then send the settings to the server to be stored in a DB. The server can return a unique ID which is then stored in a cookie, or simple use the session cookie to associated the chart settings with a session.
An alternative which doesn't use cookies is to add chart settings to the 'back' url when you navigate away. When the user clicks to go back, the url contains the information necessary to restore the chart states. However, this doesn't work if they click the browser back button.