Closed Bug 304921 Opened 19 years ago Closed 19 years ago

setting a watch on a DOM node doesn't work

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: felipe, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

onpropertychange testcase
1.78 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

The code attached sets a watch for the "checked" property of an HTML input. The
watch never fires, though, despite clicking the checkbox.

Reproducible: Always




<html>
<body>
<script type='text/javascript'>
newInput = document.createElement('input');
newInput.type = 'checkbox';

newInput.watch('checked', function(prop, oldVal, newVal) {
	alert(oldVal+' -> '+newVal);
});

document.body.appendChild(newInput);

</script>
</body>
</html>
I can reproduce this using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b5) Gecko/20051015 Firefox/1.4.1
Didn't check for duplicates.
Assignee: nobody → general
URL: (HTML in additional info)
Component: General → DOM
Keywords: testcase
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
This is invalid, as far as I can see -- the property is not being assigned to (that is, the setter for the property is not running), so I wouldn't expect the watchpoint to trigger.

Brendan, please reopen if I'm incorrect.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
The reporter clearly hopes for some internal consistency where user checking of a checkbox sets the checked property.  That's not a bad hope, but it is not how the DOM works in general.  Anyone think we should try to move in that direction?

/be
I think that would be prohibitively expensive (for example it would require calling out into JS from all sorts of C++ DOM operations).  I'm also not sure how it would work in general -- when C++ code calls a C++ setter, we can't just call into JS, since that would just turn around and call the same setter.

Frankly, I don't think it's the right thing to do -- the basic model here is that the user checking the checkbox changes some state that affects what the "checked" getter returns, nothing else.
Bug 285272 also asks for something like this. Either watch to work or to support IE:s onpropertychange
(In reply to comment #4)
> I think that would be prohibitively expensive (for example it would require
> calling out into JS from all sorts of C++ DOM operations).  I'm also not sure
> how it would work in general -- when C++ code calls a C++ setter, we can't just
> call into JS, since that would just turn around and call the same setter.

We'd need a unified model.  Imagine everything were written in JS (or Smalltalk -- that's the progenitor).  People who want this to "just work" are thinking in a bootstrapped way that I wish I had implemented back in 1995.  It's late now to change how the DOM works, however.

Can someone specify how IE's onpropertychange event handler works?

/be
I think this would be neat to have, and we could implement it by in the internal C++ setters manually calling into the js-engine and telling it a property is changing to give it a chanse to call any watch functions (dunno if there is such a hook today).

However, I think this would be very hard to implement consistently. Stuff like .checked and .parent changing lives in entierly different places. And things like the computed-style object changing would be very expensive to implement.
(In reply to comment #6)
> Can someone specify how IE's onpropertychange event handler works?
> 

http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onpropertychange.asp

So the following checkbox would return "checked" if clicked:

newInput.onpropertychange = function()
{
	// What property changed
	alert(window.event.propertyName);

}

onPropertyChange is an event sent to elements, so it's not something that works for style objects or attribute nodes. It seems to work fairly spottily. The attached testcase shows that it works for .checked and .value on <input> and <select>.

However, it did not work for .selected on <option> and it does not work for any of the offsetXXX properties anywhere.


I'm very much against reusing .watch. We will never be able to do it in a consistent manner the DOM and even less for XPConnect objects in general. And onpropertychange seems like a bad idea too since it too will never be implemented for everything.

Instead I recommend that people use the normal events such as onchange, oninput and so on. We might need to implement a few more of those in case anything is missing. But a general mechanism requested in this bug seems like a bad idea.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: