My intent is to throttle the click listener on some links and form submit buttons. The main idea was something like:
Click
<script>
window.onload = function() {
tags = document.findElementsByClassName("throttled-click");
for (let tag of tags) {
tag.onclick = _.throttle(tag.click, 1000, { 'trailing': false });
// Clearly doesn't work
}
}
</script>
The code above doesn't really work since no matter what I do, the default click event listener won't get throttled. If I pass in some other function (e.g. console.log("Throttled")), it will be throttled but the default click event listener won't.
Other than attempting to write my own throttling function, I'm out of ideas.
Note that I'm not a js dev so I may be missing something obvious.
EDIT: The goal of throttling the default click event listener is to prevent users from submitting too many forms when something hangs. Granted, form submissions usually entail a redirection which implicates that it's enough to simply disable the HTML click event after the first click.
My idea was to implement a throttle for cases when the page won't refresh or some edge case occurs where the request never reaches the server and the user actually has to click the submit button again.
I was able to do it with a custom implementation, I don't think there's a way to do it with existing standard libraries which I find kind of strange.
Sorry if duplicate, but I don't understand how I can use the basic approach in my case.
I need to hide some div, when user presses back button in browser. That is all what I need. The page must not to be reloaded. I tried this way:
window.onpopstate = function (event) {
event.preventDefault();
alert("Back button pressed");
myDiv.style.display = 'none';
}
But this doesn't work at all. Even alert doesn't fire. And the browser goes back as always.
How to make it work? First of all this must works in mobile browsers.
Will the using of window.location.hash trigger page reloading or not?
Short answer: You can't change it.
Long answer:
You should first set a State then get it with event handler.
So, simply, when user clicks on a specific section of your document, for example a <a>, you set a State then when he clicks on back button ( of browser ) you've got a fired event.
someElement.addEventListener( 'click', function( e ) {
history.pushState({ state: 'someElement was clicked' }, 'title', 'some-element.html' );
})
Now, as back button pressed, you've got an alert ( as presented in your question ).
For furthur information check here: Manipulating the browser history( mdn )
No, changing the location hash will not do a page reload (this is where all Single Page Applications are based upon.
Preventing the behaviour after the back button is clicked (which will trigger a page reload) is not really an option. Best you can do is warn the user:
window.onbeforeunload = function() {
return 'Sure you want to leave?';
};
SETUP - Large search with many criteria as a POST via a html submit button, it can take several seconds before the first byte is sent by the server / results page starts loading.
http://api.jquery.com/unload/ is now deprecated (as of version 1.8), and I'm searching for the CORRECT way to do the following...
When someone clicks the search button, I give the user a little feedback by setting the button text to "Searching...", then allow the submit to continue (return true):
$('#dosearch').click(function() {
$(this).html('<i class="icon-spinner icon-spin"></i> Searching...');
return true;
});
During unload I'm currently doing this:
$(window).unload(function() {
$('#dosearch').html('<i class="icon-search"></i> Search');
});
I tried binding to beforeunload, but that fires as soon as the submit happens (bad), not as soon as the browser begins rendering the new page (good).
The problem is if they click search and then click the BACK button on their browser. If they do that, then the Searching... text is still shown.
What is the correct / proper way to do what I'm attempting here?
NOTE: (The reason for the I tag is that I'm using font awesome).
Binding an empty event handler to unload seems to work, but it's kind of a hack.
$('#dosearch').click(function() {
$(this).html('<i class="icon-spinner icon-spin"></i> Searching...');
return true;
});
$(window).on("load", function(){
$('#dosearch').html('<i class="icon-search"></i> Search');
});
$(window).on("unload", function(){
// Leave this blank handler here or onload won't fire on IE or FF when you click back button
});
See this question for explanation.
If the user goes back in history, it means it renders the page new or not? So you could, whenever the page is loaded, reset the value to what you want to.
Could that be something?
I'm developing one of those warning windows that tells the user that they may have unsaved data, but I only need it to warn them if they're leaving the page. Currently it does so on refreshes, postbacks, etc. I was wondering if there was any way to tell how the page was unloaded or otherwise get more details about what the user is doing to unload the page. (jquery solutions welcome).
Code for reference:
window.onbeforeunload = function () {
if (formIsDirty) {
formIsDirty = false;
return "Are you sure you want to navigate away from this page?";
}
}
on beforeunload event we can do below things:
We can pass event as a parameter to the function as in above answer.
Now we can use this event for available information attached to this
event.
And we can access Document level variables.
For example document.activeElement will give you the last element you clicked that caused the page unload.
Hope this helps!!
I think that the active element is not a valid solution.
I can't comment the "open and free" solution, I dont have reputation.
document.getActiveElement gets the currently focused element in the document. If a link have the focus and I press F5 or I close the tab the active element is the link.
Short answer: There's no easy way to find out what is causing onbeforeunload to fire.
Long answer: Inside your window.onbeforeunload handler you can access the window.event object, which may have some useful properties to determine how the window is closing.
For example, if window.event.srcElement is an anchor tag, then you know that the onbeforeunload event is firing by an anchor tag being clicked.
Refer to the event and onbeforeunload pages on MSDN for more properties.
Edit: some more info I have stumbled across -
If you want to ignore ASP controls that cause post-back, you can interrogate the '__EVENTTARGET' hidden input. If this input has a non-empty string value, then the page is being posted back by an ASP control.
You could also check the keyCode property (if F5 has been pressed, causing a refresh) or the mouse position to see if the X (close) button has been clicked.
I was running into a simular issue when a user was hitting enter from an input field on a form. The form was being submitted thus firing off the onbeforeunload event. I tried setting a flag to avoid showing the message on the keydown event on the input, filtering on the enterkey code. This wasn't getting triggered until after the onbeforeunload event was firing and therefore the flag wasn't getting set.
I then looked into the _EVENTTARGET as jbabey suggested. If the form was being submitted there would be a value in that field, if it was being refreshed there wouldn't.
Therefore, doing a simple check to see if there was value in the _EVENTARGET field in the onbeforeunload event could determine if the input from the form was causing the postback.
Here is my code.
window.onbeforeunload = function (e) {
if ($('[id$=__EVENTTARGET]').val().indexOf('btnValidateMaterials') != -1) {
confirmExit = false;
}
if (DateOrQtyHasChanged() && confirmExit) {
if (/Firefox[\/\s](\d+)/.test(navigator.userAgent) && new Number(RegExp.$1) >= 4) {
var message = $('[id$=hfLeaveMessageFF]').val();
if (confirm(message)) {
history.go();
}
else {
window.setTimeout(function () {
window.stop();
}, 1);
}
}
else {
var message = $('[id$=hfLeaveMessage]').val();
return message;
}
}
}
Many times I've seen links like these in HTML pages:
<a href='#' onclick='someFunc(3.1415926); return false;'>Click here !</a>
What's the effect of the return false in there?
Also, I don't usually see that in buttons.
Is this specified anywhere? In some spec in w3.org?
The return value of an event handler determines whether or not the default browser behaviour should take place as well. In the case of clicking on links, this would be following the link, but the difference is most noticeable in form submit handlers, where you can cancel a form submission if the user has made a mistake entering the information.
I don't believe there is a W3C specification for this. All the ancient JavaScript interfaces like this have been given the nickname "DOM 0", and are mostly unspecified. You may have some luck reading old Netscape 2 documentation.
The modern way of achieving this effect is to call event.preventDefault(), and this is specified in the DOM 2 Events specification.
You can see the difference with the following example:
Google
Clicking "Okay" returns true, and the link is followed. Clicking "Cancel" returns false and doesn't follow the link. If javascript is disabled the link is followed normally.
WHAT "return false" IS REALLY DOING?
return false is actually doing three very separate things when you call it:
event.preventDefault();
event.stopPropagation();
Stops callback execution and returns immediately when called.
See jquery-events-stop-misusing-return-false for more information.
For example :
while clicking this link, return false will cancel the default behaviour of the browser.
<a href='#' onclick='someFunc(3.1415926); return false;'>Click here !</a>
Here's a more robust routine to cancel default behavior and event bubbling in all browsers:
// Prevents event bubble up or any usage after this is called.
eventCancel = function (e)
{
if (!e)
if (window.event) e = window.event;
else return;
if (e.cancelBubble != null) e.cancelBubble = true;
if (e.stopPropagation) e.stopPropagation();
if (e.preventDefault) e.preventDefault();
if (window.event) e.returnValue = false;
if (e.cancel != null) e.cancel = true;
}
An example of how this would be used in an event handler:
// Handles the click event for each tab
Tabstrip.tabstripLinkElement_click = function (evt, context)
{
// Find the tabStrip element (we know it's the parent element of this link)
var tabstripElement = this.parentNode;
Tabstrip.showTabByLink(tabstripElement, this);
return eventCancel(evt);
}
Retuning false from a JavaScript event usually cancels the "default" behavior - in the case of links, it tells the browser to not follow the link.
I believe it causes the standard event to not happen.
In your example the browser will not attempt to go to #.
Return false will stop the hyperlink being followed after the javascript has run. This is useful for unobtrusive javascript that degrades gracefully - for example, you could have a thumbnail image that uses javascript to open a pop-up of the full-sized image. When javascript is turned off or the image is middle-clicked (opened in a new tab) this ignores the onClick event and just opens the image as a full-sized image normally.
If return false were not specified, the image would both launch the pop-up and open the image normally. Some people instead of using return false use javascript as the href attribute, but this means that when javascript is disabled the link will do nothing.
using return false in an onclick event stops the browser from processing the rest of the execution stack, which includes following the link in the href attribute.
In other words, adding return false stops the href from working. In your example, this is exactly what you want.
In buttons, it's not necessary because onclick is all it will ever execute -- there is no href to process and go to.
The return false is saying not to take the default action, which in the case of an <a href> is to follow the link. When you return false to the onclick, then the href will be ignored.
Browser hack:
http://jszen.blogspot.com/2007/03/return-false-to-prevent-jumping.html
Return false will prevent navigation. Otherwise, the location would become the return value of someFunc
The return false prevents the page from being navigated and unwanted scrolling of a window to the top or bottom.
onclick="return false"
I am surprised that no one mentioned onmousedown instead of onclick. The
onclick='return false'
does not catch the browser's default behaviour resulting in (sometimes unwanted) text selection occurring for mousedown but
onmousedown='return false'
does.
In other words, when I click on a button, its text sometimes becomes accidentally selected changing the look of the button, that may be unwanted. That is the default behaviour that we are trying to prevent here. However, the mousedown event is registered before click, so if you only prevent that behaviour inside your click handler, it will not affect the unwanted selection arising from the mousedown event. So the text still gets selected. However, preventing default for the mousedown event will do the job.
See also event.preventDefault() vs. return false
I have this link on my HTML-page:
<a href = ""
onclick = "setBodyHtml ('new content'); return false; "
> click here </a>
The function setBodyHtml() is defined as:
function setBodyHtml (s)
{ document.body.innerHTML = s;
}
When I click the link the link disappears and the text shown in the browser
changes to "new content".
But if I remove the "false" from my link, clicking the link does (seemingly) nothing. Why is that?
It is because if I don't return false the default behavior of clicking the link and displaying its target-page happens, is not canceled. BUT, here the href of the hyperlink is "" so it links back to the SAME current page. So the page is effectively just refreshed and seemingly nothing happens.
In the background the function setBodyHtml() still does get executed. It assigns its argument to body.innerHTML. But because the page is immediately refreshed/reloaded the modified body-content does not stay visible for more than a few milliseconds perhaps, so I will not see it.
This example shows why it is sometimes USEFUL to use "return false".
I do want to assign SOME href to the link, so that it shows as a link, as underlined text. But I don't want the click to the link to effectively just reload the page. I want that default navigation=behavior to be canceled and whatever side-effects are caused by calling my function to take and stay in effect. Therefore I must "return false".
The example above is something you would quickly try out during development. For production you would more likely assign a click-handler in JavaScript and call preventDefault() instead. But for a quick try-it-out the "return false" above does the trick.
When using forms，we can use 'return false' to prevent submitting.
function checkForm() {
// return true to submit, return false to prevent submitting
}
<form onsubmit="return checkForm()">
...
</form>
By default, when you click on the button, the form would be sent to server no matter what value you have input.
However, this behavior is not quite appropriate for most cases because we may want to do some checking before sending it to server.
So, when the listener received "false", the submitting would be cancelled. Basically, it is for the purpose to do some checking on front end.