Closed Bug 83830 Opened 23 years ago Closed 18 years ago

Binding TD cells (with XBL) doesn't work, at all

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jasonkarldavis, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [Hixie-P4] [xbl1.0])

Attachments

(2 files, 1 obsolete file)

Shows a workaround by using bindings on table element itself
1.21 KB, application/octet-stream
Details
Simple HTML+XBL testcase v2
30.00 KB, application/x-tar
Details 
As the summary says, if you try binding a TD cell using XBL, nothing appears to
happpen. (I tested binding events, I'm sure about anonymous content though).

Look at the link associated with this bug, I have a page with a table, and a
link beneath it. Clicking on the link, an alert pops up saying "#text". Click on
the table cell, nothing happens. But they both have the exact same binding.

I've tested this on all the Mozilla builds I have, including Mozilla 0.81 and
Mozilla 0.9 build 2001050515.
Jason, could you also test a recent nightly?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [Hixie-P4] [xbl1.0]
As I am cursed with a  dial up connection, I had one of my friends with 
broadband access download the nightly, with the user agent:
Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9+) Gecko/20010602

The same thing happens, the binding on the link works flawlessly, 
alerting "#text", but when he clicks on the TD cell, absolutely nothing happens.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Testing the latest build of Mozilla 0.91, still nothing.
I also decided to test the ability of other table elements to be bound, and as 
it turns out, not only TD fails, but so does TH, TR, TBODY, TFOOT, THEAD, as 
well as TABLE.
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 107974 has been marked as a duplicate of this bug. ***
still happens in 0.9.5 as well.
Target Milestone: mozilla1.0.1 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.2
still happening ... 

Seems like this is not directly related to the TD html tag but to something more
deeply in the system? 

I tried the following

<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>table XBL</title>
		<style type="text/css">
			.xbl {
				-moz-binding: url('table.xbl#test'); 
			}
			block { display: block }
			row { display: block; }
			cell { display: table-cell; }
		</style>
	</head>
	<body>
		<bock>
			<row>
				<cell class="xbl">cell data</cell>
				<cell class="xbl">cell data</cell>
			</row>
			<row>
				<cell class="xbl">cell data</cell>
				<cell class="xbl">cell data</cell>
			</row>
		</bock>
	</body>
</html>

up to this point the xbl gets bound to the CELL elements.
When I change the ROW styling to display:table-row then the CELLs no longer get
the XBL attached

this is with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030615
Just dropping in, I spotted the same problem on my system
[Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108
Firefox/1.0]
yet I can bind a TABLE (but not a TD or a TR).

Here's a test page : http://www.taovillage.fr/playground/td_moz_binding.xhtml
Confirmed for Firefox 1.5.0.2

I say this bug is MAJOR. It obviously renders XBL useless for 50% or more of Web projects (all table layouts and most importantly all real data tables).


Inline test sample:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Hello world!</title>
<style type="text/css">
p {
 background-color: yellow;
 -moz-binding: url(content.xml#default);
}

td {
 background-color: yellow;
 -moz-binding: url(content.xml#default);
}
</style>
</head>
<body>
<p>Default content</p>
<table>
<tbody>
  <tr>
    <td>pos</td>
    <td>pending</td>
    <td>foo</td>
  </tr>
</tbody>
</table>
</body>
</html>


// content.xml
<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl"
 xmlns:html="http://www.w3.org/1999/xhtml">
  <binding id="default">
    <content><html:b>Hello world! </html:b><children/></content>
  </binding>
</bindings>

Actual results: the very same behavior attached Ok to <p> but silently ignored by <td>.

P.S. Drove me unsane before I searched for this bug.

After further investigation: 

class assignment for TD is ignored too. 
.foobar {
 background-color: yellow;
 -moz-binding: url(content.xml#default);
}
...
<td class="foobar">...</td>

In the above case binding is still silently ignored.


The only workaround is to add an inline block to cell:

span {
 -moz-binding: url(content.xml#default);
}
...
<td><span>Now it works</span></td>


I may appear very wrong, but it looks very much as an intentional block, not a bug. Someone was thinking of 1000...10000 cells tables, memory usage etc. and just took the regular "Solomon decision" here: no feature - no problems.
From all <table> elements one currently can attach bindings only to the table object itself. Something is better than nothing and allows to overpass the bug by coding in <constructor> section. Evidently semi-defeats the purpose of bindings, but see above about something and nothing.
I would also consider this a MAJOR bug, particularly in light of the recent emphasis on AJAX and dynamically rendered HTML.
Assignee: hyatt → general
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → ian
I am attempting to create XBL bindings to implement the Web Forms 2.0 Repetition Model. I have been using one of the examples in the spec to test my bindings. The example uses table rows as the repetition blocks, and so I tried to apply my bindings to these rows but there was no effect. When I tried using DIVs instead, everything worked as expected.

I too agree that this is a major bug.
We probably need to either nuke TableProcessChild or make it do XBL resolution on the kid.
Keywords: helpwanted
OS: Windows 98 → All
Hardware: PC → All
Target Milestone: mozilla1.2alpha → ---
hmmm, TableProcessChild the unloved stepchild.... bug 243159 has a lengthy entry why we have this function and it waits for you (Boris) to decide how to proceed.
Yeah.  I need to find time to think about it; it'll be after I get home on Monday.  ;)
I ran into this problem when working on some code, and managed to find a workaround...

Use the CSS -moz-binding as normal, then "activate" it by detaching and reattaching the bound node after the page has loaded.

For example:

var TD = (some TD node with a binding on it);
var parent = TD.parentNode;
parent.replaceChild(TD, TD);

IIRC, I first stumbled across this by calling removeChild() & appendChild(), but a single replaceChild() is convenient and efficient. This seems to work fine in FF1.5. The main downside for me is that you don't get to see the XBL's effect until after the page loads and the onload event triggers the "activation" code.


Unfortunately, the big bummer is that this trick doesn't seem to work in Bon Echo Alpha 3. I'm not sure if there's another workaround, or if something changed such that now it really is impossible to bind XBL to table elements... If the root problem can't be fixed, I wonder if reenabling this workaround might be possible?

Would it be helpful if I tested with past branch builds to figure out when this stopped working?
Yes, that would be very useful.  Behavior here should really not have changed on branch...
Attached file Simple HTML+XBL testcase (obsolete) — 
Ok... My workaround is OK in the 2006-05-16-04 linux build, but fails in the 2006-05-16-12 build. I'm attaching the testcase I used.

I also made a surprising discovery... Sometime between alpha1 and alpha2, the CSS binding started working as expected (no workaround needed)! It continued working until whatever happened on May 16th broke things again, completely.
Justin, please file a separate bug for the regression and cc me?  That should block 1.8, imo.
Bug 339719 filed for the regression.
Frankly, we've had this for about forever.  We might as well fix things the right way by rearchitecting per my proposal in bug 243159 instead of duplicating yet more code between the frame construction codepaths.
Depends on: 243159
*** Bug 363608 has been marked as a duplicate of this bug. ***
Fixed by checkin for bug 243159.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Woohoo! Glad to see this fixed.

I've attached an updated testcase, which confirms that this is now working.
Attachment #223729 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: