347537 - JS dispatched event not cached by onchange handler

Status: RESOLVED DUPLICATE of bug 190876

(Core :: DOM: Events, defect)

Description

[Maris Nartiss]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5

I wrote JS that on some event dispatches onchange event. This event should be catched by elements event handler, but it does not. Strangest thing - if I add alert('foo') before dispatching event, it GETS catched. Element, that needs to catch event already exists.

Same code works on Knoqueror 3.5, Opera 9 and MSIE 6.

I will attach testcase.

Reproducible: Always

Comment 1

[Maris Nartiss]

Attachment: Testcase for bug

Open test case, click on "enable" "disable". Both input fields shoud become active or inactive, but it doesn't happen in FF 1.5.0.5. 
Set "Enable alert workaround" to "Yes!" and try "enable"/"disable" then. Now both fields would become acitve/inactive as expected.

This testcase will not work in MSIE, but will work w/o bugs in Konqueror 3.5 and Opera 9.

PS. Don't ask why such lame code ;)

Comment 2

[Maris Nartiss]

Mozilla 1.7.12 seems not to be affected.


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2

Comment 3

[Martijn Wargers (dead)]

I'm not sure what I should do in the testcase. Could you maybe make a very simple testcase that shows what should be happening?

Comment 4

[Maris Nartiss]

Attachment: Testcase 2

I managed to shorten testcase.
Just follow instructions written in testcase to reproduce bug. 
In short: changing field's B value from disabled to enabled dispatches onchange event to field C, but it gets catched ony if specific workaround is enabled.

Affetcted browser: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5

Not affected browsers: 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060216 Debian/1.7.12-1.1ubuntu2
Konqueror 3.5.2
Opera 9.0.0 (Linux)

Comment 5

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

*** This bug has been marked as a duplicate of 190876 ***

Comment 6

[Maris Nartiss]

(In reply to comment #5)
> 
> *** This bug has been marked as a duplicate of 190876 ***
> 

Why? 
Bug #190876 says: "disabled form elements kill dom events", but in my test case You may notice, that I enable form element BEFORE dispatching an event to it.

To test it:
1) add <p id="debug"></p> to source;
2) add line "document.getElementById('debug').innerHTML = element.disabled;" to beginning of trigerEvent() function.

And You will see it - BEFORE dispatching event to select element it IS enabled, but bug still applys. (select element's disabled == false)

If You think, that it IS dupe of #190876 then #190876 needs an update to relfect possibility that bug #190876 also applys to enabled form elements.

PS. Sorry for reopening.

Comment 7

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

ok. Let's just add "depends on".
Though, I still think this is a dup. 
(I wonder whether showing the alert causes actually another 'change' event, 
because focus moves from select to alert box...)

Comment 8

[Maris Nartiss]

(In reply to comment #7)
> ok. Let's just add "depends on".
> Though, I still think this is a dup. 
> (I wonder whether showing the alert causes actually another 'change' event, 
> because focus moves from select to alert box...)
> 

I finaly figured out why alert() fixes problem.
Here's example:
for (i=0; i<1000000; i++) {
  if (i/10000 == Math.floor(i/10000)) foo.innerHTML +=".";
  if (i == 50000) alert('bar');
}
Normaly new foo content will be show only when for() loop finishes it's run. Adding an alert() will cause page update with current state of foo.

As I'm not an JS DOM guru, don't laught at me, but it looks like:
DOM node (select.disabled) value is changed; as script contibues to run, no update to DOM tree (or whatever it is) is done; as per bug#190876, disabled node  does not catch event. 
Puting an alert() before dispatching an event will cause DOM tree update, select get's back its event handler and catches an event.

So - sorry, You where right, it IS dupe of bug#190876. Only strange one ;)

*** This bug has been marked as a duplicate of 190876 ***