I have some replaying functionality working by using Javascript and the window.onload function.
However when I go to some other page and then come back to the web application (with the onload function) it's no longer working since the page has not been refreshed (or loaded).
Is there a way I could refresh the functionality in the window.onload function if the user doesn't close off the page but it's in the background and after a while comes back and have it on focus?
Edit - bad question. After testing I realised this behaviour is with chrome only but works fine in IE and firefox. Sorry guys, I really thought it was a bug
The onload event should be fired when the user hits the back button. Elements not created via JavaScript will retain their values. I suggest keeping a backup of the data used in dynamically created element within an <input type="hidden"> set to display:none then onload using the value of the textbox to rebuild the dynamic elements to the way they were.
If you don't care about rebuilding the page and want to actually reload it, then you could do:
<input type="hidden" id="refreshed" value="no">
<script type="text/javascript">
onload=function(){
var e=document.getElementById("refreshed");
if(e.value=="no")e.value="yes";
else{e.value="no";location.reload();}
}
</script>
I assume with "coming back" you mean "re-opening the window / tab with your website", instead of "pressing the back button after the user really left the page", in which case onLoad should fire as well.
You can use the window.onFocus() event for that. Note that it is called each time the window/tab is focused again, so it might fire more often than you'd like it to. You can prevent that by saving the timestamp of your last refresh and comparing against the last timestamp. I.e. implement a "timeout" for your page, and reload it onFocus only, when the last refresh is older than X seconds.
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"?
On one of the pages of our website (asp .net web forms), we are only able to tab through the controls of the page 1 time (by pressing tab key) and after that it just cycles tabbing through address bar and page tab. It only happens in IE. We are using this script and that's what's causing it:
<script type='text/javascript' language='JavaScript' src='https://mpsnare.iesnare.com/snare.js'> </script>
When I remove this script, it works correctly and I can tab through the controls of the page as many times as I want. However we need to have this script on this particular page. Now I noticed one thing: once the tabbing stops working (i.e. it is only cycling through address bar and page tab), if I click in an empty area of the page then tabbing starts to work and it then always works permanently. This means, this script is removing the focus from the page. So I think what I want is that, as soon as the above script finishes whatever it is doing, I want to somehow simulate click on the empty area of the page. We are using jQuery as well. Any help will be appreciated, thanks.
Not sure this is your actual solution but you can do this with plain javascript:
document.getElementById("logo").focus()
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
I am making a greasemonkey script and i would like a link to go forward and modify the current html and allow the user to click back to go to the original page.
How might i do this? using jquery + greasemonkey + javascript. Targeting firefox mostly.
-edit- http://jsfiddle.net/ seems to do it. If you write random html in the html section, hit run, change the html and hit run again. You'll be able to click back/forward to see the output change (however the html input box stays the same). I am using firefox to view this. Thats the effect i want.
it appears the magic is done on line 91. Is this submitting a form in a frame (perhaps the results frame?) and that is causing the movement in history?
88 run: function(e) {
89 e.stop();
90 Layout.updateFromMirror();
91 document.id(this.options.formId).submit();
92 this.fireEvent('run');
93 },
I don't know if that is possible at all because it is the browser itself that takes care of the navigation history. A new history item is added only when you visit a new page.
If I am not wrong you would like the user to turn on/off the changes you make to the page without enabling/disabling greasemonkey and reloading the page.
The only solution I see for this is to take care of it yourself. Save any changes you make to the page so that you can restore it and add some UI to the page to make the user turn on or off your changes.
EDIT 1:
It seems that jsfiddle.net loads a new page to do that. Using firebug you can see it is not doing any AJAX request to run the code, it is just loading a new page (maybe the same page, with different parameters, but nevertheless it is loading a page.)
EDIT 2:
Yes, maybe it is loading the page in a frame. As you can see from the HTML:
<iframe name='result' frameBorder='0'></iframe>
But this does not change your situation. If you want your logic to be in your greasemonkey script you can't load a new page. Otherwise you should upload a web page somewhere and make it load in an iframe passing it the HTML you want to modify: this is definitely not what you want to do.
It sounds like you want to use a history manager. You could either track the changes you make and undo them when the user goes back, or possibly call a page refreshing function.