Closed Bug 97506 Opened 22 years ago Closed 15 years ago

toggling btwn display: none and display: table-row inserts whitespace

Categories

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

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: basil, Assigned: bzbarsky)

References

Details

(Keywords: css2, testcase, Whiteboard: [awd:tbl][p3])

Attachments

(10 files)

display: table-row; this one breaks.
1.08 KB, text/html
Details
display: block: this one is correct
1.07 KB, text/html
Details
Testcase contrasting display: table-row and display: block
2.09 KB, text/html
Details
Test case using tables
2.68 KB, text/html
Details
Creation of extra whitespace with no table-row involved
514 bytes, text/html
Details
<tr> bug - with more than one cell per row it behaves a little different
530 bytes, text/html
Details
General table rendering example: problem when toggling <tr>'s
970 bytes, text/html
Details
extra space when tr's set to display:none
2.39 KB, text/html
Details
switch display of two tbody between none and block/table-row
1.30 KB, text/html
Details
DOM node removal and replacement has a similar effect
703 bytes, text/html
Details 
In a div tag, toggling between display: none and display: table-row inserts
whitespace if the div tag is not properly nested in a table. If the value is
changed to block, it displays correctly, and if the div is properly nested in a
table, it displays correctly. Admittedly, table-row is an invalid value here,
but it still displays, even with a strict dtd doctype tag.

Steps to reproduce:
1. Toggle the first div several times.

Actual behavior: Whitespace is inserted.
Expected behavior: ??? Not sure. Should an invalid value simply fail silently?
Should it display anyway? In any case, it should /not/ insert whitespace.

I will attach 2 testcases. I am seeing this on a Win32 build, ID 2001082820. I
am told that it has also been seen with an 8/21 Win32 build (NT/2k?).

    
    

    
  


  

    
    

    
  
Confirming and over to layout.
Assignee: jst → karnaze
Status: UNCONFIRMED → NEW
Component: DOM Style → Layout
Ever confirmed: true
QA Contact: ian → petersen

    
    

    
  
table-row is not invalid. Does it work without JS, or is the DOM maniuplation
required to make the test break?

    
    

    
  
No, it won't work w/o JS. At least, not my test case, since I'm using JS to do
the toggling. And it is specifically the toggling, ie, switching between the two
display values, that is inserting the whitespace. (IOW, if I turn off JS, the
test cases are pretty boring. :-) My sense was that the DOM manipulation was the
issue, but I'm certainly a newbie to DOM, etc.

    
    

    
  
Just FYI, IE 6 chokes on the first attachment on line 18, and the script
debugger indicates that the table-row value for style.display is not valid:
"Error: Could not get the display property. Invalid argument."


    
    

    
  
IE6 does not support table-row at all.

Do you see the whitespace if you just do:

<div style="display:table-row"> in a static document when the div is not in a
table?

I bet we put a table around the div when it becomes a table row and you're
seeing the table's margins....

    
    

    
  
I believe Boris Zbarsky is on to something here. When you specify display:
table-row, whitespace is indeed added even when not in a table. See the attached
testcase and compare the appearance of the items using table-row and using
block. Mozilla is probably constructing a table and then rendering the items in
it. Is this expected behavior? Or should it show the same as display: block?

    
    

    
  
> Is this expected behavior?

Yes.  See http://www.w3.org/TR/REC-CSS2/tables.html#anonymous-boxes

The bug would be that the anonymous table objects are not being destroyed, it
seems....

Also note "HTML user agents are not required to create anonymous objects
according to the above rules."  I'm not sure what that means.  Presumably the
idea is that an HTML document that does not have a table around a table row is
malformed to start with....

    
    

    
  

      
      
      
      

        Attached file
          
        Test case using tables
        — 
      

    


  

    
    

    
  
The latest testcase shows that if you use tables it works correctly. It looks
like this is because it doesn't need to create the anonymous table box. The
second example in the test case (using a div with display: block in a TD in a
TR) seems to behave identically in IE and Mozilla.

    
    

    
  
Bug 101518 is about the freeze caused when using the third test (block on a tr)
in the latest testcase using tables.

    
    

    
  


  
Shows that toggling between display none and display block creates whitespace

    
    

    
  
I've created attachment 57009 [details] which shows that toggling
between display:none and display:block can create whitespace
even with no table-row involved.
I guess that the problem is that the switch to display:none
doesn't remove the block entirely. 
 

    
    

    
  
That testcase is using display:block for a table row.  I'm not at all surprised
it leads to bogus behavior.  You should be using display:table-row

    
  
Status: NEW → ASSIGNED
Keywords: css2
Target Milestone: --- → mozilla1.0

    
    

    
  
I see. Didn't know that. Yes, with table-row Mozilla is fine.

Problem is that IE (5.5) behaves perfectly in my example, and
barfs if I use table-row. Oh well, the joys of scripting for 
different browsers are endless.

    
    

    
  
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

    
    

    
  
this does not appear to be table row specific (thanks to the 11/08/01 testcase) 
but that isnt a guranteed thing.  needs more investigation. (great testcases!)
Whiteboard: [awd:tbl][p3]

    
  
Priority: -- → P4
Target Milestone: mozilla1.0.1 → Future

    
    

    
  
WorksForMe using FizzillaCFM/2002071208.

    
  
Depends on: 162063

    
    

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

    
    

    
  
the original bug here is WFM, but dupe bug 171590 (which is the same as the last
testcase here) still exists

    
    

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

    
    

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

    
    

    
  
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
Component: Layout → Layout: Tables
QA Contact: petersen → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future

    
    

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

    
    

    
  
-> P3:Future
Priority: P4 → P3

    
    

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

    
    

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

    
    

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

    
    

    
  
Attachment #50713 [details] from comment #8 works properly for me.  No matter how many
times I click either "Mozilla", the page layout remains correct.  The rest of
the test cases still display the incorrect behavior.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030802 Mozilla
Firebird/0.6.1

    
    

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

    
    

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

    
    

    
  
Testcase (id=133496) should also work with inline or block not only with
table-row or at least Mozilla should not have such a behaviour - at least it
should generate a js error.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
I am not sure if my situation is the same or not.  What I have a is a table
inside another table. Both table has width set to 100%.  When using javascript
to toggle the inner table, the inner table would hide when its display property
is set to none (expected), however, when toggle back with display set to either
block or inline, the table's width no longer 100% (maybe 30%).  So, I did this
and it works, but I am not sure this is standard or not (it works with both
latest Mozilla and IE): set the display to "" (empty string).  The reason I did
this was that I want to see what the orginal style.display was, and it was
empty, so I did this and it works!  In summary, I think this is a bug, but
there's a work around.

    
  
Keywords: testcase

    
    

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

    
    

    
  
just a short reference what MS recommends in this case:
http://msdn.microsoft.com/workshop/author/tables/tables_overview.asp#display

<SCRIPT>
function getPets() {
    tblChoice1.style.display="none";
    tblChoice2.style.display="";
    tblChoice3.style.display="none";
}
</SCRIPT>

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
This bug keeps cropping up again and again, but it hasn't been fixed in over 3
years. I posted another bug report, and it was closed with a reference to this.
I just read 3 years worth of comments, and I'm kind of surprised/appalled that
this bug hasn't been fixed yet, considering the nature of the opensource
community. There are some 25 "duplicates" of this bug report, so the problem
seems fairly well defined:

"Swapping between either display:none and display:block OR display:table-row do
not work when the element is a TR (table row). Extra block space is left behind
that should not be. In addition, in table rows with multiple columns, swapping
between inline and none causes glitchy table rendering."

Both options, block or table-row, should work, regardless of personal
preferences to use display:table-row for table rows or not (display:table-row,
as defined in CSS2, is actually not explicitly meant for use with table rows, or
as the only option for use with table rows. Its actually defined to allow
non-html markup tags (i.e. XML) to be treated as if they were table rows in a
table structure.) In HTML, using display:block or display:table-row on a TR
should behave the same, to maintain compatability with other browsers (not just
IE, but Opera and Mac browsers as well). 

Its a well-defined problem, and one would think that the solution would be
fairly easy to solve with all the available evidence to whats happening. Is the
issue just that no one is willing to take the time to find and fix the culprit
code? I don't know about others, but I regularly toggle TR display using
display:none and display:block in my sites. Things have gotten easier to write
cross-browser compatible code with the DOM, lately. Its frusterating not being
able to do it now with Firefox, especially after seeing how long this bug has
been open (and NEW!). 

If someone could direct me to the right files, I'd be glad to take a look at the
code and see if I can poke a patch out of it. I like Firefox, but the more I
write DOM-compliant Javascript code, the more little buts I find with it that
just make life as a web developer frusterating. 

    
    

    
  
if you would read the bug you would find that toggling between display:'none'
and display:'' works cross browser and is endorsed by MS

    
    

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

    
    

    
  
(In reply to comment #56)
> if you would read the bug you would find that toggling between display:'none'
> and display:'' works cross browser and is endorsed by MS

I did read the bug, and implemented toggling between 'none' and ''. That still
doesn't change the fact that this bug has been around for 3 years, and neither
'block' nor 'table-row' work properly. I would still like to see the bug fixed,
and I am glad to fix it myself if someone would direct me to the right code.
There are some few hundred thousand lines of code in FireFox, and I'm having a
hard time finding the code myself.

    
    

    
  
Oh the code is fairly concentrated at
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/ and
http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSFrameConstructor.cpp

I believe one should as a first step lift the patch at bug 148810. But be warned
table pseudo frames creation is not for the weak hearted its probably just the
opposite. But I will be happy to answer your questions by email as they arise
(they will, I know).

    
    

    
  
I'll take a look. Thanks for the LXR links. I'm sure you'll hear from me
eventually, but GUI code is one of my specialties. I'm always writing custom
controls, so I think I should at least have some luck with this. I can't say
when I'll figure it all out, but I'm going to give it a try.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
*** Bug 297658 has been marked as a duplicate of this bug. ***
Blocks: 272370

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  


  
This example toggles between display="none" and display="".  The table columns shift after hiding.  The other display options ("block" or "table-row") work no better.  
It breaks the same way in Windows and Linux versions of Firefox but works okay in IE and Konqueror.
This problem hobbles many kinds of dynamic forms.

    
    

    
  


  
here's another example of similiar behavior - although the problem occurs whether the tr's are set to display:'', display:'block', or display:'table-row'.

    
    

    
  
After 5 years the bug's still bugging. Maybe the submitted test cases didn't show the problem in a general way understandable to the developers. I take a new shot, but first let me state some concerns:

1. The main problem seems not to be in core, but in Firefox.
2. A secondary problem could be in core since it also occurs in Netscape.

I stumbled across the bug when displaying and hiding <tbody>. My test case has two TBodys with toggling displays. I added a selection for display values of "block" and "table-row", since previous discussion stated using table-row as a solution to the bug.

Results:

for Netscape 8.1: perfect using block or table-row, small whitespace (x and y) when switching between the two

for Firefox 1.5.0.4: large whitespace using block (or inline for that matter), small whitespace using table-row

for IE (FYI only): perfect using block, error using table-row

Interesting enough the whitespace is only added when toggling back, but not when toggling forth.

Also IE keeps the 100% width, Mozilla doesn't, but thats probably a different bug.

    
    

    
  
Since there was no Firefox in existence in 2001, the bug was reported in a Mozilla build. Using Netscape in testing presumably has its uses, but proving that a bug isn't in the core is surely not one. For that, use a recent Mozilla build. Netscape probably alters Mozilla code downstream.

    
    

    
  
Using "" as value instead of "block", "inline" or "table-row" solves all the problems in all browsers, as suggested somewhere above. I just don't remember the value of "" from any specs.

    
    

    
  
(In reply to comment #82)

What made you think the correct display value for tbody is table-row? A tbody is quite obviously not the same as a tr, it is a collection of table rows and thus has its own display type, namely table-row-group. Your testcase works fine if use that value.

    
    

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

    
    

    
  
Here is an example of this symptom using CSS:
----------------------------------------------------------------------
<!doctype html public '-//W3C//DTD HTML 4.01//EN' 'http://www.w3.org/TR/html4/strict.dtd'>
<html>
<head>
<title> Nested Table / Display Bug </title>

<style type='text/css'>
  .hidden {
    display : none;
  }

  .showing {
    display : block;
  }
</style>

<script type='text/javascript'>
  //------------------------------------------------------------------
  // Name: field()
  // Role: Locate specified document element
  //------------------------------------------------------------------
  function field( id ) {
    var result = document.getElementById( id );
    if ( !result ) {
      alert( 'Specified document element not found.  id=' + id );
    }
    return result;
  }

  //------------------------------------------------------------------
  // Name: Show()
  // Role: Display specified number of hidden rows
  //------------------------------------------------------------------
  function Show( num ) {
    var four = field( 'four' );
    var five = field( 'five' );
    if ( four ) {
      four.className = ( ( parseInt( num ) > 1 ) ? 'showing' : 'hidden' );
    }
    if ( five ) {
      five.className = ( ( parseInt( num ) > 0 ) ? 'showing' : 'hidden' );
    }
  }

  //------------------------------------------------------------------
  // Name: chosen()
  // Role: Display user selected time
  //------------------------------------------------------------------
  function chosen( obj ) {
    alert( 'Selected time: ' + obj.value );
  }

</script>
</head>
<body>
<form id='myForm' action=''>
  <table border=1>
    <tr valign='top'>
      <td>
        <table border=0>
          <tr>
            <td colspan=2>Lunch:</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='12' onclick='chosen(this);' /></td>
            <td>Noon</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='13' onclick='chosen(this);' /></td>
            <td>1 pm</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='14' onclick='chosen(this);' /></td>
            <td>2 pm</td>
          </tr>
        </table>
      </td>
      <td>
        <table border=0>
          <tr>
            <td colspan=2>Dinner:</td>
          </tr>
          <tr id='four' class='hidden'>
            <td><input type='radio' name='TimeSlot' value='16' onclick='chosen(this);' /></td>
            <td>4 pm</td>
          </tr>
          <tr id='five' class='hidden'>
            <td><input type='radio' name='TimeSlot' value='17' onclick='chosen(this);' /></td>
            <td>5 pm</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='18' onclick='chosen(this);' /></td>
            <td>6 pm</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='19' onclick='chosen(this);'/></td>
            <td>7 pm</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='20' onclick='chosen(this);'/></td>
            <td>7 pm</td>
          </tr>
          <tr>
            <td><input type='radio' name='TimeSlot' value='21' onclick='chosen(this);'/></td>
            <td>8 pm</td>
          </tr>
        </table>
      </td>
    </tr>
  </table>
  <td><input type='button' value='None' onclick='Show(0);'/></td>
  <td><input type='button' value='One'  onclick='Show(1);'/></td>
  <td><input type='button' value='Both' onclick='Show(2);'/></td>
</form>
</body>
</html>

    
    

    
  


  
I see a similar addition of whitespace when JS simply adds and removes a table row. I'm not toggling style at all.

Deleting and recreating the entire table does not have the same effect. Is this the same bug?

    
    

    
  
Fixed by checkin for bug 162063.  I believe the tests I landed there cover all the issues mentioned in this bug.
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED

    
  
Assignee: layout.tables → bzbarsky

    
    

    
  
I get the same white space; an extra blank row  when using more than 4 multiple tab rows, w/ the default skin as well as many others, except Dark Orange and PitchDark.

          You need to log in
          before you can comment on or make changes to this bug.