230445 - broadcast event is not fired after it had been fired once

Status: VERIFIED INVALID

(Core :: XUL, defect)

Description

[José Antonio Sánchez Sánchez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

In the page http://www.4clerks.com/testcase/xul/bugObserves.xul when a button is
clicked, a broadcast is fired (a button, a different broadcast). As you can see,
with mozilla1.5 and higher, the observes defined on the xbl widget only is fired
the first time. The correct performance is to view FIRST and SECOND as the
textbox value every time a button is clicked. 

The files are distributed this way:

http://www.4clerks.com/testcase/xul/bugObserves.xul
http://www.4clerks.com/testcase/xbl/bugObserves.xml
http://www.4clerks.com/testcase/css/bugObserves.css



Reproducible: Always

Steps to Reproduce:
1. Load the http://www.4clerks.com/testcase/xul/bugObserves.xul
2. Click the first button (FIRST must be the value of the textbox)
3. Click the Second button (SECOND must be the value of the textbox)
4. Click the first button again (The textbox value must change, but it doesn't)


Actual Results:  
2. Click the first button (FIRST must be the value of the textbox)
3. Click the Second button (SECOND must be the value of the textbox)
4. Click the first button again (The textbox value must change, but it doesn't)



Expected Results:  
Every time The attribute of broadcast is changed, the broadcast event must be
fired. 

It is important because, some applications may need this feature
to change som xbl widgets data. For example, two dependent trees. 
Selecting one of its, the second must show related information to the 
item selected at first.

Comment 1

[Brendan Eich [:brendan]]

Seems bad if true -- confirming to get someone's attention.

/be

Comment 2

[Boris Zbarsky [:bzbarsky]]

Does making the XBL into valid XML help, first of all (see JS console)?

Comment 3

[José Antonio Sánchez Sánchez]

Sorry about my code error. I wrote too fast ;). 
Unfortunately the problem persist. 

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, I see what the problem is.  You are essentially doing:

foo.setAttribute('SYNC', "x");
foo.setAttribute('SYNC', "x");

And the second time the attr change broadcaster is not triggered.  That's
because there is no change (setting the same attribute on the same node to the
same value).

I believe that this is correct.   If you were to try setting the attr to a
different value, or unsetting it and setting it, it should work.

Comment 5

[José Antonio Sánchez Sánchez]

You were right Boris, but why in lower versions of mozilla does it work? 
What about if you want to send a message every time a user perform an operation?
May you define a counter variable and change it every time you set the
broadcaster attribute?

For example, The applications finish a set of operations, and some components
must rebuild every time those operation are fineshed. 

I Think the broadcast event must be fired every time a broacast attribute is
set, making no difference between last and current value of the attribute. 

Maybe I am wrong. 

Thank you. 

Comment 6

[Mike Shaver (:shaver emeritus)]

I forget the bug number, but Vidur and I made a change a while back to suppress
notifications and style recalc and whatnot for attribute settings that didn't
change the value, which might be why older Mozillas did what you say you want.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> You were right Boris, but why in lower versions of mozilla does it work? 

Because those older mozillas had a bug -- they notified everyone on all
attribute set calls.  This meant they fired DOM mutation events on calls like
this one, which was just wrong.  That bug got fixed.

> What about if you want to send a message every time a user perform an
> operation?

Your suggestion with a counter would work fine.

> I Think the broadcast event must be fired every time a broacast attribute is
> set

The documentation on XULPlanet clearly says that the broadcast happens when the
attribute _changes_.  The XUL 1.0 spec doesn't seem to cover this.

Comment 8

[David Hyatt]

I'll add something to the spec (when I get to broadcasters/observers some day).  The current behavior 
is correct.  Since the attribute isn't changing, no broadcast should occur.

Comment 9

[José Antonio Sánchez Sánchez]

Ok. My excuses. I mark the bug as invalid. 
Thank you all. 

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 230878 has been marked as a duplicate of this bug. ***