broadcast event is not fired after it had been fired once

VERIFIED INVALID

Status

()

--
major
VERIFIED INVALID
15 years ago
11 years ago

People

(Reporter: jantonio122, Assigned: hyatt)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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)?
(Reporter)

Comment 3

15 years ago
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.
(Reporter)

Comment 5

15 years ago
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.
(Assignee)

Comment 8

15 years ago
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.
(Reporter)

Comment 9

15 years ago
Ok. My excuses. I mark the bug as invalid. 
Thank you all. 
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID

Updated

15 years ago
Status: RESOLVED → VERIFIED
*** Bug 230878 has been marked as a duplicate of this bug. ***

Updated

11 years ago
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.