I am running a script locally and in one of the functions, it goes to different page. Once it does that, I want it go to back to previous page and continue running the script locally.
Is there a way to go back to previous page without refreshing the page.
I used parent.history.back(); this goes back to previous page but refreshes the page so my script stops running.
Is there a way to go back to previous page without refreshing the page?
TL;DR - The short answer is "No"
There is no way to go back without "refreshing" the page.
"refresh" is a somewhat vague term without an exact technical meaning ...
Going "back" by any means, whether it's the browser's back button or your .history.back() tells the browser to load the previous page it holds in its history.
Whether the page is loaded from the browser cache or re-requested from the server is up to the browser, not up to you.
In any case, it is again up to the browser whether it will re-parse the DOM and/or re-render the page. Which, in reality, it is going to do.
Any of these could be called "refresh".
At that time, however, the browser will start parsing and executing any scripts present. It will not continue wherever it was in the scripts at the time the page unloaded under any circumstances.
The page the browser goes back to is the HTML text as it was received from the server, but scripts could have significantly modified the DOM after the page was loaded. Those scripts need to run again, from the beginning, when the page is reloaded by going back.
It's conceivably possible to write a browser that saves the DOM state and js execution state when you leave a page, and restore that state when you return, but no such browser exists.
Depending on what your actual goals are for this, there are many things that could be done such as pushState() and replaceState(), single-page web applications, XMLHttpRequest, using <iframe>, etc. where you could replace the current page content (DOM) with other content without actually going "forward", and restore the saved DOM later when you "return" to the page,
but that's far too large a topic for a Stackoverflow question.
I'm not 100% following your question, but from my notes I can offer you this:
// To some url
window.location.href = 'some/new/url';
// To some url without it effecting browser back history:
window.location.replace('some/new/url');
Related
Doing some Intranet development. The design approach uses a basic HTML framework populated with an ajax call (via jQuery) to populate the page. We've standardized on Chrome for Intranet access. The intranet allows the user to open PDF documents linked from the page in the same window, and then use the back button to return. Our old "static" page approach retained the prior page contents - the new dynamic approach reloads the page. How can we retain prior page content?
Research has found similar problems, but not a clear answer. We've tried checking for an existing element in the onload() event; doesn't work because the page load is already triggered before that code gets evaluated.
The code is working correctly - our desire is to return to the already rendered page.
No errors. Getting page reload with the back button when we want to return to the already rendered prior page.
You could modify the url via the history api when you are changing the page content. This should be enough as history gets modified so the back function would work properly. However if this doesn't work you can use the url to determine what to show up on the page.
Here's an example: https://css-tricks.com/using-the-html5-history-api/#pushState-example
I'm having a performance issue on my web application when the user hits the "refresh" button on my webpages. The behavior is shown below:
$("#reloadbutton").click(function(){
location.reload();
});
It reloads all of the CSS, JS, and image files that the page needs, as it should. The only problem is that it does this for every other page request, such as clicking on a link to go to another page.
If I just hit the F5 button, it'll reload all of the CSS, JS, and image files, and then if I go to another page, it won't try and reload those files once I go to that other page. But if I hit the reload button on the page itself, it'll reload all of those files on every page request, and I don't want it to do that.
So I have a two part question:
How can I refresh without having the browser fetch all of the CSS, JS, and image files (because I want to minimize the time it takes to refresh each page)?
Why am I getting different behavior when using location.reload() as opposed to using the browser's own reload button?
Note: I'm currently using the latest version of Firefox
use the
$("#reloadbutton").live("click",function(){
location.reload();
});
and you can do this by making ajax call after every some second
$("#reloadbutton").click(function(){
location.reload(false);
});
As per the Mozilla developer network, location.reload(); can take a parameter. When it is true, location.reload(true);, it causes the page to always be reloaded from the server. If it is false, location.reload(false);, or not specified, the browser may reload the page from its cache.
I am building a web application which I intend it to work like a traditional 'software': as few page reload, and page redirect as possible.
My solution to page reload and redirect is to have them as 'tabs' within the app, so when you click on another tab, the div of your current content will shrink to 0 width.
My question is: how do I prevent the content (writtent in JS, w/ PHP backend) in a tab to load unless when it's clicked on?
(Assuming this is what I should do to reduce unnecessary load)
Just don't load it until the link/button/etc. to the tab is clicked.
See also the jQuery tab implementations.
If your back-end is in PHP, you should control what you send to the client from there.
By the time the js gets the code, it is too late to control what not to load. You can hide it, or remove it, but it has already been loaded.
So, to reduce unnecessary load, and as a good practice, you should only send to the client the active 'tab'. That has to be done in PHP in your case.
We need to implement a mechanism to persist information between web pages in the same session. There is a lot of information on the client-side and passing it back and forth to the server across requests is something we want to avoid. HTML5 local storage is one option.
The other option mentioned was "using a hidden frame where the data is kept". I am not sure what this option really means.
Does it mean keeping a hidden frame that holds on to the data across page requests?
How would this be accomplished? Are there any jquery plugins or sample code I can look at?
What are the advantages and disadvantages?
I am not aware of a way where you can keep data in the main page and use a hidden iframe/frame to persist data. This is because once the main page is reloaded (when you go to another page), everything in the iframe is lost.
You would basically use the main page as your data-storage location. On top of the main page, you would superimpose an iframe. The user would interact with your site through the iframe. From the user's perspective, there is no difference. You can persist information by writing to the parent frame (the main page). Since the main page is never getting reloaded, you can persist data inside it.
I am not aware of any Javascript libraries that do this; I will take a look though.
Keep in mind that this might affect SEO and possibly navigation (not back/forward buttons). Another point, as Guffa noted, is that users cannot share links to your page since the URL in the address bar never changes (all interaction is via the iframe). So when your user sends someone a link, they will end up at the very first page.
You can't keep a frame from one page to another, so the only way to use that is to make the frame cover the window and load the actual pages in the frame. That way you can keep the data in the surrounding page that won't be replaced.
This of course means that you actually never leave the page. The URL in the location bar remains the same when the content changes, so you can't bookmark a specific page or share it with others. Search engines will link to the content pages instead of the frame, so anyone finding your page that way will end up on a non-functioning frame page.
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.