When accessing an external page from a Cordova app, then coming back to app with back-button, the app page is empty, or more precisely, everything that was dynamically added to the page is gone.
This seems to be the case whether the link is a native <a href="..."> or is accessed via window.open(), or via cordova.InAppBrowser.open(). The only way it does not happen is when the actual browser is specified via "_system" parameter.
Is there a way to prevent this, or is it normal behaviour ? Should I simply rebuild the dynamic page upon returning ? I could do that, but no event seems to be fired on return, not even a pageshow.
Navigating back refreshes (reloads) the page...so anything dynamically added to the page will correctly be gone. You could use hash tags on the URL for simple information or localStorage for more complex information about the page state and re-populate the page based on it when it reloads.
pageshow most like isn't firing because of some assumption being made in the JS code. Try listening to the $(document).ready for debugging purposes. It could also be caused by the issue described here (because of caching): 'pageshow' is not received when pressing "back" button on Safari on *IPad"
Specifying system causes the page to open in a new window...so that's
Related
Posting without a target so that a web page reloads seems useful behaviour for some things - such as writing a login page. I have implemented a calendar in PHP which takes advantage of this. It reloads an object from the session (or creates a new one if not present), applying any changes that result from the post then saves the object back to the session. The problem is this. If I hit the back button I don't want to go back through every click of the calendar button but would rather jump back to the page before arriving at the calendar page. Not only that, if I do go back one calendar page after another I get an annoying "confirm form resubmission". I have implemented an incrementing value after the # for each post so that I might be able to use window.onhashchange. The problem is that window.onhashchange never fires so I am unable to intercept the back button and pop the history stack. Any ideas? Am I better off coding on the server side with javascript?
Well I solved one problem. My form subclass in PHP defaults to using POST as I understand this is more secure. This causes the annoying resubmission problem when using the back button. I now use GET in my calendar page which solves this issue. I am still bemused by JS debugging in Netbeans. I have never got script to stop on a breakpoint within a single document. I have previously had it working with an external javascript source but this no longer works. If I can output to console but there is no window in which to see the output. I am told window.alert no longer works for some events in Chrome. I am completely blind! To add to the irritation, it took me a while to realize was that the javascript file was cached and changes would not be reflected in behaviour. I have put a random number into the script tag which fixes this issue. As I am debugging using netbeans connector in Chrome I have no idea why this does not force the js file to refresh. All in all, this appears to be a pretty shambolic toolchain.
I'm working on a site that provides web access to to legacy data.
The basic flow is for the user to select a query form from a menu, fill out the form, and submit it. The server generates the appropriate HTML and returns it to the browser. So far, so good.
Some reports can take some time to generate. For those reports I display a "processing" indicator when the form is submitted. This indicator is a normally hidden <div> containing an animated icon.
The problem comes when a user uses the browser's Back button to return to the query form. When the browser re-displays the page with the query form, the processing indicator is still visible. The only way to get rid of it seems to be to refresh the page at that point.
Is there any way to hide it after the Back?
You could set a JavaScript event to automatically remove the indicator after the page loads. That way, the indicator won't display unless the script later tells the indicator to show. In order to avoid never displaying the indicator, you could place the code that displays the indicator after the event that automatically hides it, both occurring on the page loading.
I finally have a solution for this that is working well enough in this application.
Some browsers, like Firefox, fire a document.focus event when the page is re-displayed. Others, like Safari, fire a window.popstate event instead.
I now hook both of these events and it works as expected 99.9% of the time.
As far as I could find, you should be able to use pageshow window event:
The pageshow event is sent to a Window when the browser displays the window's document due to navigation.
This includes:
Initially loading the page
Navigating to the page from another page in the same window or tab
Restoring a frozen page on mobile OSes
Returning to the page using the browser's forward or back buttons
<!DOCTYPE html>
<script>
window.addEventListener("load", console.log);
window.addEventListener("pageshow", console.log);
</script>
<p><a href="https://html.spec.whatwg.org/multipage/">Navigate
away</a> (then come "Back")</p>
See also:
Can I use "pageshow"?
What I got working so far:
Store a few pages in the DOM so that when the user uses the browser's back or forward button it will quickly show the page without reloading it.
What I need help with:
When a user clicks a link to a page that is already in the DOM (for back/forward functionality), I want to remove the requested page from the DOM before jqm processes the request so that the requested page is retrieved from the server rather than the DOM.
If this is possible I'm guessing I need to somehow use the pagebeforechange event.
Basically, I want jqm to use the DOM only for back/forward navigation. Otherwise I want the page to be retrieved from the server.
A website contains a "random" link, which loads a url that returns a 307 redirecting to the url we want. It works fine: click it and you load a random page. The problem is that each time you click it, the browser assumes you're loading the same page: so if you're on the homepage, then you follow the random link 5 times, then you press back, you'll be taken all the way back to the homepage, with no way to find the random pages you were just looking at. I want to modify this behavior so that users can access previous random pages via the back and forward buttons.
I don't own the website, so I can't just change the redirect code.
Here's what I've tried, all of which has failed.
Predicting what would be redirected to. While somewhat possible, there would be no way to avoid failure in up to .1% of clicks, and it would react very poorly to unexpected events, like a page that's published a day late, let alone a sit structure change.
Loading the 307 page via ajax. The request stops at readystate == 2 and I can't access the location header.
Cancel the click event and instead set location.href = random_link.href. This has no effect - the new page still doesn't go into history.
Have the new page call history.pushState. This successfully adds the page to history, but I can't find a way to distinguish between new pages and ones being opened via the back button, so the history quickly becomes very corrupted.
Keeping my own history in localStorage. As above, I can't tell when the back button is being used.
I'm working on a solution that I'm pretty sure will work, involving loading the page in an iframe over the existing page and using a background process and messaging to work around the fact that content injections from chrome extensions can't access window.parent from within iframes. And using the history API to reflect the current iframe's URL in the address bar, and get the back and forwards buttons to apply to the current iframe where appropriate.
While I'm pretty sure the last solution can be made to work, it's a hideously complex and heavyweight approach to what seems like a simple problem. So I thought I'd ask you guys before I continue: any other ideas?
Have you tried storing the locations in localStorage, then hi-jacking the back button ?
I am sure you know how localStorage works, for hi-jacking the back button you can refer to this : Is there a way to catch the back button event in javascript?
T.
I have an HTML5 application that manipulates the browser history to show the proper URL for Ajax calls. This works great, but a problem occurs when my application has hyperlink to an external site, say http://www.google.com. When this happens, the history looks like this:
My App Page A -> My App Page B -> Google
When the user hits the back button once, everything is fine. My App Page B is shown.
But when the user hits the back button a second time, the URL changes, but the page doesn't change. My app can't make the proper Ajax call to show the state for My App Page A, because the onpopstate handler never got called. This is because the handler wasn't initialized when the browser went back to My App Page B (no events fire on that back event, so I can't reinitialize the handler.)
This experience is with Chrome, but I have no reason to believe it is Chrome-specific. Is there a way around this problem?
I know that applications like Gmail open all external hyperlinks in a new window. But the requirements for my application don't allow me to do that.
The link provided by #Pumbaa80 put me on track to the right answer.
If you put <body onunload=""> on your page, then is breaks the bfcache on Chrome and other browsers. This means that when you click the back button to return to My App Page B from Google, all page state JavaScript events will fire.
There is no way to get onpopstate to get called on My App Page B after coming back from Google. (This woud be illogical, as that event only fires on the page where you hit the back button.)
The alternative is to execute the logic when My App Page B loads. By breaking the bfcache as described above, jQuery dom ready will fire. By running similar code from onpopstate in a jQuery dom ready callback, I can access the data stored in the History object reset the state of my HTML5 web app after returning from an external page.
I think you'll need to use hash tags to save the state of your page, I don't see a way around this. I've done it in the past with great success using this jQuery plugin, with the very fashionable name BBQ (Back Button & Query library). This will allow your page to perform actions based on the hash tags in the URL.