I have 3 buttons <input type="submit" name="submitButton" value="something">. Then i check the event with $(".form_name").submit(function(e) { and i would like to check which of the 3 buttons have been clicked and to alert the user of the action and return false if the user wishes to not go through with the action.
How do i check which of these buttons have been clicked?
event.target might help. Another workaround is to have the three buttons fire events, and make their event handler do the submission. In that sense there is no guesswork.
—
Personally I would first make sure that the three buttons have identifiers, plausibly tucked within with $(element).data lines, or custom HTML attributes (oh, don’t use special classes!), and have the event handler check $(event.target).data(key) or $(event.target).attr(key) to find out more information related to the caller. I would then map the form’s submit event also to this handler, so everything is processed from one place.
The Event interface gives information about the event. Look at this answer to know where you can find this object.
The target or scrElement of the object is the attribute you're looking for. See Quirksmode.org.
EDIT: you asked for a jQuery specific answer. You can just use event.target (in your case e.target), jQuery fixes this when necessary.
Related
What element here is the form object that i can attach a submit/onsubmit eventHandler too? I'm making a chrome extension that modifies a website so I don't exactly have access to the direct website code outside of inspect element.
Inspect Element Breakdown
<div class="search-inner" role="form">
I assume that its the highlighted one, and I'm using this code to try getting a reaction out of the eventListener, but it doesn't seem to activate.
const form = document.getElementsByClassName("search-inner");
if(form != null && form.length > 0){
form[0].addEventListener('onsubmit', run);
}
function run(event){
console.log("hi");
event.preventDefault();
}
The website does set up the form so that it does get hidden after submission, in case that affects the onsubmit eventHandler.
Adding the role attribute to elements only communicates their role to assistive technology, to tell users what they can expect in terms of the element’s behaviour, and to add it to document outlines. It does not actually change an element’s behaviour.
That’s why we should rely on semantic HTML elements whenever we can.
If a <form> doesn’t have an action attribute, it’s quite likely that it never gets submitted, but that its controls trigger changes based on other events. This is quite common in today’s reactive pages.
So if you actually want to target any form element that induces change to the DOM, it will get complicated, as most of the time they are not correctly grouped, neither with a form, nor with a <fieldset>.
Depending on what you’re trying to achieve, you could look for buttons in the form and bind to their click events.
// kind of selector you’d need to implement
form, [role="form"], [role="search"], fieldset {
button, input[type="button"], input[type="submit"] {
}
}
Unfortunately it is not really possible to check for registered event handlers on elements.
So, as #xOxxOm suggested, you might also listen for change events on the document level, maybe as an additional measure to see whether a button click inside the form changed something.
Btw, the form from your example is not valid, since it’s lacking its obligatory accessible name.
Also, it’s a search form, so the search role might be more appropriate, which doesn’t require a name, and you might consider it as well for your extension.
This is how the example should have been
<div class="search-inner" role="form" aria-labelledby="search-legend">
<fieldset>
<legend id="search-legend">
I've got a form where I'm trying to do the sort of thing you often see with tags: there's a textfield for the first tag, and, if you put something into it, a new and similar textfield appears to receive another tag. And so on. I've gotten the basics of this working by setting up a jQuery .blur() handler for the textfield: after the value is entered and the user leaves the field, the handler runs and inserts the new field into the form. The handler is pretty vanilla, something like:
$('input.the_field_class').blur(function () { ... });
where .the_field_class identifies the input field(s) that collect the values.
My problem is that, while the new textfield is happily added to the form after the user enters the first value, the blur handler doesn't fire when the user enters something into the newly-added field and then leaves it. The first field continues to work properly, but the second one never works. FWIW, I've watched for and avoided any id and name clashes between the initial and added fields. I had thought that jQuery would pick up the added textfield, which has the same class markings as the first one, and handle it like the original one, but maybe I'm wrong -- do I need to poke the page or some part of it with some sort of jQuery initialization thing? Thanks!
Without seeing your code in more of its context, it's hard to know for sure, but my best guess is that you're attaching a handler to the first field, but there is no code that gets called to attach it to the new field. If that's the case, you have a few options, two of which are:
1) In your blur() handler, include code to attach the blur handler to the newly created field.
2) Use jQuery's event delegation to attach a handler to the field container, and listen for blur events on any field in the container:
<div class="tag-container">
<input class="the_field_class" /> <!-- initial tag field -->
</div>
<script>
var $tagContainer = $('.tag-container');
var createNewField = function() {
$tagContainer.append($('<input class="the_field_class" />');
};
$tagContainer.on('blur', 'input.the_field_class', createNewField());
</script>
Which is better will depend on your use case, but I'd guess that the 2nd option will be better for you, since you're unlikely to be dealing with tons of blur events coming from the container.
I have a large form that contains several text input fields. Essentially, I need to handle the onchange event for all fields and the onblur events for some fields. When a change is made to a field and the field loses focus, both events fire (which is the correct behavior). The only issue is that I would like to handle the onblur
event before I handle the onchange event.
After some testing in ie and Firefox, it seems that the default behavior is to fire the onchange event before onblur. I have been using the following code as a test...
<html>
<body >
<input type="text" value="here is a text field" onchange="console.log('Change Event!')" onblur="console.log('Blur Event!')" >
</body>
</html>
Which brings me to my questions:
It seems that this behavior is consistent across browsers. Why does onchange fire first?
Since I cannot handle the onblur event for every input element, is there a way I can get onblur to fire before handling the onchange event?
The reason onchange fires first is that once the element loses focus (i.e. 'blurs') the change is usually complete (I say usually because a script can still change the element without user interaction).
For those elements that need onblur handled first, you can disable the onchange handler and fire the onchange (or even a custom event) from the onblur handler. This will ensure the correct order even though it is more work. To detect change, you can use a state variable for that field.
As a general remark though, the need for such synchronicity is a sign that the approach you are using to solve whatever problem you are solving might need more work even though sometimes it cannot be avoided. If you are sure this is the only way, try one of these methods!
EDIT: Just to elaborate on the last point, you would have to follow some assumptions about your event model. Are you assuming that each change event is followed by a blur and goes unprocessed otherwise, or would you like to process each change but those that are followed by a blurget further processing after whatever onblur does with them? In any case if you want to enforce the order the handlers would need access to a common resource (global variable, property, etc.). Are there other event types you might want to use? (input?). Finally, this link has some details for the change event for Mozilla browsers:
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/change.
The third 'bullet' addresses the issue of event order.
This is a bit of hack, but it seems to do the trick on most browsers:
<input type="text" value="Text Input" onchange="setTimeout(function(){console.log('Change Event!')}, 0);" onblur="console.log('Blur Event!');" />
You can see a fiddle of it in action here: http://jsfiddle.net/XpPhE/
Here is a little background information on the setTimeout(function, 0) trick: http://javascript.info/tutorial/events-and-timing-depth
Hope that helps :)
This drives me mad. I just can't understand it.
I wrote a filter-function based on checkboxes and clicking on their labels. I'm checking the 'checked' state of checkboxes and show mathed elements of the list (the rest elements are hidden). I use 3rdparty plugin that stylizes checkboxes (cut from example) and makes checkboxes checked while other onClick event does the filtering.
The problem is that after 'checked' state is successfully set inside a callback-function it "suddenly" becomes reset! I can't understand why that happens.
I implemented the base logic (without stylizing) here: http://jsfiddle.net/3Xtuh/13/
and ask all to help me solve this, please.
The problem is that you are invoking the click event manually, and then when your function is done running, the default click event is invoked.
By passing the event variable to your click handler and calling event.preventDefault(); fixes this behavior.
See example here: http://jsfiddle.net/3Xtuh/14/
The HTML label will check the associated checkbox even if it´s hidden (using CSS) so there´s no need to reinvent the wheel.
You should use the change() event. Try this demo and view your console.
It's default browser behavior that's messing your js script. By default, clicking on a label that is either wrapped around checkbox or have valid for attribute set, is toggling checked state of that checkbox.
You've attached custom onclick handler on labels.
So what's going on is that when clicking on a label? Your click handler gets fired (in in you alter state of target checkbox), and then
I've been endlessly looking for a working way to automate a mouse click on a specific element using javascript (I'm making a user-script). The structure is like the below:
<div id="elementContainer">
<div class="item1" style="width: 50px; height: 50px;">AutoClick Here!</div>
</div>
item1 is the thing I want to automate a click on. I've tried lots of approaches, e.g. getting the element and creating/initialising/dispatching a 'click' event on it, calling .click() on it etc, but to be honest I'm new to javascript and don't hugely know what I'm doing!
I can happily get the element and make changes to it (like changing the innerHTML), but want to be able to simulate/automate a click on it too. I would be very grateful for any advice on how to proceed.
Many thanks in advance!
Calling .click() on the element should work just fine.
var container = document.getElementById('elementContainer'),
innerDiv = container.getElementsByClassName('item1');
innerDiv.click();
That said:
The click method is intended to be used with INPUT elements of type button, checkbox, radio, reset or submit. Gecko does not implement the click method on other elements that might be expected to respond to mouse–clicks such as links (A elements), nor will it necessarily fire the click event of other elements.
Non–Gecko DOMs may behave differently.
When a click is used with elements that support it (e.g. one of the INPUT types listed above), it also fires the element's click event which will bubble up to elements higher up the document tree (or event chain) and fire their click events too. However, bubbling of a click event will not cause an A element to initiate navigation as if a real mouse-click had been received.
Have you bound any click event handlers to that <div>?
Read this: http://www.howtocreate.co.uk/tutorials/javascript/domevents