Closed
Bug 334994
Opened 20 years ago
Closed 20 years ago
XBL 1.0.Firefox property.setter leads to loop exception
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: schools_ring, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
In continuation of Bug # 334654 and Bug # 334618 filed earlier I confirm that XBL implementation in Firefox has only rather far relation to the official outlines. It is rather a whole new system which I actually like so far (I'm doing universal binding/behavior pairs for Gecko/IE).
At the same time XBL 1.0.Firefox is in the same relations with the original XBL W3C proposal as a lion and an elephant (both mammals, and that's it). Thusly I see pointless to file a "bug" on each step. An elephant has a trunk and no hair, but these are not its "bugs" as compared with a tiger, these are its features :-) I promise though to update MDC providing samples for each substantial change.
Sorry for a long preface but I had (?) to explain why from the the posted testcase one can file 8 "bugs" while I see and care of only one: because it affects the *actual implementation*.
Reproducible: Always
Steps to Reproduce:
1. HTML file:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>XBL : Properties</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
font: 1em Verdana, sans-serif;
color: #000000;
background-color: #FFFFFF}
p {
-moz-binding: url(properties.xml#default)}
</style>
<script type="text/javascript">
function init() {
// to ensure timing-issues free results
// (for local tests at least):
setTimeout('demo()',1000);
}
function demo() {
var p = document.getElementById('p1');
alert(typeof p.foo); // undefined
alert(p.innerText); // OK
alert(p.innerText = 'noop'); // OK
// BUT:
try {
p.bar = 'foobar'; // leads to loop
}
catch(e) {
alert(e.message); // too much recursion
}
}
window.onload = init;
</script>
</head>
<body>
<p id="p1"><b>Sample<br>
text</b></p>
</body>
</html>
2. properties.xml binding:
<?xml version="1.0"?>
<!--
XBL 1.0.Firefox
Properties handling demo
-->
<bindings
xmlns="http://www.mozilla.org/xbl"
xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<binding id="default"><implementation>
<constructor><![CDATA[ // called on binding bound
// your code here
]]></constructor>
<destructor><![CDATA[ // called on binding unbound
// your code here
]]></destructor>
<!-- Real property: not implemented -->
<property name="foo">
10
</property>
<!-- Overloaded property: leads to deadloop in setter -->
<property name="bar">
<getter><![CDATA[
return this.bar;
]]></getter>
<setter><![CDATA[
this.bar = val;
]]></setter>
</property>
<!-- Virtual property: I love it -->
<property name="innerText">
<getter><![CDATA[
var st = this.innerHTML || '';
var re = /<\/?[^>]+>/gi;
return st.replace(re,'');
]]></getter>
<setter><![CDATA[
// Just a loop hole by default:
return val;
// A nasty variant if one likes (comment above, uncomment below):
// throw new Error('setting a property that has only a getter');
]]></setter>
</property>
</implementation>
</binding>
</bindings>
Actual Results:
On attempt to set p.bar property (with setter defined) setter calls itself to set the property. In the result it leads to the quick call stack overflow.
Expected Results:
Within the <setter> the code doesn't call itself to assign val to the property. It does it directly.
As a workaround one need to have an extra property to keep the value:
<property name="foo">
<getter>
return this.$foo;
</getter>
<setter>
this.$foo = val;
</setter>
</property>
It works but having doublicate properties is not really elegant.
|
||
Comment 1•20 years ago
|
||
I don't really see what the bug is here, if you try to set a property within it's setter then of course it's going to loop infinitely.
Assignee: nobody → general
Component: General → XBL
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
|
||
Comment 2•20 years ago
|
||
Yeah, this is invalid. You're setting "this.bar = val" as the setter for the "bar" property, so it recurses.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
(In reply to comment #2)
> Yeah, this is invalid. You're setting "this.bar = val" as the setter for the
> "bar" property, so it recurses.
Then I must be missing the right way. How do I suppose to set the relevant property within the setter?
Or you mean to say that having a *setter* defined implies that you cannot *set* the property itself, but only something else?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
|
|
||
Comment 4•20 years ago
|
||
A property is essentially just a pair of methods, it has no inherent value. If you need to keep a value somewhere you must declare a field to keep it in.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
(In reply to comment #4)
> A property is essentially just a pair of methods, it has no inherent value. If
> you need to keep a value somewhere you must declare a field to keep it in.
Aha... <http://developer.mozilla.org/en/docs/XBL:XBL_1.0_Reference:Elements#field>
I say "Bingo!" :-)
P.S. So you decided to go in XBL with the triple opposition of method/property/field a la C++? Nothing criminal of course, but far of obvious from the JavaScript point of view (and that's what's used for DOM property=~field access). You may want to bookmark this bug for future numerous quick answers :-)
Thanks again to everyone, especially to Dave Townsend.
You need to log in
before you can comment on or make changes to this bug.
Description
•