180504 - xbl:inherits breaks when inherited attribute is removed

Status: RESOLVED INVALID

(Core :: XBL, defect)

Description

[Alex Vincent [:WeirdAl]]

When you have a default attribute in XBL, and XBL also directs the inheritance 
of that attribute through xbl:inherits, the Core DOM can make things 
interesting.

(1) Without the inherited attribute initially, XBL defaults to the attribute 
value defined in the XBL document.
(2) Using setAttribute in the XUL document (I haven't built an HTML testcase), 
the default attribute value in the XBL document is overridden by the XUL 
document's attribute, which it inherits (correctly).
(3) Using removeAttribute in the XUL document to remove the overriding 
attribute, the XBL document fails to revert to the default attribute.

Testcase coming up via three attachments.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: Testcase (part 1 of 3) -- XBL document

Comment 2

[Alex Vincent [:WeirdAl]]

Attachment: Testcase (part 2 of 3) -- CSS stylesheet for binding

Comment 3

[Alex Vincent [:WeirdAl]]

Attachment: Testcase (part 3 of 3) -- XUL document

Open this attachment to see the testcase, then follow the directions embedded
within.

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: Testcase (part 3 of 3) -- XUL document

ML stylesheet didn't apply -- trying with stylesheet PI in the right place.

Comment 5

[Alex Vincent [:WeirdAl]]

Attachment: Testcase as ZIP

Bugzilla doesn't like me today.  Sorry for all the spam.  This testcase is
localized, so you simply unzip all three files into the same directory.

Comment 6

[Alex Vincent [:WeirdAl]]

Attachment: Testcase (part 3 of 3) -- XUL document

Per bz's insistence, one more try (with & escaped).

Comment 7

[Alex Vincent [:WeirdAl]]

Attachment: Testcase (part 3 of 3) -- XUL document (final draft)

Argh.  Bugzilla doesn't like me because it doesn't like stupid mistakes.

Comment 8

[Alex Vincent [:WeirdAl]]

Comment on attachment 106516 [details]
Testcase (part 2 of 3) -- CSS stylesheet for binding

Last bit of stupid bugspam for a while.  Major apologies to all concerned.

Comment 9

[Alex Vincent [:WeirdAl]]

Sorry if I haven't been clear:  this bug forces, in the XUL document, a
violation of the DOM Level 1 Core specification under Element.removeAttribute. 
From that specification, the exact words are:

removeAttribute
    Removes an attribute by name. If the removed attribute is known to have a
default value, an attribute immediately appears containing the default value.

I believe Mozilla "knows" via XBL a default value for the context attribute in
the testcase, and that is my justification for this bug.  If I'm wrong, I'm wrong.

Comment 10

[jag (Peter Annema)]

Interesting XBL spec question. I know the spec right now says that any change to
an inherited attribute is reflected into the anonymous content/attribute we're
inheriting into, including removeAttribute. It kinda makes sense though to think
of this combo as default + override, where removing the override would take you
back to the "default" value:

<foo id="fooEl"/>

<binding id="foo">
  <content>
    <bar a="1" xbl:inherits="a"/>
    <children/>
  </content>
</binding

// begin with <bar a="1"/>
fooEl.setAttribute("a", "2"); // --> <bar a="2"/>
fooEl.removeAttribute("a"); // --> <bar a="1"/> (and not <bar/>)



As a side question, what does this do:

<foo id="fooEl"/>

<binding id="foo">
  <content a="1" xbl:inherits="a"> <!-- rather nonsensical -->
    <children/>
  </content>
</binding>

// begin with <foo id="fooEl" a="1"/>
fooEl.setAttribute("a", "2"); // --> infinite loop?

Should xbl:inherits be disallowed on <content/>? Is it currently ignored?

Comment 11

[David Hyatt]

The current behavior of XBL (the way it works now) is correct.  If you specify
an attribute along with xbl:inherits in the XBL template, it represents an
initial value only (a value that should be used if it isn't overridden by the
bound element).  It's an initial value and not a default value.

The concept of "default values" with XML and the DOM is something totally
different.  This is getting into XML schema territory, where it is the province
of the language itself (e.g., the XUL schema) to specify what the default values
for attributes are in XUL.

Comment 12

[Alex Vincent [:WeirdAl]]

invalid per hyatt's comment.  Thanks.