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.
Seems bad if true -- confirming to get someone's attention. /be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: broadcast event is not fired after it had been fired once → broadcast event is not fired after it had been fired once
Does making the XBL into valid XML help, first of all (see JS console)?
Sorry about my code error. I wrote too fast ;). Unfortunately the problem persist.
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.
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.
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.
> 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.
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.
Ok. My excuses. I mark the bug as invalid. Thank you all.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
*** Bug 230878 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.