I’ve talked about this a few times:
To summarize the answers, onunload and onbeforeunload do not serve to detect when the person leaves the site, what it does is to detect the unloading, that is if browsing a link from the same site will trigger the event, if press F5, will trigger the event, if using the Back or Forward will trigger the event.
Still if you want to use, you must first understand some things, when Unload or beforeunload occurs the page already in pre-process of destroying/downloading and therefore no new windows/Guis will be generated.
That is to say, alert()
, confirm()
, prompt()
and window.open()
will not run, even if you wish, this is explained in the W3C specification https://www.w3.org/TR/html5/webappapis.html#user-prompts
note: Alert/confirm and others are also ignored in the event pagehide
So the only event you should use is the beforeunload
with the return '<string>';
, has one more problem your HTML this badly marked, it is not that it affects the execution, but still it should be this:
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<script>
//script vai aqui
</script>
</body>
</html>
However note that even using:
window.onbeforeunload = function(){
return 'Tchau';
};
Will not issue the desired text, he will only generate a standard message asking whether or not to download the page:
In other words, this is not just a "goodbye" message, nor is the Tchau
, is a resource to be used on certain occasions, to say goodbye is certainly not a good way to implement this.
Providing a good user experience
Say hi, say goodbye, is this really necessary? Does the user not know he is already leaving or when he entered the page?
I personally believe that these types of messages sound more like noise than something useful to the user, so much so that for many of these problems is that certain implementations have been removed from the browsers, many more things cause that sensation "to no, again that message", than really seem polite, the user will feel welcome on the site when he gets what he wants from the site, and not with a disturbing welcome message that hangs everything until it is pressed on the button ok
.
About the use of beforeunload
and unload
I explained, they are not to check when the person leaves the site, and there is no guaranteed way to do this, you can implement anything, detect internal and external links, but this kind of thing is unnecessary work, I personally recommend that you focus on creating a nice interface to navigate so that the user feels good when browsing, so yes he will feel welcome and when he leaves the site for sure he will want to come back.
What would be the beforeunload utility?
It would be more interesting if used to prevent you from losing edits made, or if it is a game to prevent you from leaving without saving the game, as this is exactly what the standard message says:
Wish to leave this site?
It is possible that changes made have not been saved
This is the focus of it currently, preventing the user from accidentally closing something and losing something.
I just edited the question, I tried it that way and I couldn’t either.
– Lucas Caresia
And is there any way to test if it’s working on google Chrome ??
– Lucas Caresia
@Lucascarezia works perfectly. See a test page at this link. Try to exit by clicking on the link, reload the page or close the tab.
– Sam
You had commented another method, however deleted the comment, could put it again ??
– Lucas Caresia
@Lucascarezia where?
– Sam
Right here, you told me to test another method (other than onunload and onbeforeunload) in Chrome, but you deleted the comment, and I was curious when to method.
– Lucas Caresia
@Lucascarezia Isn’t the link in the answer? https://answall.com/a/263488/8063
– Sam
Just for the record: the ability to define a
{String}
to the event "onbeforeunload" was removed in the Chrome 51, Safari 9.1 and Firefox 4– Lauro Moraes
@Lauromoraes Pois eh, Chrome, FF and Opera (if I’m not mistaken) ignore strings. They show their own confirmation box.
– Sam
@dvd It was a method
window.algumacoisa
same. But no problem. Is there any way to capture the Unload event even with the user not interacting with the page ?? (if you prefer I open another question).– Lucas Caresia
@Lucascarezia Wait a little while I’ll see... I’ll be right with you
– Sam
From the Chrome 60 and Firefox 44 respectively the events "beforeunload" and "onbeforeunload" require the user to have at least one interaction with the page
– Lauro Moraes
@Lauromoraes And there’s no way to "circumvent" it ??
– Lucas Caresia
No. This is default browser implicit in your "politics". The correct would be to follow the @dvd response and align to a strategy that makes the user interact at least once with the page.
– Lauro Moraes
@Lucascarezia I believe there is no way. The browser blocks any attempt to circumvent this, even simulating interaction.
– Sam
All right, I’ll do it. Thanks for your help.
– Lucas Caresia
@You’re welcome to Lucascarezia. Then, with more time, I’ll explore more of this, I think it’s a bit cheesy. I’ll let you know.
– Sam
@Perfect DVD, I’m waiting.
– Lucas Caresia
@Lucascarezia I put an update in the reply. It’s a way to force the user to click on the page.
– Sam