I have on the client side (mobile) a timer (setTimeout()) which triggers refreshing the token on the server side by sending a post message to the server.
That timer does not seem to trigger sending a message to the server when the screen timeout on my mobile is on and the screen is black.
How can I enable triggering even if the mobile has the screen switched off.
I don't think there is a a way for angular to know when a page is locked. You could track any input or page movements instead and reset a timeout timer so that if the page stays idle for a while you could send a request to the server. That being said you would probably want the page timeout to be decently long to avoid closing a session while a user is still using the page. What you can also do is have a warning message pop up when the timeout is reached that prompts the user to say they are still using the page, if they click yes reset the timer again otherwise close the session.
I want to calculate time consumed in redirecting from 1 webpage to another webpage.
For Example:
1) I am using Facebook in Google Chrome browser.
I have shared 1 link on my Facebook profile like below:
http://www.webdeveloper.com/
(It's not only Facebook. It can be any domain having link to another domain).
2) When I click on this link from my Facebook profile, then this website will open in new tab.
3) I want to calculate time difference in miliseconds or microseconds between below two events:
First Event: Time of clicking link "http://www.webdeveloper.com/" from my Facebook profile.
Second Event: Time of completely loading webpage of "http://www.webdeveloper.com/".
Thank you in advance.
Unless you load the linked page yourself into a frame or with xmlhhtp request, your facebook page does not have control of another page. In other words, as soon as the user clicks the link you have no control and it runs separately. If you use a frame or load the page ajax style with javascript into an object, it's not going to give you the same kind of timing. So this is basically a pointless excercise as you can't do it. You could potentially setup your own browser with whatever analyzer so it will give you timings but you can't set up any code that would time it for visitors, for the aforementioned reason. If it was possible to do such things then this code could also manipulate the linked to page and take over it. With such lax security you couldn't trust any link you click.
I have a Live Feed jQuery box which updates in every 10 seconds, and puts the sites latest comments on top. This is working fine: jQuery makes an Ajax request, calls a PHP, which returns new items or none.
This box is like a sidebar, it is on every page on my site. My problem is that if a user opens many pages on the site, every tab he opened will do this auto-refresh until he closes that tab. So with a few dozen users each opening many pages this becomes a problem, even if the Live Feed is well optimized, and the SQL query behind it is fast (0.0005 seconds per query). Also if the user leaves the browser open with a couple of opened tabs, and start browsing somewhere else, or watch a movie they'll update forever, or until he closes them.
So what is a nice solution for this? Can I make my feed update only if its tab/window is visible/active? Is there an event which will fire if it was inactive and now active again?
Try adding onFocus event on the window object to trigger your updates and add onBlur to stop updating your live feeds.
Since you are using jquery you can do this
$(window).('focus',function(){
//do updates
})
$(window).('blur',function(){
//stop updates
})
I am creating an internal web based application that will not be the target audience of the web.
I understand the frustration of alert boxes and forcing people to do certain things.
With that said, what I am attempting to do is create a javascript function, that unless a user clicks a link on a specific page, if they try to navigate away from the page other than using a link on the page, I would like to alert them and say, sorry you need to click the appropriate link to exit.
What my issue is, is that I need to lock out fields, and what I can do when a user hits an edit page, im going to write to a table that user to the lockoutuser colum. If a value exist, that user can access the record if it is null, it means no one is editing the record. If someone clicks to go into that record they lock it out, my means of updating the lockoutuser colum could be ajaxy on unload of the page, but the page could be unloaded for 2 reasons, 1 the edit form is submitted or the user leaves the page.
An alert that would say, sorry you can leave this record without clicking the big red button that says unlock, and force the user without refreshing to stay on the page.
I understand the machine could crash and or an alt f4 or a brute end task on the browser will still leave me other work to unlock the record
You need to use the onunload event of the page to present a messagebox when the user tries to leave your page. Check out this example: http://www.codetoad.com/javascript/miscellaneous/onunload_event_eg.asp
Once the user is on my page, I do not want him to refresh the page.
Anytime, the user hits F5 or refresh button on top. He should get an alert saying
You cannot refresh the page.
Also if the user opens a new tab and tries to access the same url in prev tab he should get an alert
You cannot open same page in 2 tabs
Anyway I can do this using JavaScript or jQuery? Point one is really important.
#1 can be implemented via window.onbeforeunload.
For example:
<script type="text/javascript">
window.onbeforeunload = function() {
return "Dude, are you sure you want to leave? Think of the kittens!";
}
</script>
The user will be prompted with the message, and given an option to stay on the page or continue on their way. This is becoming more common. Stack Overflow does this if you try to navigate away from a page while you are typing a post. You can't completely stop the user from reloading, but you can make it sound real scary if they do.
#2 is more or less impossible. Even if you tracked sessions and user logins, you still wouldn't be able to guarantee that you were detecting a second tab correctly. For example, maybe I have one window open, then close it. Now I open a new window. You would likely detect that as a second tab, even though I already closed the first one. Now your user can't access the first window because they closed it, and they can't access the second window because you're denying them.
In fact, my bank's online system tries real hard to do #2, and the situation described above happens all the time. I usually have to wait until the server-side session expires before I can use the banking system again.
You can't prevent the user from refreshing, nor should you really be trying. You should go back to why you need this solution, what's the root problem here?. Start there and find a different way to go about solving the problem. Perhaps is you elaborated on why you think you need to do this it would help in finding such a solution.
Breaking fundamental browser features is never a good idea, over 99.999999999% of the internet works and refreshes with F5, this is an expectation of the user, one you shouldn't break.
Although its not a good idea to disable F5 key you can do it in JQuery as below.
<script type="text/javascript">
function disableF5(e) { if ((e.which || e.keyCode) == 116 || (e.which || e.keyCode) == 82) e.preventDefault(); };
$(document).ready(function(){
$(document).on("keydown", disableF5);
});
</script>
Hope this will help!
Back in the ole days of CGI we had many forms that would trigger various backend actions. Such as text notifications to groups, print jobs, farming of data, etc.
If the user was on a page that was saying "Please wait... Performing some HUGE job that could take some time.". They were more likely to hit REFRESH and this would be BAD!
WHY? Because it would trigger more slow jobs and eventually bog down the whole thing.
The solution?
Allow them to do their form.
When they submit their form... Start your job and then direct them to another page that tells them to wait.
Where the page in the middle actually held the form data that was needed to start the job.
The WAIT page however contains a javascript history destroy. So they can RELOAD that wait page all they want and it will never trigger the original job to start in the background as that WAIT page only contains the form data needed for the WAIT itself.
Hope that makes sense.
The history destroy function also prevented them from clicking BACK and then refreshing as well.
It was very seamless and worked great for MANY MANY years until the non-profit was wound down.
Example:
FORM ENTRY - Collect all their info and when submitted, this triggers your backend job.
RESPONSE from form entry - Returns HTML that performs a redirect to your static wait page and/or POST/GET to another form (the WAIT page).
WAIT PAGE - Only contains FORM data related to wait page as well as javascript to destroy the most recent history. Like (-1 OR -2) to only destroy the most recent pages, but still allows them to go back to their original FORM entry page.
Once they are at your WAIT page, they can click REFRESH as much as they want and it will never spawn the original FORM job on the backend. Instead, your WAIT page should embrace a META timed refresh itself so it can always check on the status of their job. When their job is completed, they are redirected away from the wait page to whereever you wish.
If they do manually REFRESH... They are simply adding one more check of their job status in there.
Hope that helps. Good luck.
No, there isn't.
I'm pretty sure there is no way to intercept a click on the refresh button from JS, and even if there was, JS can be turned off.
You should probably step back from your X (preventing refreshing) and find a different solution to Y (whatever that might be).
Issue #2 now can be solved using BroadcastAPI.
At the moment it's only available in Chrome, Firefox, and Opera.
var bc = new BroadcastChannel('test_channel');
bc.onmessage = function (ev) {
if(ev.data && ev.data.url===window.location.href){
alert('You cannot open the same page in 2 tabs');
}
}
bc.postMessage(window.location.href);
Number (2) is possible by using a socket implementation (like websocket, socket.io, etc.) with a custom heartbeat for each session the user is engaged in. If a user attempts to open another window, you have a javascript handler check with the server if it's ok, and then respond with an error messages.
However, a better solution is to synchronize the two sessions if possible like in google docs.