Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

The change event is not firing when bound to a input text field in FF 15

  • 30 uphendule
  • 23 zinale nkinga
  • 1714 views
  • Igcine ukuphendulwa ngu Mygind

more options

$("#dealer-warranty-parts-percent").bind('change', function(){ data.partsPercent = $(this).val(); AMMS.dealerWarrantyModified = 1; });

This code will not fire in the latest (FF 15) version of FF but does fire in the previous version. I am now having to switch to blur event.

$("#dealer-warranty-parts-percent").bind('change', function(){ data.partsPercent = $(this).val(); AMMS.dealerWarrantyModified = 1; }); This code will not fire in the latest (FF 15) version of FF but does fire in the previous version. I am now having to switch to blur event.

Isisombululo esikhethiwe

Never mind after further digging in the code there appears to be an issue with binding the keyup event that was deeper in the code that appears to be the ultimate culprit.

Funda le mpendulo ngokuhambisana nalesi sihloko 👍 0

All Replies (10)

more options

I tested an XHTML 1.0 Transitional page and got the same sequence. Does your page have multiple event handlers? Perhaps in that context something has changed.

more options

First off, sorry for the slow response. I only work one day a week.

Following the suggestions posted here, I logged the events on my suspect field and the "onChange" event did not fire when the tab key was pushed.

I repeated the process with the mouse and the "onChange" did fire and return the ajax call.

Then I created a simple two control page, one input and one submit button html page where I assigned onKeyPress, onChange, onBlur. With this simple page the onChange did fire with the tab key. Note that this new error about the "character encoding not being declared" did occur in the simple two control app, but did not affect the onChange event firing.

See attached photos.

I use the same html editor for both apps. From this I can now conclude that something in the block code or functions called in my failing app is preventing the onChange from firing.

Any further suggestions would be appreciated.

more options

Ok, I have now created some reproducible code, which will demonstrate how the "onChange" event is broken in FF 15.0.1. (see photo of code)

Take the following steps to see the problem:

  1. Start the page
  2. Open firebug
  3. Turn on logging event as described in earlier post
  4. Type in a letter in input box and use mouse to click on button (note change event fired)
  5. Click "Shift-Tab" and type another letter in input box
  6. Use "Tab" key to advance to submit button and observe that "onChange" did not fire.
  7. Repeat process until you are satisfied that the "onChange" is broken in FF 15.0.1

Other notes.

  1. If you comment out the one line of code in the "onKeyPress" function the tab key will fire the "onChange" event.
  2. I tighten up the code to snap the screen shot of the code. Before I did that the "blur" event fired every time. Now for me at least that does not fire when the input field looses focus.

Comments on how to work around this problem would be appreciated. Hopefully this problem will be corrected in FF 15.0.2

Okulungisiwe ngu Mygind

more options

I report this problem in bugzilla, and already corrected the beta version of Firefox 18.01.a https://bugzilla.mozilla.org/show_bug.cgi?id=788158

more options

So... having a keypress event that changes the value in the input blocked the change event? That does sound like a bug since the value of the input changed twice! Hmmm, maybe that was the problem: the second change somehow broke the handling for the first change, and yet did not fire the event again?

Edit: Thank you for all the extra research. Hopefully this will help others facing the same issue.

Okulungisiwe ngu jscher2000 - Support Volunteer

more options

jscher2000 - "Hmmm, maybe that was the problem: the second change somehow broke the handling for the first change, and yet did not fire the event again? "

No it is not the double change that breaks the event handling on the tab key, that is only the sequence I chose to demonstrate that it works with the mouse click and not the tab key. You could reverse the procedure or not use the mouse at all to and still see that the tab key did not fire the onchange event after a letter is type into the control.

The problem is multiple event handlers bound to one control breaks the "onChange" event handler for the tab key.

But it looks like, as rchicangana has reported, that it will have to wait until FF 18.0.1.a before we will see a fix to this problem. Too bad it could not be worked into the next release.

Okulungisiwe ngu Mygind

more options

Hi Mygind, I wasn't referring to the two methods of user navigation. In your example, the keypress event handler changed the value in the control by making the text upper case. In other words, there was a change in value by the user AND a change made your script BEFORE the first change event was handled. I was speculating that this scenario created the problem. However, I haven't built my own test case to explore that.

more options

Ok then we are on the same page. That is exactly what is happening. However, it may be more than that. I believe in my own scenario, I am not changing the content, I am setting some other flags. So I believe it is any other event handler firing some code which breaks the tab key event handler.

Thanks for following up.

more options

just leave the version 16.01, and the bug is already fixed

more options

Yep! version 16.0.1 fixed the problem with tabbing out of a field and having onChange fire. Back in business

  1. 1
  2. 2