370521 - TextArea not firing onchange event

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Simon Porter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070214 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070214 Firefox/2.0.0.2

In FireFox 2.0.0.2 release candidates RC2 and pre RC3 the onchange event no longer fires on a textarea.

Reproducible: Always

Steps to Reproduce:
1. Visit the attached URL
2. Type something into the textarea
3. Click off the textarea

Actual Results:  
Nothing alerts

Expected Results:  
The page should alert "test"

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Get an alert:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20061227 BonEcho/2.0.0.2pre

No alert:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20061228 BonEcho/2.0.0.2pre

Regression window:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-12-27+03%3A33&maxdate=2006-12-28+03%3A32&cvsroot=%2Fcvsroot

Perhaps bug 357684, CC'ing mats and bz.

Comment 2

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

Argh, I guess we need the same thing for textareas what was added for input elements in Bug 357684. Will test that now.

Comment 3

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

Attachment: for trunk

Comment 4

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

Attachment: for 1.8

These needs some testing.

Comment 5

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

Mats, if you have any good tests, could you try those

Comment 6

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

Attachment: a testcase

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 255244 [details] [diff] [review]
for trunk

sr=bzbarsky.  Does <select> need something like this too?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 255246 [details] [diff] [review]
for 1.8

sr=bzbarsky.

Comment 9

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

As far as I see <select> dispatches 'change' whenever something actually changes, not on 'blur'.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Tab to a combobox, use the up/down arrow keys to change the selection, then tab out.  That should fire onchange on blur.

Comment 11

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

(In reply to comment #10)
> Tab to a combobox, use the up/down arrow keys to change the selection, then tab
> out.  That should fire onchange on blur.
> 
Ah, when size=1. Seems to work even without a patch.

Comment 12

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

Attachment: testcase for <select>

Comment 13

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

http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLSelectElement.cpp#1852
http://lxr.mozilla.org/seamonkey/source/layout/forms/nsComboboxControlFrame.cpp#351

Comment 14

[Mats Palmgren (inactive)]

Comment on attachment 255244 [details] [diff] [review]
for trunk

r=mats

Comment 15

[Mats Palmgren (inactive)]

Comment on attachment 255246 [details] [diff] [review]
for 1.8

r=mats

Comment 16

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

Checked in to trunk

Comment 17

[Dan Sledz]

Forgive my possible bug spam, but how is this resolved without having been checked into the branch yet?

Comment 18

[Ryan VanderMeulen [:RyanVM]]

RESOLVED FIXED status applies to the bug's status on the trunk. fixed1.8.x keywords are applied when the patch is committed to the specific branch.

Comment 19

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

Attachment: mochitest

Comment 20

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

I think another option for branch is to back out bug 357684.
At least .0.2. would work like .0.1

Comment 21

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

Whoever verifies the bug for branch, note that the testcase from 
reporter is http://ld.livecache.net/F/5618588/Test.html, not the 
testcase I attached.

Comment 22

[Carsten Book [:Tomcat]]

(In reply to comment #21)
> Whoever verifies the bug for branch, note that the testcase from 
> reporter is http://ld.livecache.net/F/5618588/Test.html, not the 
> testcase I attached.
> 

Hi, thanks :)

verified for 1.8.1.2 using this testcase.

Build: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2) Gecko/2007021917 Firefox/2.0.0.2 Mnenhy/0.7.5.0 (RC5) also on Windows Vista Ultimate.

Comment 23

[Jay Patel [:jay]]

I also tested the backout of bug 357684 and the http://ld.livecache.net/F/5618588/Test.html passes with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

Leaving the verified1.8.1.2 keyword in place, since we know this works with Firefox 2.0.0.2 rc5, but we need to make sure we address this issue again.

If we decide to take the fix in bug 357684 in the future, we will also have to take the patch in this bug and verify that all test cases work.

Comment 24

[Daniel Veditz [:dveditz] back January 5, 2026]

Comment on attachment 255246 [details] [diff] [review]
for 1.8

Moving nomination so we don't miss it.

Comment 25

[Lei Sun]

Hi Guys,

Though this is fixed on windows platform, it doesn't seems to be working on ubuntu.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)

Thanks

Comment 26

[Daniel Veditz [:dveditz] back January 5, 2026]

Comment on attachment 255246 [details] [diff] [review]
for 1.8

approved for 1.8.1.4, a=dveditz for release-drivers

Comment 27

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

(In reply to comment #26)
> (From update of attachment 255246 [details] [diff] [review])
> approved for 1.8.1.4, a=dveditz for release-drivers
> 
This patch was a regression fix for bug 357684, but that was
backed out from branch.

Comment 28

[Boris Zbarsky [:bzbarsky]]

The question is whether we want to reland it....

Comment 29

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

Marking blocking1.8.1.4? for now.
Bug 357684 has blocking1.8.1.4-

Comment 30

[Daniel Veditz [:dveditz] back January 5, 2026]

Comment on attachment 255246 [details] [diff] [review]
for 1.8

clearing patch branch approval while we straighten out the issues with the regressing bug.

Comment 31

[Daniel Veditz [:dveditz] back January 5, 2026]

Clearing blocking flag. If we do end up taking bug 357684 on the branch we'll want to approve a regression-fixing patch in that bug.