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

RESOLVED FIXED in Future

Status

()

P3
normal
RESOLVED FIXED
17 years ago
7 years ago

People

(Reporter: basil, Assigned: bzbarsky)

Tracking

({css2, testcase})

Trunk
Future
x86
Windows 98
css2, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl][p3])

Attachments

(10 attachments)

(Reporter)

Description

17 years ago
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?).
(Reporter)

Comment 1

17 years ago
Created attachment 47545 [details]
display: table-row; this one breaks.
(Reporter)

Comment 2

17 years ago
Created attachment 47546 [details]
display: block: this one is correct
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?
(Reporter)

Comment 5

17 years ago
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.
(Reporter)

Comment 6

17 years ago
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."
(Assignee)

Comment 7

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

Comment 8

17 years ago
Created attachment 50713 [details]
Testcase contrasting display: table-row and display: block

Comment 9

17 years ago
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?
(Assignee)

Comment 10

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

Comment 11

17 years ago
Created attachment 50736 [details]
Test case using tables

Comment 12

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

Comment 13

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

Comment 14

17 years ago
Created attachment 57009 [details]
Creation of extra whitespace with no table-row involved

Shows that toggling between display none and display block creates whitespace

Comment 15

17 years ago
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. 
 
(Assignee)

Comment 16

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

Updated

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

Comment 17

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

Comment 18

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

Comment 19

17 years ago
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]

Updated

17 years ago
Priority: -- → P4
Target Milestone: mozilla1.0.1 → Future

Comment 20

17 years ago
WorksForMe using FizzillaCFM/2002071208.
(Assignee)

Updated

16 years ago
Depends on: 162063
(Assignee)

Comment 21

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

Comment 22

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

Comment 23

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

Comment 24

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

Comment 25

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

Updated

16 years ago
Target Milestone: --- → Future
(Assignee)

Comment 26

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

Comment 29

15 years ago
*** 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
(Assignee)

Comment 32

15 years ago
*** Bug 218939 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 33

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

Comment 34

15 years ago
Created attachment 133496 [details]
<tr> bug - with more than one cell per row it behaves a little different

Comment 35

15 years ago
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. ***

Comment 38

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

Comment 39

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

Comment 40

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

Comment 41

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

Comment 42

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

Comment 43

15 years ago
*** Bug 248286 has been marked as a duplicate of this bug. ***
*** Bug 250882 has been marked as a duplicate of this bug. ***

Comment 45

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

Comment 48

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

Updated

14 years ago
Keywords: testcase

Comment 49

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

Comment 50

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

Comment 51

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

Comment 52

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

Comment 53

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

Comment 54

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

Comment 55

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

Comment 56

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

Comment 57

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

Comment 58

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

Comment 59

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

Comment 60

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

Comment 61

14 years ago
*** Bug 276034 has been marked as a duplicate of this bug. ***
*** Bug 277508 has been marked as a duplicate of this bug. ***

Comment 63

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

Comment 64

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

Comment 65

14 years ago
*** Bug 284723 has been marked as a duplicate of this bug. ***
*** Bug 284800 has been marked as a duplicate of this bug. ***

Comment 67

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

Comment 68

14 years ago
*** Bug 294411 has been marked as a duplicate of this bug. ***
*** Bug 296277 has been marked as a duplicate of this bug. ***

Comment 70

14 years ago
*** Bug 296372 has been marked as a duplicate of this bug. ***
*** Bug 297658 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 272370

Comment 72

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

Comment 75

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

Comment 76

13 years ago
*** Bug 308803 has been marked as a duplicate of this bug. ***
*** Bug 312469 has been marked as a duplicate of this bug. ***

Comment 78

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

Comment 79

13 years ago
Created attachment 206642 [details]
General table rendering example: problem when toggling <tr>'s

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.

Comment 80

13 years ago
Created attachment 209888 [details]
extra space when tr's set to display:none

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'.

Comment 81

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

Comment 82

13 years ago
Created attachment 225686 [details]
switch display of two tbody between none and block/table-row
(Reporter)

Comment 83

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

Comment 84

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

Comment 85

13 years ago
(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. ***

Comment 87

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

Comment 88

11 years ago
Created attachment 322108 [details]
DOM node removal and replacement has a similar effect

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?

Updated

10 years ago
Duplicate of this bug: 321362

Updated

10 years ago
Duplicate of this bug: 480550
(Assignee)

Comment 91

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

Updated

10 years ago
Assignee: layout.tables → bzbarsky

Comment 92

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