HTML5 introduced some really neat tools to manipulate the browser history, namely the history.pushState/replaceState methods and the onpopstate event, so we don't have to rely on location.hashes to display a meaningful url for our web applications.
(Or better, we won't have to rely on hashes when the adoption of IE<10 will be negligible.)
Using the browser's back and forward button doesn't reload the page if the targeted state was created using history.pushState, even if the URL looks completely different.
However, unlike changing the hash, if the user changes the url from the browser's address bar, the browser does reload the page. Somehow I doubt there's an effective solution for this, but the question is: is there a way to prevent the browser to reload the page, and force it to push an history state instead?
I don't believe so. AFAIK, manually entering an address in the address bar - unlike clicking a link, back/forward buttons, pushstate/popstate, and form submit - is defined as requesting a new page, unless you change a hash (like in the pre-html5 days).
No. It isn't possible to interrupt the loading of new pages via the address bar (except for unload events, but they can only give you "Are you sure you want to leave the current page?" interruptions).
The real URLs should be handled by your server which should build the page into the expected state for that URL before delivering it to the client.
Related
Is it good to allow webpages to load directly from browser url field or browser back buttons?
Our webapplication is working fine if any user navigates through home page, but some users are directly accessing the web url in the browser and raising issues that it is not working fine.
Can you please suggest do we need to support loading the urls through browser or allow to navigate through home page?
Some banking websites gives a warning saying to do not use browser urls or browser buttons to navigate between pages i.e. they will warn to do not press browser back button to navigate to previous page etc., so is it correct idea then?
Yes! Ideally, you should let your users use the links directly and have the website function as usually does. This is ideal if they use, for example, their "recent webpages" functionality on their browser, they want to revisit some page from their history, or they visit the webpage so often it appears on their recommended webpages list (This is a functionality present in some browsers, such as Chrome).
A good way to achieve this is query parameters.
Overall, you should expect your user to access the website from other places than the homepage, and have some logic to handle it in such a webpage that the website doesn't become broken.
However, there are some situations where it's just impossible to have the website work as expected without some previous action done by the user (For example, filling a form or being authenticated. In some cases, your user might need to be authenticated to visit a specific link, and ideally, because of security, user sessions should eventually expire). In this case, having safeguards that redirect the user to some previous page where they can begin their flow again (Such as, the login page) is better than nothing.
How to implement this depends a lot on the stack being used (Programming navigation varies between React and Angular. You might not even be using a library or framework at all!). More context would be needed to suggest an approach.
Is it possible to use cookies, to let users browse faster in a site with a lot of jquery modules? I mean, that every time when someone clicks browsers back button, he goes back to the page which was in it memory (every page module would be in exactly that position in which it was when user got out from that page).
You might find pushState and history useful for this: Manipulating the Browser History
Using these techniques, you can change what information is requested when the browser's back button is used.
I'm tasked with coming up with a way to determine if a person has reached our site via using their back button (meaning they left our site and came back) and log them out if so.
I've come up with some options, but am wondering what other options I may be missing.
FYI, we do have a session state, so server-side we're covered for long absences, but they want an additional check on the client side.
option 1: set a cooking via onunload that expires in x seconds. On each page of our site, I check for said cookie. If it exists, I assume they came from another page on our site and do nothing. If it's not there, I assume they have been gone from our site more more than x seconds and redirect out. Con: Blackberry devices running OS5 don't support onunload.
option 2: same as #1 but instead of setting cookie onunload, we set it on every click of every link that goes to another page on our site. con: messy
option 3: check browser history on every load of every page of our site. If the previous URL is not one of ours, we log them out. Cons: browser support? It looks like previous/next history objects are now blocked in modern browsers due to security.
Option 4: Via JS, every x seconds, check for a cookie. If it's there, reset it to expire in x seconds. If it's not there, assume they've returned from somewhere else. Con: Not sure if the JS cookies would be set while that page may be in the background (app switching on an iPhone, or using a different tab in a desktop browser).
Any other options I should consider? Is there a 'proper' way to handle this? Is this just grasping at straws trying to prevent normal browser behavior?
You could keep the current page name/action/identifier in a session variable, then use a javascript onChange/load/keyup/keydown to request the current state of the user from the server. If it does not match, redirect or otherwise block them from viewing the current page.
This is a method that I've used, but it has it's downsides.... for example, onload doesn't always seem to work when the user uses the back button. OnChange, etc on certain form fields definitely works. Timers are pretty straightforward, as well, but a quick user can get input through the page regardless.
It's not that complicated... Use javascript history object
history.next gives you the complete url of the page in the forward button. A simple regex can tell if it's from your domain or not.
I just don't know if it's supported by all browsers
I dont want to page reload when going to history back on my web pages.
When visitors are click back button on browser or press backspace key, my pages are reload. How can i disable reloading on history back or how can i activate real caching?
Thanks...
This behaviour stems from the browser's MO, not from your end.
you cannot prevent page reload. If your problem is POST pages relaoding, with messages alerting the user that POSTED data should be resend then you should look at "Redirect after Post" principle with 303 redirect on POST. It can fix some of theses behaviors.
The second thing you should look at is the cache headers you are sending with your pages responses, use PageSpeed extension of firebug or other tools, you'll have good hints on what headers you are actually sending and what setting you could adjust. When your cache headers are fine you'll see that some pages won't be recall and that some queries from the browser are not generating real GET+response 200 but 304-unchanged responses and headers queries. And if you go deeper on the analysis you'll find that the way the browser cache is working depends a lot of the browser.
The page is not reloaded when following a HTML bookmark within the same document. That is, all the browsing must happen using Javascript only and URL must stay the same until the # character. To handle the Back button correctly, you may need to use the onpopstate event. If you don't want any changes to the URL, you can use history.pushState().
If Javascript is not supported by the browser, you can do some tricks using CSS :target selector -- or just navigate the user to another page with reloading.
Note: I did not code a page like this, it is just my guess after reading an API reference page.
Got a window.history.go(1) to stop the user hitting the back button, but was wondering if I could check to see if a forward history exists before doing it, so I can display a popup warning the user not to press the back button.
I know you can get the history length, but is there a way to get the current position in the history list? Or some other way of doing this...
AFAIK you won't be able to access the history from JavaScript. It will be a security hole and most of the browsers won't allow that. Probably there might be a workaround in IE by using ActiveX.
Found this entry which might be useful to you
window.history
There is a next property.
Returns the URL of the next item in
the session history
This property is not available to web
content and is not supported by other
browsers.
For security reasons the History
object doesn't allow the
non-privileged code to access the URLs
of other pages in the session history,
but it does allow it to navigate the
session history.
There is no way to clear the session
history or to disable the back/forward
navigation from unprivileged code. The
closest available solution is the
location.replace() method, which
replaces the current item of the
session history with the provided URL.
Don't break the back (or forward) button.
You don't know exactly what they might do without knowing every possible user's setup (including plugins, etc.)
You still have to do something mildly intelligent (e.g. not trash your database) if scripting is disabled, or disabled then re-enabled, etc.
Because you already have to handle #2, don't even worry about figuring out how to do #1 everywhere for everyone, and spend more time to make #2 work better.
Now your site works with the back button.