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"?
Related
Is there an event raised, after going to an page via the browsers back button?
Reason: I have a mobile website which shows an loading animation after clicking on a certain link. If the visitor later goes back to this page with the back button, the animation still blocks the whole ui.
I don't know of an event like what you're looking for. 🤔
A few other options could solve your problem, though.
You could set a unique value in localstorage, and check for it on document ready. If it exists, then hide/turn off your loading animation.
Set it when you start the animation:
window.localStorage.setItem('loadingAnimationStarted', 'true');
Check for your item on document ready:
document.addEventListener('DOMContentLoaded', function(){
if(localStorage.getItem('loadingAnimationStarted') === 'true') {
stopAnimation();
}
}
You could also have the loading animation be turned off when the user navigates away from the page in the first place using the beforeunload event.
Or, you could also tie the loading animation to the completion of a custom event, or promise depending on what is happening behind the scenes.
You probably set the loading animation while the user is waiting for the page to load correct?
If the user clicks back, he will be redirected to the previous page, which is cached in the client's browser. That's probably why you don't see the loading animation at all, which is good.
If you have different condition that shows the loading animation, maybe consider to change it accordingly to your purpose.
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
What is the difference between JQuery mobile pagecontainer's "load" versus "change" functions and what is intended usage of each? I'm not interested in how the events are for each but rather what does each to do the DOM.
I've been using change to switch pages; but I'm getting some "unexpected" behavior.
Here's my scenario. There is a light page that is presented to the user for login. After logging in, I call "change" to get a page that loads a heavy page (a dashboard). In that dashboard page, I've got a button hooked up that has JQ "change" to a dialog page. When the user confirms the dialog, JQ "changes" to the dashboard page.
The issue is that upon changing back to the dashboard page the dashboard UI is all new. For example, say a user flipped a flipswitch in the dashboard, upon returning to the dashboard the user finds the switch isn't flipped.
After inspecting the DOM I see that when switching to the dialog page, JQ removes the dashboard page from the DOM and inserts the dialog. When switching back to the dashboard, JQ removes the dialog from the DOM and inserts the dashboard. Thus the fresh UI; but if the behavior is such, what is the intent of the "reload" property of each method if "change" chucks the page out of the DOM?
I tried changing things to using "load" and load inserts the DOM in but doesn't make it visible. I can't figure out how to use change to make it visible...
I searched a lot to get rid of this problem on the internet but could not find a specific solution despite the problem being discussed in details previously.
The query is simple. My javascript dynamically adds an Iframe to the web page (which displays a feedback form). The problem is that, "after answering", now when the user clicks the back-button of the browser the iframe instead of the browser window is affected i.e. the questionnaire is displayed again. I want the browser back button to behave normally.
This behavior is really annoying and I am having real trouble fixing this.
I am using firefox.
Looking forward to the replies. Please inform me if I should give more details.
Thanks,
Your form has a submit button, which posts the page to the server. The back button will always send the user back to the form regardless of whether you use a iframe or not. The ideal way is to notify the user of a completed action, in this case thank the user for the feedback (using an alert box) and redirect the user to the home page or provide a button in the page saying "Back to Home".
Firefox and IE indeed act like you mentioned, but Chrome do not, and I'd guess other WebKit browsers would do the same.
In Chrome, clicking the Back button will land you where you want to go (the previous URL of the parent frame). i.e. Chrome to not add iframe URL changes in the back button history.
Sadly, I've found no way to force IE and FF to replicate this, so I used the AJAX post approach suggested above by Arun.
Here's my iframe source, which use jQuery to post the form, and replace the whole page with the result of that POST:
<form method="post" onsubmit="postForm(this);return false">
...
</form>
<script type="text/javascript">
function postForm(form) {
$.post(form.action, $(form).serialize(), postCompleted);
}
function postCompleted(data) {
$('html').html(data);
}
</script>
This works in all browsers; clicking the Back button will send you back to the previous URL a seen by the end user, instead of the initial form loaded dynamically in the iframe.
I encountered the same problem: I use a dynamically created iframe to show a "popup" on my page, whose SRC points to another page that has got a form and a submit button. After submitting that page, a JS callback is used to hide the iframe. As you explained, this causes a new entry to be added to the history (on IE at least).
But I found out that removing the iframe element from the DOM (instead of hiding it) results in the unwanted history entry being removed (tested on IE9)! Which is what the user would expect in that situation.
You can observe this yourself on IE9:
Open the back button menu (right-click the back button): you only have one entry for the current page
Press submit in the iframe => the back button menu shows one extra entry for the iframe
Remove the iframe from the DOM => the back button menu no longer shows that entry
What is the expected behavior of Javascript when you do a soft refresh on a web page?
I know that when you refresh a page, most web browsers will preserve values entered into form elements on a page. But it becomes harder to predict what will happen on a refresh when half of the page is dynamically generated.
My question is a little more general than that, though. I want to know what the prescribed behavior is for a web browser when a page will dynamic content is refreshed. In particular:
What Javascript gets rerun.
How is the DOM altered on the refresh.
How are form values "floated" to the proper place in the DOM after a refresh.
What other quirky stuff goes on?
If you leave a page by clicking on a link or entering an URL into the navigation bar some browsers try to pause the page and resume it once the user comes back. This technique is known under different names:
Safari/WebKit: Page Cache
Firefox: Back-Forward Cache
Opera: Fast History Navigation
For the page it looks as if the user has never left it. However not all pages can be paused. Especially pages with plugins, pages served using HTTPS and all pages with an unload event handler are ignored by a page cache.
If the page cache is not used, the page is reloaded from the server. Browsers might fill in form fields and restore scroll positions.
A reload = a complete re-request. (shift + reload = reload all js and css files from server)
The browser might also remember name="" value="" pairs, and tries to pre-populate the fields based on the remembered pairs. It is not about trying to populate exactly what fields are in what pixel or whatever.
I refresh pages all the time when developing, all javascript is re-run as if the page is loaded anew. I do not believe the change events kick off in the page due to remembered values.
This is also true for firefox -> this frame -> reload or IE right click on a frame and reload.
Chrome does not allow single-frame reloads.