270393 - Broken binding makes content randomly not show up

Status: NEW

(Core :: Layout, defect)

Description

[Fred Le Guern]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0

The URL given above should show a table with 2 visible columns out of 4 columns
total. The last two columns are styled to visibility=collapse and should not be
visible.

The page sometimes displays properly, but sometimes the collapsed columns show
up partially (only a few rows at bottom of table show content, the header only
shows background-color with no content).

This is a PHP-generated page. When trying it with a 'static' page (php page
saved as static html then put back on server) the bug is harder to reproduce
(though it happens maybe one reload out of 20) : see
http://www.taovillage.fr/playground/bug_visi_collapse.html

Reproducible: Always
Steps to Reproduce:
1. open url in browser
2. hit reload and see how the last 2 columns show up or not

Comment 1

[Bernd]

I have seen this once and can not reproduce it we need something more reproducible.

Comment 2

[Fred Le Guern]

I can reproduce the behaviour both on firefox and mozilla 1.7.3 on at least two
systems (didn't try more) under windows and linux. As it's much harder (almost
impossible) to reproduce from a local file I suspect a thread concurrency timing
issue or something like that.

Both systems are connected to the Internet through a DSL line with a 1.5Mbits/s
throughput. As far as file sizes are concerned there might be something about
http chunking and inherent delays (this is mere assumption). I'll try with
different connexions and report whether I can always reproduce the behaviour.

I have other strange behaviours that seem to be timing-related so it might be a
more general problem, but those are harder to reproduce. Take a look at
http://www.taovillage.fr/playground/bug_infopopup.php if you like, maybe you'll
observe something. On my system it seems to load the whole table but generally
displays only 4 rows.

I'll do my best to make all this observable for sure.

Anything else I can do ?
Sorry I can't help at all with browser code, I never delved into it.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Fred, can you make it happen reproducibly if the PHP sends the data on the wire
one line at a time or something, with 1-second sleeps in between?  That is, if
the data comes in a whole bunch of separate network packets?

Comment 4

[Fred Le Guern]

This page should (?) show a fairly reproducible behavior :

    http://www.taovillage.fr/playground/table_timing.php

What happens is that there is a binding on <tr> elements :

    tr {
        -moz-binding: url(showdetails.xml#showdetails);
    }

but the file showdetails.xml doesn't exist within that directory.
As soon as firefox tries to load the file it stops rendering the table.
No other styling on this page ; cutting the binding out makes it render
properly.

I added a 20ms sleep after each <tr>, adding more doesn't seem to
bring any profit but if you need it try :

    http://www.taovillage.fr/playground/table_timing_1s.php

Adding even the smallest sleep (10 microsecs) makes the timing
utterly different ; the browser shows 14 rows everytime.

Hope this helps...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimalish testcase

Comment 6

[Boris Zbarsky [:bzbarsky]]

So the problem here is that when a GetBinding() call fails in frame construction
we simply bail out of ConstructFrameInternal instead of constructing a frame.

In this case, I suspect that either LoadBindingDocumentInfo or
GetPrototypeBinding fails in nsXBLService::GetBindingInternal, so we end up
returning an error.

Is this desirable?  Should we render content "normally" if the binding load
fails, perhaps?  And maybe log an error to the error console if the binding
could not be found?

Comment 7

[[e-mail]]

Sounds good to me.

Comment 8

[Fred Le Guern]

Sustained, thanks

Comment 9

[Boris Zbarsky [:bzbarsky]]

So the question is, do we cover up all possible GetBinding errors in the frame
constructor, or do we fix XBL to return NS_OK in those cases (with a possible
warning)?

Comment 10

[Douglas Ross]

It seems the visibility collapse property causes the layout to ignore style 
applied to the col element unless the layout forces scrolling. Otherwise, 
resizing the window will cause the layout to apply the collapse visibility 
style. I have not tried this with colgroup, row, or rowgroup.

Steps to reproduce using sample code below:
1) Open Firefox (1.0.2).
2) Size window large.
3) Open file (with sample code in it).
4) Observe columns 1 and 3 are silver per style rules applied to the col 
element and columns 2 and 4 are plain ignoring style rules applied to the col 
element (they are collapsed).
5) Resize the window.
6) Observe columns 2 and 4 disappear.
7) Resize window smaller than layout height.
8) Reload file.
9) Observe layout displays per style rules applied to all the col elements.

Sample Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<STYLE>
<!--
col#col1, col#col3{
	background-color: yellow;
	visibility: collapse;
}
col#col0, col#col2{
	background-color: silver;
}
-->
</STYLE>
</HEAD>
<BODY>
<p>Resize the window to see Column 2 and 4 disappear.</p>
	<table>
		<col id="col0">
		<col id="col1">
		<col id="col2">
		<col id="col3">
		<thead>
			<tr><th>Column 1</th>
				<th>Column 2</th>
				<th>Column 3</th>
				<th>Column 4</th>
			</tr>
		</thead>
		<tbody>
			<tr><td>Column 1</td><td>Column 2</td><td>Column 
3</td><td>Column 4</td></tr>
		</tbody>
	</table>

</BODY>
</HTML>

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 1) Open Firefox (1.0.2).

Douglas, that uses a Gecko from April 2004 (about a year ago).  Please test
layout issues with a current trunk build (based on Gecko 1.8b1 or later) before
commenting on the bugs... In particular, the problem you describe is not
reproducible with a current build.

Quite apart from that, the testcase you have isn't really related to this bug,
which isn't really about visibility:collapse (as the "Minimalish testcase"
demonstrates).

Comment 12

[Bernd]

Boris, I have two questions
1. this bug seems pretty real, you wrote a testcase why you did not confirm it?
Or is it unclear that it is a bug at all?
2. Why is this a table bug your description seems to indicate that is a rather
generic problem. I am not arguing to send this to /dev/null AKA XBL, but would
rather like to cut that error propagation in table frame construction if this is
the problem.

Comment 13

[Boris Zbarsky [:bzbarsky]]

I just forgot to reassign....

Comment 14

[Douglas Ross]

Boris, the Firefox About screen shows Gecko at 20050317: Mozilla/5.0 (Windows; 
U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2. 

I'm not sure how to coordinate Gecko versions per Firefox About screen with 
Bugzilla version dropdown. Now that I look at it, I presume rv:1.7.6 
corresponds to Bugzilla version 1.7 Branch, but I'm not sure. 

Also, the original description was misleading. Thank you for changing it. 

In the future, I will avoid commenting on Trunk versions. Any additional 
pointers would be appreciated.

Sorry for the confusion. Thanks for clarifying.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> I'm not sure how to coordinate Gecko versions per Firefox About screen with 
> Bugzilla version dropdown.

The "rv" part is the Gecko version.  So yes, that's using Gecko 1.7.6, from the
1.7 branch.

Nothing wrong with commenting on trunk bugs; just worth using a trunk version
when you do.  ;)

Comment 16

[Ioana (away)]

Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0 (20140113030203)

Reproducible with the testcase from comment 10. All I had to do was open the html in Firefox - columns 2 and 4 were not there from the beginning. This works fine in Chrome 31.