Prevent refresh of any page shape with jQuery / Javascript

As soon as the user is on my page, I do not want him to refresh the page.

  • At any time, the user presses F5 or the refresh button at the top. He must warn that

    You cannot refresh the page.

  • Also, if the user opens a new tab and tries to access the same URL in the previous tab, he should receive a warning

    You cannot open the same page in 2 tabs

Anyway, can I do this using JavaScript or jQuery? Point 1 is really important.

+57
javascript jquery refresh
Aug 19 '10 at 23:19
source share
6 answers

# 1 can be implemented through 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 receive a request with a message and provide the opportunity to stay on the page or continue on his way. This is becoming more common. Stack overflow does this if you try to jump from a page while typing a message. You cannot completely stop the user from rebooting, but you can make him really scary if they do.

# 2 is more or less impossible. Even if you track sessions and user logins, you still cannot guarantee that you have correctly defined the second tab. For example, maybe I have one window open, and then close it. Now I open a new window. You will probably find this as a second tab, although I have already closed the first. Now your user cannot access the first window because he closed it, and they cannot access the second window because you deny it.

In fact, my online banking system is making No. 2 really hard, and the situation described above is happening all the time. Usually I have to wait for the end of the session on the server side before I can use the banking system again.

+123
Aug 19 '10 at 23:34
source share

You cannot prevent users from updating, and you should not try. You must return to why you need this solution, what is the root problem here? Start there and find another way to solve the problem. Perhaps you have elaborated on why you think you need to do this, this will help to find such a solution.

Violation of the basic functions of the browser is never a good idea, more than 99.999999999% of the Internet works and is updated using F5, this is a user expectation that you should not violate.

+26
Aug 19 '10 at 23:22
source share

Although it is not a good idea to disable the F5 key, you can do it in jQuery as shown 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 helps!

+10
Nov 15 '13 at 20:08
source share

In the last days of CGI, we had many forms that could trigger various backend actions. For example, text notifications for groups, print jobs, data fermentation, etc.

If the user was on a page that said, "Please wait ... Doing some HUGE work, which may take some time." They most likely got into REFRESH, and that would be FREE!

Why? Because it will lead to slower work and, ultimately, link it all.

Decision? Let them make their shape. When they submit their form ... Launch your work and then forward it to another page that will keep them waiting.

If the page in the middle actually contained the form data needed to run the job. The WAIT page, however, contains a history of javascript destruction. So they can RELOAD that wait for the page is all they want, and will never run the original job in the background, because this WAIT page contains only the form data needed by WAIT itself.

Hope this makes sense.

The history erase feature also prevented them from pressing BACK and then updating.

It was very smooth and worked great for many MANY years until the nonprofit activity was wounded.

Example: FORM ENTRY - collect all your information and when it is sent, this starts your back work.

RESPONSE FROM LOG IN TO FORM - returns HTML that redirects to your static wait page and / or POST / GET to another form (WAIT page).

WAIT PAGE - contains only FORM data related to the wait page, as well as javascript to destroy the most recent history. Like (-1 OR -2) to destroy only the very last pages, but still allows them to return to the original FORM login page.

As soon as they appear on your WAIT page, they can click REFRESH as much as they want, and this will never cause the original FORM to work on the backend. Instead, your WAIT page should include a timely META update so that it can always check the status of its work. When their work is completed, they will be redirected from the wait page to whatever you wish.

If they do REFRESH manually ... They just add another check of the status of their work there.

Hope this helps. Good luck.

+7
Aug 01 '14 at
source share

No no.

I am sure that there is no way to intercept the click on the update button from JS, and even if it were possible, JS can be disabled.

You should probably step back from your X (preventing the upgrade) and find another solution for Y (whatever that is) .

+5
Aug 19 '10 at 23:21
source share

Number (2) is now possible using socket.io with an individual heart rate for each session in which the user is participating. If the user tries to open another window, you have a javascript handler check with the server, if it is ok, then respond with error messages.

However, the best solution is to synchronize the two sessions, if possible, as in google docs.

0
Jan 10 '14 at 22:35
source share



All Articles