Has anyone else run into the issue where handling a click event on a submit button for a form with preventDefault stops autocomplete from working?
To be specific it simply never prompts to save the username and password combination, I assume this is because it is triggered on a post request which doesn't occur in my case.
Can anyone think of a workaround?
PS: I have only tested in IE but am willing to bet I will see similar issues in the other browsers (will test shortly).
You have three options when altering the flow of an event:
e.preventDefault()
e.stopPropagation()
return false (calls both of the above).
Maybe trying using e.stopPropagation() instead, and see what that does for you.
Related
I have a situation where an anchor fires the 'click' event before the input, which loses the focus and fires the 'focusout' event.
To be clear, I write something in the input and then I click the anchor. I'm expecting the 'focusout' event to be written to console first and then the 'click' event.
I'm not able to reproduce this in a dummy app like in the code below, it only reproduces in the web app I'm working on, which I can't share here.
click me
<input type="text" id="t">
<script>
document.querySelector("#a").addEventListener('click', function(e) {
console.log('click');
});
document.querySelector("#t").addEventListener('focusout', function(e) {
console.log('focusout');
});
</script>
Any idea how could it be possible for anchor to fire the 'click' event first before the input firing 'focusout' event?
I'm pretty dazzled how it's actually possible... I can't see how in the world, even if I wanted to, be able to make the 'click' fire first. I checked several times the event object in watcher in Chrome dev tools and I can't see anything peculiar
I'm using latest Chrome on Windows 10
The change event doesn't fire until the input loses focus. You can use onkeypress instead.
Ironically enough, it seems like jQuery .focusout / .click conflict has the exact opposite problem as you. From what I'm reading around the web it seems like the general concesus is that the HTML specification doesn't actually specify the order of events and it is up to the browser to implement however they see fit. However, in your case I would certainly expect focusout to happen first, tho clearly it isn't. Have you tried "onblur" instead?
I found it! This is one of those things which doesn't let you sleep well.
The issue was somewhere else, in some library, there is a mousedown handler on the anchor with a e.preventDefault():
http://jsfiddle.net/vynd7kgj/
This sucks. I don't know if I should cry or laugh.
Why would you want to do something like this?
I have a site which has three radio inputs and based on which input is selected parts of the html page around it will change. Everything works perfect except in IE8(of course). My issue for this page is that when I click on the input which has an event listener of 'change' on it, nothing will happen, it is only until it is clicked the second time that the event will fire. I know that IE8 doesnt handle addEventListeners but I am using a pollyfill for all this and am using addEventListeners for tons of other things on the site and they work fine.
The second thing to note is that everything works fine in IE8 if I switch the event listener to a 'click' event. The only issue and reason why im not just switching it to 'click' is because of tabbing. I still what the user to still be able to tab through the form for a proper UX.
Lastly when I bring the site up in my VB for IE8, this functionality(even with the 'click' event) will not work until I put it in debugging mode and it finds all the polyfill.min.js errors. Then I can stop debugging and everything will then work as intended. I will provide a picture of my errors. I have no idea why and what is causing them. My guess would be some external script I am pull for third party functionality maybe. Cant figure that out yet.
here is how the function is being called,
Here is where the function is called:
function attachToggleReportType (elem) {
console.log('Trigger attachToggleReportType');
elem.addEventListener('change', toggleReportType, false);
}
And here is the main function for the actions to happen based on the event
function toggleReportType () {
console.log('Trigger toggleReportType');
var reportOptions = document.querySelectorAll('.report'),
reportIncToggle = document.querySelectorAll('.toggle');
console.log(this.getAttribute('data-sample-report-link'));
reportSample({
href: this.getAttribute('data-sample-report-link'),
src: this.getAttribute('data-sample-report-image'),
title: this.getAttribute('data-sample-report-title')
});
reportIncToggle.forEach(toggleInclude);
}
So I found a solution for my problem. It is not perfect but it worked fine for me, for now. It was a pretty odd issue because in IE8 my event listener with a type of 'change' would always have a click delay on it. So no matter which radio I would click, the only time the event would fire is when I clicked again anywhere on the screen the second time. I know IE8 doesnt handle addEventListeners but I was using a polyfill for accommodate this. I also would get a polyfill error when in debug mode, so I wonder if this is an issue related to that. Anyways, i resolved this issue for now by including a 'change' event listen for modern browsers, then in IE8 i switched it to an on 'focus' event and everything works perfectly still. I hate the idea of having two event types but it was the only way to resolve this bug. Also to note, the change event still worked in IE8 on the second click, so trying to detect if the browser could handle this event type wasn't an option for me.
I was thinking of forcing an onblur handler to run by calling the element's blur method. But then, I thought it wouldn't work, because I remembered that calling submit on a FormElement does not cause its onsubmit method to be run.
After some experimentation, I found that calling blur does cause the element's onblur handler to get called. This seems very inconsistent, not that it surprises me (this is JS after all). Still, if there's a good reason for this, I'd like to know. Is there a good reason to call the handler in the case of blur but not submit?
I agree it seems inconsistent. My take is that OnSubmit behavior has a ton of legacy baggage because much of its functionality was designed so that people could code right inside of form elements. To this end onsubmit was used to validate input without cracking open a source editor or javascript file. My guess is that when they coded this behavior (a long time ago), this seemed wise because once you are in javascript the programmer can easily validate the input themselves so the automatic check isn't necessary. Seems like an oversight to me.
This following website on quirksmode specifically warns of this, so clearly many people are being confused by this.
http://www.quirksmode.org/js/forms.html
I have a certain situation I want to clarify for myself, and I would be glad if anyone has any experience with this issue and is willing to explain it to me.
I have a textarea that has a change event handler:
textarea.bind('change', function(event){
// do something
});
Hypothetically, what if I have some sort of a click event handler that catches all user clicks:
$(document).bind('click', function(event){
event.preventDefault();
});
Will this handler also cancel blur and change events for a textarea if a user clicks out of it with his mouse? And if it will, how can I prevent this from happening?
Update: Thank you for your answers, I can not say that I tried it, but I have a similar situation and I am trying to rule out possibilities why change is not firing on my textarea. In my case there is a change handler that doesn't work if I click on an area in which all click events are prevented by default and replaced with custom behaviour.
No, it will only prevent the default browser behavior for the 'click' event.
No, it won't.
Hypothetically, what if you just tried it? (answer: it won't, as stated just before me)
If you don't want users to be able to leave a inputfield (which sounds like strange user interaction to me), you might be able to just set focus after a blur/change event - perhaps you would need a small timeout to let the event finish first. I would not recommend it, but it's always worth a try.
I am binding an event to a checkbox's change or click event which works fine in Firefox but in IE I have to click anywhere else (causing the blur) event before the event is fired.
I have read and believe this is down to the way IE fires the events, but is there anyway I can get round it?
The whole point is that it is a smooth search feature which doesn't need a search button to be clicked
$('#sidebar .itemSearchModule-Form input[type=checkbox]').click(function() {
$('#sidebar .itemSearchModule-Form .saveButton').click();
});
The change event requires a blur to happen first. The Click event should not. You could always force a blur event if you wanted by $(elem).blur()
Paolo Bergantino was right so this answer credit should go to him.
It seems my code was all screwed up and another selector was getting tied up with the sample I used above.
The CLICK event does work in IE I can confirm, if you are suffering the same problem ALL I can suggest is you check your code
try giving that checkbox a class like chkbx and try:
$('.chkbx').click(function() { etc...
its just for debuggin your selector.. being sure problem is in the action. i think for IE you need to use GetElementByID.