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

RESOLVED FIXED

Status

()

Core
XBL
RESOLVED FIXED
16 years ago
7 years ago

People

(Reporter: Jason Davis, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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]
(Reporter)

Comment 2

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

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 3

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

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 4

16 years ago
*** Bug 107974 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
still happens in 0.9.5 as well.

Updated

16 years ago
Target Milestone: mozilla1.0.1 → mozilla0.9.8

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 6

14 years ago
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

Comment 7

13 years ago
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

Comment 8

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

Comment 9

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

Comment 10

11 years ago
Created attachment 220684 [details]
Shows a workaround by using bindings on table element itself

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.

Comment 11

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

Comment 12

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

Comment 14

11 years ago
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...
Created attachment 223729 [details]
Simple HTML+XBL testcase

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.
Huh.  So the branch range (somewhat expanded) looks like:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-16+00&maxdate=2006-05-16+18&cvsroot=%2Fcvsroot

The trunk range I'm getting here looks like:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-08+02&maxdate=2006-03-09+10&cvsroot=%2Fcvsroot

Can someone confirm?

The problem is that I don't see checkins in common, or checkins that should affect XBL....
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

Comment 23

11 years ago
*** Bug 363608 has been marked as a duplicate of this bug. ***
Fixed by checkin for bug 243159.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Created attachment 250530 [details]
Simple HTML+XBL testcase v2

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

Updated

7 years ago
Duplicate of this bug: 291841
You need to log in before you can comment on or make changes to this bug.