355367 - textbox onchange doesn't fire if user tabs out and value changed in onkeydown

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[voracity]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0

If the onkeydown event of a textbox alters the contents of that same textbox, the onchange event won't fire if the user presses tab to move out of the control. This used to work in Firefox 1.5 and works in IE.

Not sure how common a problem it is --- in my case, it breaks my dhtml autocomplete when I want to use it with an onchange event (workaround is to trigger the onchange manually).

Will attach a very simple testcase.

Reproducible: Always

Comment 1

[voracity]

Attachment: onchange not firing

I forgot to mention that I did a search and found this regression (if it is one) might be related to Bug 313337.

Comment 2

[Jesse Ruderman]

I can reproduce as described on Mac, using Firefox trunk.

This doesn't seem like a bug to me.  Onchange does not fire for script changes, IIRC, to avoid infinite loops.  But since you say this changed between Firefox 1.5 and Firefox 2, it would be nice to know why it changed...

Comment 3

[Jesse Ruderman]

You can work around this by excluding the tab key from the special onkeydown handling, right?

Comment 4

[voracity]

Yes, avoiding tabs in the keydown event (e.g. onkeydown="if (event.which!=9) {this.value+='_';}") does allow onchange to fire when tab is pressed. But this doesn't solve the problem in my autocomplete case, since the textbox value is set in the onkeydown handler precisely when tab is hit (after some initial characters have been typed in, of course).

Comment 5

[Jesse Ruderman]

Hmm.  Have you tried having your autocomplete script fire an onchange event manually?  (e.g. calling foo.onchange(), or using init*Event?)

Comment 6

[voracity]

Yes, calling foo.onchange() is what I've used as a workaround. Unfortunately, I have to use browser sniffing so it doesn't trigger twice.

Incidentally, I had also tried the initMutationEvent/initUIEvent methods with no luck, even when they were called from somewhere other than the onkeydown --- in contrast, simulating a mouse click with initMouseEvent worked. There's nothing in the dev.moz wiki on it, but from the w3c events spec, I figured this would work, but it doesn't:

var evt = document.createEvent("MutationEvents");
evt.initMutationEvent("change", true, true, textbox, 0, 0, 0, 0);
textbox.dispatchEvent(evt);

Comment 7

[voracity]

I've just found this bug to be more extensive than I initially realised. The problem also occurs when the value is changed from onblur, onkeyup, onkeypress, etc. In fact, it even occurs with onmouseout/onmouseover *IF* you mouse out at the same time that the onchange is supposed to fire. (You can test by replacing 'onkeydown' in the testcase with any of the other events.)

In other words, whenever the textbox value is supposed to fire an onchange event, but there is some other thread that updates the textbox's value at roughly the same time, onchange doesn't fire.

Comment 8

[Daniel Bachran]

I think I'd like to confirm this bug. At least, this is probably the bug I was looking for...

I have recently switched from Firefox 1.5.0.7 to Firefox 2 and noticed that FF 2 sometimes does not "accept text form input" anymore. This means, that I can enter text in the input form, but whenever I "focus out of the text box", the affected web page does not recognize the entered text.

This happens on several pages on our intranet, so I can't post another test case here. But checking the page source revealed that those pages also use onChange to trigger the respective JavaScript function.

I'm using the official FF 2 release:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/2006101023 Firefox/2.0

This is highly annoying, as it means that I'll have to resort to using IE on those pages... *eek*

Comment 9

[Daniel Bachran]

Ah, after digging into bugzilla a bit more, searching for onchange, I think I found the bug which is affecting my usage pattern: bug 359387. This is slightly different from this bug, so my previous statement may actually be wrong.

Sorry for the bug spam, Daniel :)

Comment 10

[Ronny Hanssen]

I confirm the problem as described. I also can conform that this worked in FF1.5 (and for - whatever it's worth also in IE6)

Our case is that we formats form-field content (value) on blur. The fields are numeric and needs to be formatted with two decimals (".00"). When the content changed (by the user) the onchange event used to fire. However. After FF2.0 the behavour was "odd". After some investigation we seem to have narrowed down the problem as much as possible.

If: 
* the field says "100.00" before entering the field, 
* the user then enters "200" [changed by user],
* then exits the field,
* the onblur event is fired (as it should): 
  Here we pretty print the number by writing the value to be "200.00"
  [written programmatically - from "200" to "200.00" => changed],
* then the onchange event is NOT fired (but should have fired). 

However - if:
* the field says "100.00" before entering the field, 
* the user writes "200.00" [changed by user],
* then exits the field,
* the onblur event is fired (as it should): 
  Here we pretty print the number by writing the value to be "200.00"
  [written programmatically - from "200.00" to "200.00" => not changed],
* then the onchange event IS fired (as expected).

In both cases above the user has changed the field and we want to capture that change in an onchange handler.

But why doesn't the onchange fire in both cases? I think this happens:
* The first case fails. When the user types text the internal dirty bit is set. Then, in the onblur handler we set field.value - and the value is different. Since it was programmatically changed it *resets* the dirty bit for the field. Hence, the onchange doesn't have to fire anymore, since it thinks it isn't changed (when it is indeed was)!
* The second case works. When the user types text the internal dirty bit is set. Then, in the onblur handler we also here set field.value, but the value is the same. It was programmatically changed, but since the value written to field.value is exactly the same it *doesn't* change the dirty bit. It is still dirty, and hence the onchange fires - as it should.

How to fix? I guess that the onchange dirty-bit has to compare the contents of the field as they were before the onfocus and after the onblur events, before deciding whether to fire or not. I have not studied the W3C enough to tell if this is according to W3C specs. I guess someone with more knowledge in this area can point out if this is a compatible solution.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The behavior here changed between 2006-07-05-01 and 2006-07-06-01.  What happened there is that bug 313337 got fixed.

Sounds like IE's behavior is more complicated than just not firing onchange if script sets the value.  :(

Comment 13

[publicjanak]

Attachment: examples of onchange not firing when it should for several different javascript changes

Comment 14

[publicjanak]

As [e-mail] says, this bug affects any programmatic changes of value.  However, the change doesn't have to occur right as the onchange handler is supposed to fire.

http://workshift.usca.org/change_bug.html has a few examples, also attached above.  In these cases, the event which changes the value of the box does not also trigger the onchange -- the onchange event is triggered by the next event, of the user leaving the box.

Comment 15

[publicjanak]

It looks like both examples no longer work with IE 7 -- I see the same incorrect behavior as with Firefox 2, in which the change handler does not fire because presumably the "initial" value of the text box has been set to the value post-javascript change.

Comment 16

[cc young]

fails HTML Test Suite for this very case:

http://www.w3.org/WAI/UA/TS/html401/cp0102/0102-ONCHANGE-TEXTAREA.html

Comment 17

[Tonnerre Lombard]

This also fails on Seamonkey 1.1

Comment 18

[Tonnerre Lombard]

See also http://tonnerre.users.bsdprojects.net/tmp/formtest.html

Comment 19

[Daniel Veditz [:dveditz]]

Don't see how this can be a blocker after shipping in five 2.0 releases. Is there more to the nomination that isn't being said? Without an assignee it doesn't look hopeful.

Comment 20

[Boris Zbarsky [:bzbarsky]]

I think the fact that it shipped in those five releases is a serious mistake.  And I think that our policy of "we didn't fix it before, so there's no need to fix it now" makes no sense.

This is a correctness regression from a branch security fix; I really feel we need to have a zero-tolerance policy for those. Otherwise the quality (in terms of correctness) of our branch builds will consistently decrease, since we generally don't take overall correctness fixes on branches.

I guess we'll fix it "sometime" since it _is_ blocking 1.9, and should land it on branch then...  but again I really feel that this is the sort of thing we really don't want to have happening on branches.

Comment 21

[Daniel Veditz [:dveditz]]

I'm not happy about the situation either but unhappiness isn't getting the bug fixed. We _should_ fix regressions, but I don't have the energy left to dragoon someone into it after trying to find folks to fix bugs with security impact.

Comment 22

[Daniel Veditz [:dveditz]]

Clearing the specific version blocking flag lest a minus be interpreted as "we won't take this". It's "wanted", ask for approval when there's a patch. If it's not important enough to fix on trunk then we're not going to hold our breath for a branch fix.

Picked an assignee based on the regressing bug.

Comment 23

[Johnny Stenback (:jst)]

Smaug agreed to look into this one.

Comment 24

[siciliano]

I confirm this bug. I am using FF 2.0.0.4 on Windows XP SP2 at the moment. For now I cannot check on Linux and Solaris.

Error:
The onchange event is not fired in a text-input when the user selects an item from the FF-autocomplete-list. onblur is always fired. This is very annoying, because I don't want to react on onblur if data is formatted and inserted in hidden fields only when it changes.

To reproduce the error:
1) Insert a value into a text-input.
2) Submit the form.
3) Reopen the page with that form.
4) Change the value and leave the input-field. (onchange is fired) Go back to that field. Start typing the former value and select an item from the autocomplete-list.
5) Leave the input-field (onchange is *NOT* fired)

Possible workaround:
Put Javascript-code into onblur-handler.

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

The FF-autocomplete problem is a different bug, I'd say.
Related to this one, but not exactly the same bug.
nsFormFillController can't use the same SetValue method as what scripts use, 
that blocks the change event.

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

Fixes testcases for me and doesn't regress bug 313337.
As I said, FF-autocomplete problem is a different bug, IMO.
I could perhaps fix that too though, but after this one.