685844 - element.setAttribute('onchange', 'second value') does not work completly

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[André Breier]

Attachment: teste.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

1. Create an input hidden element with onchange="return false".

2. On script, running while loads HTML, I setAttribute 'onchange' to 'verify(\'um\')'.
3. Sent the onchange() on the element().
4. I use a button onclick to setAttribute 'onchange' again, to 'verify(\'ec\')'.
5. Sent the onchange() on the element().
6. I use a button onclick to setAttribute 'onchange' again, to 'verify(\'et\')'.
7. Sent the onchange() on the element().


Actual results:

Following the steps as above:

3. the javascript function "verify" is called with the argument "um".
5. the javascript function "verify" is called with the argument "um" again.
7. the javascript function "verify" is called with the argument "um" again.

And so it goes, I can change the attribute onchange many times I wish, it will ever throw the first set.


Expected results:

Following the steps as above:

3. the javascript function "verify" is called with the argument "um" as it should be.
5. the javascript function "verify" is called with the argument "ec" now.
7. the javascript function "verify" is called with the argument "et" now.

Comment 1

[André Breier]

I have tested with firefox 3.6, 6.0.2, 7.0b4, 8.0a2 and SeaMonkey 2.0.4 without success. But firefox nightly 9.0a1 worked as any other browser.

I tested IE-9, Opera-11.50, Chrome-13 WITH SUCCESS on all of them!

Comment 2

[Boris Zbarsky [:bzbarsky]]

This was fixed by the patches in bug 659350.

I have no idea _why_; at first glance it should have worked before that too.  But in any case, it's fixed.

Comment 3

[André Breier]

I did not understand exatly how it's already fixed if it is not on the stable release.

When will this patch be part of the stable code?

Comment 4

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110908 Firefox/9.0a1

The patches were updated to the nightly channel (as per bug 659350), that means Firefox 9. 

I used the test case attached on Firefox 9 and it works as expected. You can download the nightly build from:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 5

[André Breier]

Vrigil Dicu,

As you might have read on my first comment:
 > ...But firefox nightly 9.0a1 worked as any other browser.

And on the last one:
 > When will this patch be part of the stable code?

Will I have to ask all my customers not to use firefox or use the extra-ultra-supper-not-even-alpha version of it?

Actually I cannot do it and I would really appreciate if my customers and I could continue on using firefox stable release...

Comment 6

[Virgil Dicu [:virgil] [QA]]

(In reply to André Breier from comment #5)
> Vrigil Dicu,
> 
> As you might have read on my first comment:
>  > ...But firefox nightly 9.0a1 worked as any other browser.
> >>True, sorry about that.
> And on the last one:
>  > When will this patch be part of the stable code?
> >>One Mozilla version will be released every 6 weeks. Firefox 6 was released in the 16th of August, Firefox 7 is planned for the end of September, so Firefox 9 should be released in December. 
> Will I have to ask all my customers not to use firefox or use the
> extra-ultra-supper-not-even-alpha version of it?
> 
> Actually I cannot do it and I would really appreciate if my customers and I
> could continue on using firefox stable release...

A developer might give you more relevant feedback on this issue. In the light of the rapid release process fixes usually arrive in the nightly channel, that is the least stable one.

Comment 7

[André Breier]

Thank you Virgil.

I have really appreciated your information.

Thanks again...

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is fixed.  Fixed means fixed in development builds, not necessarily stable release.