I am facing issue with the way back button works in Chrome.
I have a application where I am displaying a form in iframe inside the parents window.
So when the user clicks on back button the behavior on IE and Mozilla is that page in iFrame loads up again.
This iFrame page refresh when the user clicks browser back button is important in my case is because we need to keep a track of users who have logged in the application and accessed that iFrame content.
Now in Chrome the behavior of back button is different. When the user clicks on browser back button the user is taken back to previous page.
I need to alter this behavior for chrome and need to refresh the content in iFrame instead of moving back to previous page.
Anyone kindly who have idea on this help me out.
PS: I cant use jQuery in application.
Regards,
Well the short answer is you can't and you shouldn't. becoz this behavior is inconsistent across different browsers and even future versions of mozilla and ie may also change it's behavior.
Still you have some alternatives to achieve this kind of behavior.
You can use HTML5's history.pushState where on hashchange event you can refresh you frame whenever you want.
Related
I'm using pushState to have adaptative URLs on a single-page web app. I'm also using onpopstate to have native-like behaviour with mobile devices' back button. I have managed not to lock the user out of their history, which is everyone's main concern on the threads I read mentioning how to do it.
It seems however that the trick I'm using only works when the window is clicked. Even scrolling doesn't work. It's a problem because users might not necessarily click and still hit the back button to close a menu. I've only tried it in Chrome with the following code :
window.onload = function(){
history.pushState({}, '', '')
}
window.onpopstate = function(){
history.pushState({}, '', '')
}
You have to open a new tab, browse to the file and hit the back button. If you don't click the content of the page before, it should walk back in history instead of being locked by the script. I've tried to use .focus and .click with no success.
Any ideas?
EDIT
This is what this person is talking about, and they definitely phrased it better than I did
The popstate solution works for my PWA, however I just want to point out that, from my experience, Chrome WILL close the PWA if it doesn't detect ANY user interaction, before the click on Android's back button (the interaction can be a link click, zoom-in, scroll ...). I was testing this code snippet on a minimal sample app, and couldn't understand why it wasn't working. I assume it is a safety measure against spam pop-ups, but hadn't read anything about it in the guides fetched by Google.
Seems like PWA aren't quite there yet.
I found something weird. Desktop and mobile browsers do not work the same way regarding back button.
I have hamburger menu overlay, when I click it, it opens (absolute position DIV). When I click on the link inside this overlay, on desktop, it goes to the new page. Back button then brings the previous page back, WITHOUT the overlay. This is my expected behavior.
But as I've seen, on mobile (at least on Chrome, but I think on others also), when I have overlay open and click on a link, I get to the new page, but with back I get to the previous page with the overlay STILL OPEN. It would be kind of ok, IF clicking back again would close the overlay, but it doesn't. It goes to the page I was before clicking hamburger menu or exit site, if that was my first thing I did...
Now I can handle this in 2 ways:
I can close the overlay when clicking on a link inside the menu. When I did that, overlay closes and I get to the next page. Back gets me back to the previous page without overlay. So far so good, BUT... on desktop, when I click and get on a new page this way, I have to click back 2 times to come to previous page. So that is not good.
I can somehow make the back button to close the overlay first and the next back would go back one page, but that seems even more dirty than the first option handling the push states etc.
As I see many sites have solved this. On mobile, clicking on link inside hamburger menu (or some other "popup" with menus) gets to a new page and clicking back goes back to the previous page with hamburger closed. Same behavior is on desktop, no need for double back click.
Does anybody know how I should manage this and if anybody knows why mobile browsers do not close the overlay in the first place when clicking inside it or is there some easy setting that I could trigger this behavior?
Yours
Jerry
This sounds like you just discovered a browser feature called "bfcache". I have experienced similar issues once and it took me hours to figure out whats going on.
The implementation is inconsistent through out browsers (as well as their mobile & desktop versions) and background requests the page made. It requires a certain amount of page optimization if a consistent history back/forward behavior is needed. I'm not 100% sure if that's the problem here as you missing a minimal reproducible example, but you might want to investigate in that direction.
One of the best guides on how to handle back/forward caching is this one from Google Developers.
Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation. It significantly improves the browsing experience for users—especially those with slower networks or devices.
As web developers, it's critical to understand how to optimize your pages for bfcache across all browsers, so your users can reap the benefits.
The "cache" used by bfcache is different from the HTTP cache (which is also useful in speeding up repeat navigations). The bfcache is a snapshot of the entire page in memory (including the JavaScript heap), whereas the HTTP cache contains only the responses for previously made requests.
– web.dev
I read these two questions:
How can I detect browser tab refresh or close using javascript
and
How do I detect a page refresh using jquery?
which suggest binding to 'onbeforeunload' and also binding on F5 and Ctrl-R key presses, which is good advice.
However, most browsers have a refresh button on their address bars, like this in Chrome:
Question is: is it possible to detect and bind to refresh event of browser's address bar's refresh button?
By binding onbeforeunload to windowlike this window.onbeforeunload it should trigger in most browsers. check this fiddle. It seems it's not supported on IOS devices.
For IOS apple docs suggest using pagehide see apple page on Handling Events.
The load and unload events may not work as expected for back and forward optimization. Use the pageshow and pagehide events instead.
Keep in mind that this will also trigger on all other kinds of navigation away from the page. Such as close, tab close, back/ forward navigation, link navigation and address bar navigation
Checking if the browser is reloading versus navigating away from the page I'm pretty confident is not possible, due to security/ privacy reasons not being able to give you the destination url. You could eliminate link presses by using it is an condition when firing the onbeforeunload.
Edit: If you need to check if the page has been reloaded however, you could use sessionvariables or cookies to store that the user has already opened the page once before.
I have jsp aplication.
I want, that button Back don't work.
history.forward - not suitable, that transitions occur in frame.
In Google chrome when I go in my jsp aplication create history transitions in frame, and button Back becomes active. I need disable button Back or when button back is pressed - nothing happened. Open new windows without toolbar - ot suitable.
history.forward - good work if simple internet page.
In jsp project with frames hi does not behave predictably.
I need, than it wark in google chrome and IE (maby can write individually to each his own)
How do it?
You can't disable the browser's back button. The best you can do is write your application so that using the back burron doesn't break anything.
Try this code
<body onload="onLoad();" onpageshow="if (event.persisted) onLoad();">
because Firefox 1.5 uses in-memory caching for entire Web pages, including their JavaScript states, for a single browser session. Going backward and forward between visited pages requires no page loading and the JavaScript states are preserved.
Click here for your reference
Currently I am developing a web application for which I am using a pre-loader icon. What I want is that the pre-loader becomes visible every time the user navigates to another page or refreshes the page. So far I have the following solution:
window.onbeforeunload = function() { $("applicationdisabler").show(); };
For Safari and Firefox it works fine when the user clicks a link or refreshes the page. However in IE7 the div only becomes visible when the user clicks a link and NOT when the user refreshes the page.
The user can refresh the page by hitting F5 (on Windows) or any other possible way the browser provided.
Of course I have been looking for some workarounds already. The following code shows the alert in IE7, but the div still doesn't become visible.
window.onbeforeunload = function() { $("applicationdisabler").show(); alert("come on!"); };
The code of my div:
<div id="applicationdisabler"><img src="images/preloader.gif" /></div>
Hopefully someone can help me out.
You need to put the # before the id on the jQuery selector:
$("#applicationdisabler").show();
Why not use just use the onLoad listener instead? Although it would be slightly slower it should be more reliable.
Actually after a bit of looking around I'm not sure modifying the DOM makes any sense unless the onBeforeUnload handler returns false first - i.e. forces the user to stay on the same page.
As I understand it the onBeforeUnload event is fired just before the page is unloaded, so if you don't return false the browser will unload the page and DOM, and any JavaScript executed after that will be pointless.
That doesn't quite explain why JavaScript isn't executed properly in the onBeforeUnload function, but from what I've seen sites only use the window.alert or window.prompt dialogs to ask the user if they want to leave the site, and then often executing JavaScript if the user decides to stay.
Hence I'm guessing that some browsers may not allow DOM manipulation when this event is fired - since if the page is unloaded any DOM manipulation done is completely pointless.
So either:
Return false in your onBeforeUnload method, and then show your preloader (although this will stop navigation to the next page)
Use the onLoad event of the next page to show the preloader image instead
Also note: Opera versions 9.5 and below do not support this event (I'm unsure about later versions) but GMail does manage to catch the back button in Opera.
Possibly related is this security warning for IE7's implementation of the onBeforeUnload event - it's possible Microsoft patched it in a way that prevents the things you're trying to do. And I know IE6 and below don't allow commands like document.location='' in the onBeforeUnload handler for security reasons.