I've made a search page for a client, but in this case the actual search page is in an iframe and the user is presented with a decorative shell surrounding said iframe, which passes its URL parameters to the iframe, which then interprets them and performs a search. This is something I cannot change. It also presents me with the unique problem that if the user types into the search page's search bar to perform another search, the iframe refreshes but the shell page does not. This means the URL is now no longer relevant to the current search. How can I change the URL in the address bar without navigating away from this shell page? The whole point of this system is that there is less wait for the iframe to refresh than the whole page, so refreshing the whole page would be counter-productive.
Full Solution
For anyone wanting just a code snippet, here's my final implementation of Ian's solution:
<?PHP
// ...
function buildTitleChanger($search) {
?>
window.top.history.pushState({search : "<?PHP echo str_replace("\"", "\\\"", $search); ?>"}, document.title, window.location.search);
window.top.document.title = document.title;<?PHP
}
// ...
?>
it's a little dirty with that inline PHP, but it works 100% of the time :3
You are able to change part of the URL with something like window.pushState. Take a look at MDN's explanation:
https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history
Browser compatibility: http://caniuse.com/history
A nice library that wraps these features and provides similar functionality in browsers that don't support it is history.js: http://balupton.github.io/history.js/demo/
An example from the MDN link:
Example
Suppose http://mozilla.org/foo.html executes the following JavaScript:
var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");
This will cause the URL bar to display http://mozilla.org/bar.html, but won't cause the browser to load bar.html or even check that bar.html exists.
Suppose now that the user now navigates to http://google.com, then clicks back. At this point, the URL bar will display http://mozilla.org/bar.html, and the page will get a popstate event whose state object contains a copy of stateObj. The page itself will look like foo.html, although the page might modify its contents during the popstate event.
If we click back again, the URL will change to http://mozilla.org/foo.html, and the document will get another popstate event, this time with a null state object. Here too, going back doesn't change the document's contents from what they were in the previous step, although the document might update its contents manually upon receiving the popstate event.
Related
I have a button on index page (index.php) that when you click it, it should take you to other page (login.php) without reloading the page simultaneously. Below is javascript with pushState.
document.getElementById('cta_btn').onclick = function() {
window.history.pushState('', '', 'login.php');
};
The problem is that I stay on same page (index.php) only url changes /login.php
pushState is a way of saying "I am using JavaScript to modify the DOM of this page so that it becomes the same as what you would get if you requested this URL". You don't appear to have written the JS to modify the DOM.
It doesn't cause new content to load by itself. It doesn't really navigate anywhere. It just pretends to so you can hook into popstate and change the DOM back to how it was before when the back button is pushed.
If you use pushState then you all need to change the DOM (with createElement and friends for simple cases and with frameworks like React for complex ones).
If you want to navigate to a new page, then assign a value to location.href.
If you don't want to load content from the server in order to do that navigation then make sure the user has previously visited the page and that caching headers were sent then.
I guess State is a Object, You should try this...
window.history.pushState({}, '', 'login.php');
I found a lot of questions about this on Stack Overflow, but they were all very specific about certain parts. I did find this question whose answers provide some nice references, but they don't actually explain how it all works, and their examples hardly do anything. I want to know more about how it all works together, and I want to use vanilla JavaScript.
(Also, many of the answers on other questions are years old.)
GETTING STARTED
First of all, you can remove the window part. Just history works fine. But before we get into how everything works together, we need to know what we can use.
Important Events
window.onload
This event fires whenever your webpage is loaded. There are two cases that will fire this event:
When your webpage is navigated to from another webpage. Note that I wrote webpage, not website. Moving between pages on the same site will trigger this event.
Just after your webpage is refreshed.
window.onpopstate
This event fires when you navigate between history states that you have set. Your browser automatically sets history states (to null) during normal browsing, but navigating to/from these states will not trigger this event.
window.onunload
This event fires whenever your webpage is unloaded. There are two cases that will fire this event:
When you navigate to another webpage from your webpage.
Just before your webpage is refreshed.
Important Objects
The history interface contains five functions (described below), two read-only objects (described here), and works a bit like a linked list. The two objects contained in each 'link' of the history object are:
length - This is the number of history states for the current browser window. It starts at 1.
state - This is a JavaScript object that can contain practically anything. It is null by default.
You can access them by calling history.length and history.state respectively, though history.state can only be used to get the current history state.
Important Functions
history.go(distance)
This function does the same thing as pressing the back or forward button in your browser, with the added functionality of being able to specify exactly how far you want to go. For example, history.go(3) has the same effect as would pushing your forward button three times, without actually loading the pages between your start and end locations. A negative value will likewise move you backwards through your history. history.go(0), history.go(), and even history.go(NaN) have the same effect as refreshing the page (this does not trigger the popstate event). If you cannot move forward/backward as far as specified, the function will do nothing.
history.back()
This function has the same functionality as the back button in your browser. It is equivalent to history.go(-1). If it cannot go back, the function will do nothing.
history.forward()
This function has the same functionality as the forward button in your browser. It is equivalent to history.go(1). If it cannot go forward, the function will do nothing.
history.replaceState(state, title[, location])
This function replaces the current history state. It takes three arguments, though the last one is optional. The arguments are:
state - This is the most important argument. The object you give to this argument will be saved to history.state for later retrieval. This is a deep copy, so if you later modify the original object it will not change the saved state. You could also set this to null, but if you aren't going to use it, there's not much point in using history at all.
title - The HTML Standard suggests that a string passed to this argument could be used by the browser in the user interface, but no browser currently does anything with it.
location - This argument allows you to change the URL relative to the current page. It cannot be used to change the URL to that of another website, but it can be used to change the URL to that of another page on your website. I would advise against this however, as the page is not actually reloaded even though the URL is of another page. Using back/forward will show the changed URL, but will not change the page, and will trigger popstate rather than load or unload. Refreshing the page after changing its URL will load the page specified by the URL rather than the page you were previously on. This functionality could be used to provide a link to your page in its current state, but I would recommend only changing the query string rather than the full URL. If this argument is not used, the URL will not change.
history.pushState(state, title[, location])
This function works the same as history.replaceState, except it puts the new state after the current state instead of replacing the current state. All history states that could have previously been accessed with forward are discarded, and the new state becomes the current state.
ASSEMBLING THE PIECES
The history interface is very useful for allowing your users to navigate through dynamically generated content from within their browser without having to reload the entire page, but you need to be mindful of all the possible things your users could do that could affect the history state.
First time navigating to your page
Should your users be greeted with a menu/list, some specific dynamically generated content, or maybe some random dynamically generated content?
Will your page display correctly without history, or even JavaScript?
Using back/forward to return to your page
Should your users see the same thing they saw their first time, or should they see the result of their visit reflected in the content? (A "Welcome Back" message might be a nice touch to some, but an unwanted distraction to others.)
Refreshing your page
Should you get a new page, return to the start page, or reload the same page? (Your users probably won't expect that last one if the URL hasn't changed.)
Using back/forward from a refreshed page
Should you get new content relative to the refreshed page, or reload the previously saved state?
Navigating away from your page
Do you need to save anything before leaving?
Returning to your page via a deep link
Do you have code in place to recognize and handle a deep link?
Note there is no way to delete a saved state (other than a specific case with pushState() mentioned above). You can only replace it with new content.
PUTTING IT ALL TOGETHER
Since this is starting to get a bit wordy, lets finish it off with some code.
// This function is called when the page is first loaded, when the page is refreshed,
// and when returning to the page from another page using back/forward.
// Navigating to a different page with history.pushState and then going back
// will not trigger this event as the page is not actually reloaded.
window.onload = function() {
// You can distinguish a page load from a reload by checking performance.navigation.type.
if (window.performance && window.PerformanceNavigation) {
let type = performance.navigation.type;
if (type == PerformanceNavigation.TYPE_NAVIGATE) {
// The page was loaded.
} else if (type == PerformanceNavigation.TYPE_RELOAD) {
// The page was reloaded.
} else if (type == PerformanceNavigation.TYPE_BACK_FORWARD) {
// The page was navigated to by going back or forward,
// though *not* from a history state you have set.
}
}
// Remember that the browser automatically sets the state to null on the
// first visit, so if you check for this and find it to be null, you know
// that the user hasn't been here yet.
if (history.state == null) {
// Do stuff on first load.
} else {
// Do stuff on refresh or on returning to this page from another page
// using back/forward. You may want to make the window.onpopstate function
// below a named function, and just call that function here.
}
// You can of course have code execute in all three cases. It would go here.
// You may also wish to set the history state at this time. This could go in the
// if..else statement above if you only want to replace the state in certain
// circumstances. One reason for setting the state right away would be if the user
// navigates to your page via a deep link.
let state = ...; // There might not be much to set at this point since the page was
// just loaded, but if your page gets random content, or time-
// dependent content, you may want to save something here so it can
// be retrieved again later.
let title = ...; // Since this isn't actually used by your browser yet, you can put
// anything you want here, though I would recommend setting it to
// null or to document.title for when browsers start actually doing
// something with it.
let URL = ...; // You probably don't want to change the URL just yet since the page
// has only just been loaded, in which case you shouldn't use this
// variable. One reason you might want to change the URL is if the
// user navigated to this page with a query string in the URL. After
// reading the query string, you can remove it by setting this
// variable to: location.origin + location.pathname
history.replaceState(state, title, URL); // Since the page has just been loaded, you
// don't want to push a new state; you should
// just replace the current state.
}
// This function is called when navigating between states that you have set.
// Since the purpose of `history` is to allow dynamic content changes without
// reloading the page (ie contacting the server), the code in this function
// should be fairly simple. Just things like replacing text content and images.
window.onpopstate = function() {
// Do things with history.state here.
}
// This function is called right before the page is refreshed, and right
// before leaving the page (not counting history.replaceState). This is
// your last chance to set the page's history state before leaving.
window.onunload = function() {
// Finalize the history state here.
}
Notice that I never called history.pushState anywhere. This is because history.pushState should not be called anywhere in these functions. It should be called by the function that actually changes the page in some way that you want your users to be able to use the back button to undo.
So in conclusion, a generic setup might work like this:
Check if (history.state == null) in the window.onload function.
If true, overwrite the history state with new information.
If false, use the history state to restore the page.
While the user is navigating the page, call history.pushState when important things happen that should be undoable with the back button.
If/When the user uses their back button and the popstate event is triggered, use the history state you set to return the page to its previous state.
Do likewise if/when the user then uses their forward button.
Use the unload event to finalize the history state before the user leaves the page.
I am working on some javascript code, and using window.History.pushState to load new HTML pages, instead of using href tags. My code (which is working fine) looks like this.
window.History.pushState({urlPath:'/page1'},"",'/page1')
strangely, this fails, ie reloads the browser
window.History.pushState({urlPath:'/page2.php'},"",'/page2.php')
But this works, content is updated, browser not refreshed ! (notice the URL is absolute and not relative)
window.History.pushState({urlPath:'www.domain.com/page2.php'},"",'www.domain.com/page2.php')
The documentation for window.History.pushState says that the third parameter URL can be either absolute or relative -
URL — The new history entry's URL is given by this parameter. Note
that the browser won't attempt to load this URL after a call to
pushState(), but it might attempt to load the URL later, for instance
after the user restarts the browser. The new URL does not need to be
absolute; if it's relative, it's resolved relative to the current URL.
The new URL must be of the same origin as the current URL; otherwise,
pushState() will throw an exception. This parameter is optional; if
it isn't specified, it's set to the document's current URL.
Absolute URLs seem to be working but relative seem to be not. Why is this happening?
The short answer is that history.pushState (not History.pushState, which would throw an exception, the window part is optional) will never do what you suggest.
If pages are refreshing, then it is caused by other things that you are doing (for example, you might have code running that goes to a new location in the case of the address bar changing).
history.pushState({urlPath:'/page2.php'},"",'/page2.php') works exactly like it is supposed to in the latest versions of Chrome, IE and Firefox for me and my colleagues.
In fact you can put whatever you like into the function: history.pushState({}, '', 'So long and thanks for all the fish.not a real file').
If you post some more code (with special attention for code nearby the history.pushState and anywhere document.location is used), then we'll be more than happy to help you figure out where exactly this issue is coming from.
If you post more code, I'll update this answer (I have your question favourited) :).
As others have suggested, you are not clearly explaining your problem, what you are trying to do, or what your expectations are as to what this function is actually supposed to do.
If I have understood correctly, then you are expecting this function to refresh the page for you (you actually use the term "reloads the browser").
But this function is not intended to reload the browser.
All the function does, is to add (push) a new "state" onto the browser history, so that in future, the user will be able to return to this state that the web-page is now in.
Normally, this is used in conjunction with AJAX calls (which refresh only a part of the page).
For example, if a user does a search "CATS" in one of your search boxes, and the results of the search (presumably cute pictures of cats) are loaded back via AJAX, into the lower-right of your page -- then your page state will not be changed. In other words, in the near future, when the user decides that he wants to go back to his search for "CATS", he won't be able to, because the state doesn't exist in his history. He will only be able to click back to your blank search box.
Hence the need for the function
history.pushState({},"Results for `Cats`",'url.html?s=cats');
It is intended as a way to allow the programmer to specifically define his search into the user's history trail. That's all it is intended to do.
When the function is working properly, the only thing you should expect to see, is the address in your browser's address-bar change to whatever you specify in your URL.
If you already understand this, then sorry for this long preamble. But it sounds from the way you pose the question, that you have not.
As an aside, I have also found some contradictions between the way that the function is described in the documentation, and the way it works in reality. I find that it is not a good idea to use blank or empty values as parameters.
See my answer to this SO question. So I would recommend putting a description in your second parameter. From memory, this is the description that the user sees in the drop-down, when he clicks-and-holds his mouse over "back" button.
window.history.pushState({urlPath:'/page1'},"",'/page1')
Only works after page is loaded, and when you will click on refresh it doesn't mean that there is any real URL.
What you should do here is knowing to which URL you are getting redirected when you reload this page.
And on that page you can get the conditions by getting the current URL and making all of your conditions.
I want to change html without reload. I do it like:
$('#left_menu_item').click(function(e) {
if (!!(window.history && history.pushState)) {
e.preventDefault();
history.pushState(null, null, newUrl);
}
});
It works correctly. But if I want to go back with "Back" button - browser change url on previous, but it not reload page. Why?
this behaviour is expected and is in accordance with the specifications of manipulating the history stack.
this is a relatively complex problem to explain. but in short think of it as this: any history entry the user pushes on the history stack (using pushState etc) doesn't merit a page load when you move from it because it is considered a fake (user generated) history entry.
why?
this behaviour is a good thing and is consistent with the intent of giving the developer more control over the page without being forced to reload it (think of it like ajax: you can do things that were previously only possible by page reloading like fetching data but now you can do it without reloading the page using the XMLHttpRequest object).. if you want to mimic the behaviour of reloading the page when clicking the back button.. you can simply call location.reload() when you handle the window.onpopstate event
how?
this may be outside the scope of your question but i just wanted to put it there to describe what we're talking about
let me explain by using an existing example here (excerpted text will be italicised):
Suppose http://mozilla.org/foo.html executes the following JavaScript:
var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");
This will cause the URL bar to display http://mozilla.org/bar.html, but won't cause the browser to load bar.html or even check that bar.html exists.
think of it as that you are creating an entry in the history stack that is not associated with an actual page load.. rather a 'fake' page load (ie you are just using javascript to manipulate the dom and insert html)..
Suppose now that the user now navigates to http://google.com, then clicks back. At this point, the URL bar will display http://mozilla.org/bar.html, and the page will get a popstate event whose state object contains a copy of stateObj. The page itself will look like foo.html, although the page might modify its contents during the popstate event.
the point here is that bar.html is a fake history entry that sits on top of the original http://mozilla.org/foo.html.. so you will see on the url http://mozilla.org/bar.html but the contents will belong to foo (in this example notice that we didnt manipulate the content of the dom when we pushed bar.html.. if we did like in your example.. then that content will also show up). the key thing here is that the page reloads!.. because we are serving a page that has a genuin entry on the history stack (even if on the url.. we are displaying a url that is associated with a fake entry on the history stack).
also separate this discussion from the page manually handling the popstate event.. that's a different story and will just complicate things.
If we click back again, the URL will change to http://mozilla.org/foo.html, and the document will get another popstate event, this time with a null state object. Here too, going back doesn't change the document's contents from what they were in the previous step, although the document might update its contents manually upon receiving the popstate event.
here.. the page will not load!.. that's because we are making the transfer from a fake history stack entry to the real one (and the real one was already loaded in the previous step.. so the page reloaded and that's it).
that's it for the example. the concept is kind of hard to explain and i encourage you to test your code by clicking through a combination of real and fake pages and you will see a pattern of when the page actually loads and when it doesn't..
window.onpopstate = function(event) {
if(event && event.state) {
location.reload();
}
}
This is what I use :)
I have an iframe tag and I want to dynamically change it using jquery animation. So for example the iframe sits on the home page, and if i click the about link, it will load the about.html and when its ready it will slide it down using animation.
I have the basic logic for it but then came about this
problem:
When I refresh the page it loads back the content of the index.html page, and what I want is that when I refresh it, it still keeps the contents of about.html.
About
<iframe id="content" name="content" align="top" src="index.html"
frameborder="0" width="100%" height="1200px" scrolling="no">
</iframe>
this is just the most basic logic, but I need help on how do I achieve the refreshing part/
and what if i dont include them in the same page but I still want to animate the page transitions. so when the users clicks a link to a new page, it will load it, and then animate it.How can I achieve this. Because recently I saw a jquery plugin callen LocalScroll and they achieve this effect, but i couldnt get it to work for new pages
Your reference to the jQuery plugin LocalScroll is on the right track. In fact, if you could implement it properly I think it would solve your problem.
Anchor-based navigation, as used in this plugin, jQuery Mobile, and other places, will update the window.location object and also be reflected in the browser's address bar so that, when an explicit page refresh occurs, the hashed location is preserved.
The answer, then, is to have a script which can parse this local link from the address. Here's a generic JavaScript code block to demonstrate this:
window.onload=function() {
var URLParts=window.location.toString().split('#');
if(URLParts.length>1)
var lastPage=decodeURI(URLParts[1]);
else
return false;
if(lastPage)
iframe_load(lastPage,'content');
}
function clear_last_page(location) {
var URLParts=location.split('#');
if(URLParts.length<=1)
return location;
URLParts.pop();
return URLParts.join('#');
}
function iframe_load(url,targetID) {
document.getElementById(targetID).src=url;
var location=clear_last_page(window.location.toString())+'#'+url;
window.location.href=location;
}
How it Works
When the window onLoad event is triggered, the URL is searched for anchor (hashed) links. If found, we will assume that this is a reference to a page and so then pass it to iframe_load().
This function does two things. First, it points your target inline frame to the page passed via url parameter. Second, it points the parent frame to a fictitious anchor, which will be preserved even after the page is refreshed.
Therefore, when you refresh the parent frame, that anchor text is grabbed, parsed, and used to re-load the last loaded inline page.
The function clear_last_page() is simply a helper function that prevents additional anchor links from being appended to the URL.
Demonstration
Visit this URL:
http://gocontactform.com/stackoverflow/dynamically-change-iframes-content/
Click the link "Page 2" to see the change. Then refresh the page.
Noteworthy
Be advised that this solution technically takes over the normal function of anchoring. So if you attempt to use anchor links normally on the page, you may get undesirable results.
You are forced to rely on iframe_load() for any links bound for that inline frame, instead of what you modeled in your question (traditional linking with a target attribute).
I might also suggest that you define no default src attribute inline. Rather, you could add to the onLoad handler a call to iframe_load('page1.html','content') and that will prevent the unnecessary attempt to load the default page when you are refreshing with anchored links in the address.
There are also other ways to accomplish what you are asking. But I believe that this solution is easy to understand and implement.
Hope that helps!
You can use the following to change the src attribute of the iFrame:
$("#content").attr('src', 'http://mysite.com/newpage.html');
Oops, looks like I misread the question.
If you want to slide it down, you can bind an event handler to the load event (jQuery doc) to do something when the frame loads.
$("#content").hide();
$("#loadLink").click(function() {
$("#content").hide();
$("#content").attr('src', 'http://mysite.com/newpage.html');
});
$("#content").load(function() {
$(this).slideDown();
});
In this example, the iframe is hidden when you click the link, and when it is ready, it slides down.
Demo
Edit: still misread it!
To save the state of which page is last shown in the iframe, you can use HTML5 localStorage.
In the load event of the iframe save the page that it's currently showing.
localStorage['lastPage'] = "about.html"
and then load it back using localStorage['lastPage'] on page load.
Updated demo showing both sliding and keeping the page after refresh.
Not possible. When you refresh a page, your browser is supposed to get the page from the server, dropping all JS data.
History API can help, but only for the newest browers.
Whenever the page loads you need to check something to know what the last src iframe loaded. By default, no browser can know this. One way to do this is to change the hash of your page when hit the click, and whenever page loads, you check if exists this hash and trigger some link with the hash.
I write this: http://jsfiddle.net/estevao_lucas/revsg/4/
Like said Michael, History API can help you.