X
Нажмите здесь, чтобы перейти на мобильную версию сайта.

Форум поддержки

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

Размещено

$("#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.

Выбранное решение

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.

Прочитайте этот ответ в контексте 0

Дополнительные сведения о системе

Это случилось

Каждый раз при открытии Firefox

Это началось когда...

After updateing to latest version of FF (15)

Установленные плагины

  • Shockwave Flash 11.4 r402
  • Adobe PDF Plug-In For Firefox and Netscape 10.1.4
  • Google Update
  • Winamp Application Detector
  • 4.1.10329.0
  • Next Generation Java Plug-in 1.6.0_31 for Mozilla browsers
  • NPRuntime Script Plug-in Library for Java(TM) Deploy
  • Intel WebAPI Updater - Installs and updates Intel WebAPIs
  • Inte IPT Web API
  • VMware Remote Console and Client Integration Plug-in
  • wpidetector
  • NPWLPG
  • Fortinet SSL VPN FortiControl Firefox Plugin
  • Fortinet SSL VPN CacheClean Firefox Plugin
  • The plug-in allows you to open and edit files using Microsoft Office applications
  • Office Authorization plug-in for NPAPI browsers

Приложение

  • User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0

Дополнительная информация

This code no longer gets fired with the latest version
$("#dealer-warranty-parts-percent").bind('change', function(){
data.partsPercent = $(this).val();
AMMS.dealerWarrantyModified = 1;
});

jscher2000
  • Top 10 Contributor
8899 решений 72797 ответов
Размещено

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.

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.
Mygind 0 решений 6 ответов
Размещено

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.

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.
Mygind 0 решений 6 ответов
Размещено

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

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: # Start the page # Open firebug # Turn on logging event as described in earlier post # Type in a letter in input box and use mouse to click on button (note change event fired) # Click "Shift-Tab" and type another letter in input box # Use "Tab" key to advance to submit button and observe that "onChange" did not fire. # Repeat process until you are satisfied that the "'''onChange'''" is broken in FF 15.0.1 Other notes. # If you comment out the one line of code in the "'''onKeyPress'''" function the tab key will fire the "'''onChange'''" event. # 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

Изменено Mygind

rchicangana 0 решений 5 ответов
Размещено

Полезный ответ

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

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
jscher2000
  • Top 10 Contributor
8899 решений 72797 ответов
Размещено

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.

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.

Изменено jscher2000

Mygind 0 решений 6 ответов
Размещено

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.

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.

Изменено Mygind

jscher2000
  • Top 10 Contributor
8899 решений 72797 ответов
Размещено

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.

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.
Mygind 0 решений 6 ответов
Размещено

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.

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.
rchicangana 0 решений 5 ответов
Размещено

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

just leave the version 16.01, and the bug is already fixed
Mygind 0 решений 6 ответов
Размещено

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

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