187550 - table with overlapping colspans suppress virtual columns

Status: RESOLVED DUPLICATE of bug 413286

(Core :: Layout: Tables, defect, P3)

Description

[Zdik Kudrle]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

The problem is reproducable vere easily (and that's what makes me not that happy
- this fetaure is kinda necessary :) :

<table border="1" width=300> 
<tr>                         
    <td colspan=2>z</td>     
    <td width=30>x</td>      
</tr>                        
<tr>                         
    <td width=30>z</td>      
    <td colspan=2>x</td>     
</tr>                        
                             
</table>                     
                   
          

Reproducible: Always

Steps to Reproduce:
See code in details.

Actual Results:  
+------+-------+
|z     |x      |
+------+-------+
|z     |x      |
+------+-------+

Expected Results:  
+------------+--+
|z           |x |
+--+---------+--+
|z |x           |
+--+------------+

Comment 1

[Frederic Bezies]

Seeing this bug - 5 hours old CVS based build - WinXP-Sp1.

Changing OS -> All.

Comment 2

[Ruslan Ismailov]

This description is not 100% clear, and Mozilla's behaviour is correct. As I see
actual results is slightly differs from you picture

+-------+-------+
|z      |x      |
+------+--------+
|z     |x       |
+------+--------+
       ^^
You see this small distance between borders? It is border of middle collumn,
wich have no data in it. By default empty columns width become 0. So to obtain
picture, you want to get, you should use colgroup tag.

Here is a correct example.

<table border="1" width=300> 
<colgroup><colgroup width="33%"><colgroup>
<tr>
    <td colspan=2>z</td>     
    <td width=30>x</td>      
</tr>                        
<tr>                         
    <td width=30>z</td>      
    <td colspan=2>x</td>     
</tr>                             
</table>      

Comment 3

[Boris Zbarsky [:bzbarsky]]

this is already filed (many times over)

Comment 4

[Bernd]

Attachment: testcase

the testcase shows that virtual columns which have no originating cells are
suppressed

Comment 5

[Ralf Hauser]

http://bugzilla.mozilla.org/show_bug.cgi?id=201632 is very similar, although
there it is not mixing "width" with "colspan", but producing a similar effect
with just colspans alone.

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 201632 has been marked as a duplicate of this bug. ***

Comment 7

[Bernd]

*** Bug 207848 has been marked as a duplicate of this bug. ***

Comment 8

[Matt Dale]

I've been directed here from http://bugzilla.mozilla.org/show_bug.cgi?id=207848

Reading other reports on similar lines, it appears this behaviour is 
considered "correct", despite the fact that just about every other major 
browser does it "the other way" (ie. they allocate the space for the column(s)).

Having downloaded 1.4 RC1 and tried that, the situation is the same, so I'm 
guessing there are no plans to alter the rendering system.

In that case I'd be interested what workarounds people have come up with as 
alternatives to using columns in this way.

Thanks.

Comment 9

[Bernd]

Matt if I would consider the behaviour correct, I would invalidate the bug

Comment 10

[Steven Grimm]

This behavior certainly wasn't what I was expecting, and it seems mathematically
suspect too:

<table>
  <tr>
    <td width="30%">z</td>
    <td colspan="2">x</td>
  </tr>
  <tr>
    <td colspan="2">z</td>
    <td width="30%">x</td>
  </tr>
</table>

In this case, for the column widths to add up to 100%, the virtual column needs
to be 40% of the table width.  IE and Opera and w3m all render it that way, but
not Mozilla.

Comment 11

[Bernd]

before anybody continues to waste time at this, this can be easily fixed by
backing out
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=BasicTableLayoutStrategy.cpp&branch=&root=/cvsroot&subdir=mozilla/layout/html/table/src&command=DIFF_FRAMESET&rev1=3.200&rev2=3.201

I think I will do this  as I can't verify what bug has been fixed and I contest
that r= alexsavulov is valid for this file.

Comment 12

[Alfonso Martinez]

*** Bug 226202 has been marked as a duplicate of this bug. ***

Comment 13

[Bernd]

Attachment: patch

Comment 14

[Bernd]

the patch that created the problem is from bug 101759

Comment 15

[Bernd]

Comment on attachment 136996 [details] [diff] [review]
patch

the patch does not pass the regression tests

Comment 16

[Bernd]

*** Bug 237895 has been marked as a duplicate of this bug. ***

Comment 17

[Bernd]

*** Bug 263859 has been marked as a duplicate of this bug. ***

Comment 18

[Erik Fabert]

*** Bug 265142 has been marked as a duplicate of this bug. ***

Comment 19

[Tony Tovar]

Is this bug responsible for the problem I keep seeing on slashdot.org,
theregister.co.uk, etc?  If I right-click the link to a story and open it in a
New Window, about 5% of the time I find that the text columns in the new window
are overlapping.  If I refresh, it fixes itself.  If this bug is unrelated, I'll
file a new bug...

Comment 20

[Phil Endecott]

Re comment #19 - Tony, that's not this bug.  This bug isn't cured by pressing
refresh.

Comment 21

[Kiernan Holland]

Is colgroup a standard HTML tag or is this something that 
was produced for the rendering engine.. 

I agree with Steven Grimm, it seems that the engine could derive the 
proper width from the given information.. 

How I would solve the problem is this.. 

Assume naturally that all columns are an equal percentage of the table width, 
and are changed if the content is larger. If a percentage is given for any 
column, refactor that in to the total width and adjust the width purportionately. 

Its a matter of precedence, and which width is greater.. 

The problem is everything is done by the book and yes even standards 
committees make mistakes.. There are two kinds of standards, de jour and de
facto.. de facto is like what Microsoft does (standard by use, not by
agreement), de jour is the kind supposedly that are well thought, but defacto 
tends to reign because its useable now.. If people are experiencing something
that doesn't seem intuitive like this, I would use this as a strong case to go
against the supposed "standard". I mean, really would you rather Microsoft come
up with it and soon their implementation becomes the standard, or would you
rather your implementation be the standard?

I think the way you guys use standards, its more just and excuse not to bother
to implement something that works.. Its lazy in the worse sense of the word that
people get degrees in computer science for. Lazy hacking is about better design, 
not about avoiding implementations. 

Comment 22

[Bernd]

It looks like Kiernan knows how to fix it, great one bug less on my list. Feel
free to ask me for a review once you have done it. I would like to see this bug
beeing fixed.

Comment 23

[Kiernan Holland]

(In reply to comment #22)
> It looks like Kiernan knows how to fix it, great one bug less on my list. Feel
> free to ask me for a review once you have done it. I would like to see this bug
> beeing fixed.

Well I guess I stepped on some toes with that last letter.. 

This is really complex stuff I guess.. I take the position that the code is well
written, because the browser seems together.. Sometimes when I come up with a
bug,  the coders discuss the standards, so I assume that its a choice sometimes,
whether to fix something. Tables are about displaying stuff, and that's and area
I consider easy, but if there is some complex ADT's, if the browser is broken up
into some wierd MVC configuration that seems to distribute complexity than
localize it, then I can understand how this could be a problem..  But I'm
assuming the code that controls the table is in an object called table, and 
that it handles its view, contents (model), and control.  And its just a matter
of arranging the logic of how it draw itself right?

So then why is this a problem? 

Comment 24

[Bernd]

The task is pretty easy: modify the attached patch so that it does not change
the rendering of 
https://bugzilla.mozilla.org/attachment.cgi?id=51518&action=view. The code can
be browsed at http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/ 
The layout strategy stuff is at
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/BasicTableLayoutStrategy.cpp
Small hint this task might become easier once bug 226637 gets reviewed and
checked in.

The problem is really that the people who give "valuable advice" by far exceeds
the amount of people who attach patches. Thats all, or why are there more than
400 bugs in the layout component? Do they all have patches and only wait to get
checked in? (http://bugzilla.mozilla.org/page.cgi?id=etiquette.html)
But I think I really explained you what needs to be done, so please fix it. And
no lame excuses (I am not a coder, blah blah....)

Comment 25

[Wayne Mery (:wsmwk)]

is there an obvious bug to dup this to?  (or is DUPME wrong?)

Comment 27

[Wayne Mery (:wsmwk)]

should testcase look like how it renders in IE, or does IE also do it wrong?

Comment 28

[Wayne Mery (:wsmwk)]

note from steve - Yes, it still happens in Firefox 2.0.0.1. Here's a demo with screen grabs of Firefox's rendering and Safari's (correct) rendering:
  http://www.midwinter.com/~koreth/firefox/column-overlap.html 

Comment 29

[Mark Manning]

Hey everyone! :-)  If you look at bug #451733 which I submitted, you'll see it is a duplicate of this bug.  However, I did come up with a work-around via HTML.  If you create a hidden line in HTML and break out the colspans so that you have enough cells equal to the number of cells there are across the table you can eliminate this problem.  This isn't a code answer (still trying to find the time to look at all of the code there is for producing tables - helping too many different people get back on their feet from the hurricane here in Houston) but it is an HTML answer.  To give a simple example:

If you have the problem above of having your table cells laid out like this:

<table>
 <tr>
  <td colspan=2>.</td>
  <td colspan=1>.</td>
  </tr>
 <tr>
  <td colspan=1>.</td>
  <td colspan=2>.</td>
  </tr>
 </table>

Then you just insert a hidden row into the table like so:

<table>
 <tr>
  <td height="0px">.</td>
  <td height="0px">.</td>
  <td height="0px">.</td>
  </tr>
 <tr>
  <td colspan=2>.</td>
  <td colspan=1>.</td>
  </tr>
 <tr>
  <td colspan=1>.</td>
  <td colspan=2>.</td>
  </tr>
 </table>

This should make everything show up correctly.  The "height='0px'" item might be placed into the "<tr>" line (I didn't try it).  But in any case - this will correct this problem via HTML, but not via C/C++.  My thoughts (so far) on how to fix this via C/C++ is to create a single dimensioned array.  Have Mozilla scan each row.  Cells with colspan's in them are divided up so an equal amount of space is allocated to each part of the cell.  (Default colspan = 1.)  This is then compared to what is already in the array based upon how many cells you have gone on that row.  (So 1st row = 3 cells, 2nd row = 5 cells.  1st row's cells are 50px, 200px, 60px.  2nd row's cells are 25px, 100px, 100px, 100px, 200px.  So when the cells are mapped you get: 
   50-200-60
   25-100-100-100-200

   25-25-200-60
   25-100-100-100-200

   25-25-200-60
   25-25-75-100-100-200

   25-25-75-125-60
   25-25-75-100-100-200

   25-25-75-100-25-60
   25-25-75-100-100-200

   25-25-75-100-25-60
   25-25-75-100-25-75-200

   25-25-75-100-25-60
   25-25-75-100-25-60-15-200

End Result:   25-25-75-100-25-60-15-200

The end result would allow for all combinations of the first two lines.  Subsequent lines would again be compared to the single dimensioned array and further adjustments would then be made.  The end result would be that a hidden row could be inserted into the top of the incoming HTML table which would have the appropriate number of cells in it so the rest of the table would correctly be displayed.  This isn't an end-all be-all solution since the colspans would then have to be adjusted to account for the smaller cells.  However, a simple tabulation to reach the original amount of the colspan could then be achieved.

(The above is going on the assumption that Mozilla converts the COLSPAN's information into it's associated WIDTH information (so like a COLSPAN=2 might equal a 50px WIDTH or maybe the user provides the WIDTH and the COLSPAN can be evenly divided into the width. [Or in the case of an odd COLSPAN - one or more of the individual cell sizes would be larger.  Ex: COLSPAN=3 so the cell widths would be 33, 33, 34 if the total width of the cell was 100px.])

In any event, this is what I have come up with so far.  By divying up the widths into smaller cells, Mozilla could then add up how many of these smaller cells it needs in order to create what the user originally asked for.  This would adjust the table and make everything line up properly.

Ok - so what do think?  Is the idea good/bad...what?  TIA!

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This was fixed in Firefox 3.

Comment 31

[Mark Manning]

That is incorrect.  I'm using Firefox 3 and it is still there.  Remember you asked me to upgrade to FF3 from FF2?  I did so.  The bug still exists.

Comment 32

[Phil Endecott]

Mark, I am seeing the correct behaviour with FF3.  Are you looking at this bug's testcase, or some other example of the problem?

Comment 33

[Mark Manning]

On the original problem from

Description From  Zdik Kudrle   2003-01-03 00:26:31 PST   (-) [reply]

I WAS getting the same output/problem as described.  I haven't downloaded the latest FF3 which was released yet.  Let me try that, retry the above example problem, and see if it still exists.  BRB.

Comment 34

[Mark Manning]

Wow!  It worked like it is supposed to work!  :-)  Got the latest version of FF3 installed and now it works!  Great!  :-)