49314 - Setting a DIV to display: none does not cause re-flow

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Colin Stewart]

When setting a DIV to hidden in JavaScript the page should re-flow to look as if
the element was in fact missing, rather than just hide it.

To re-produce on this page:

1 - Click on the arrow to the left of "Fidonet".  The sub menu should appear,
and the arrow change from pointing right to pointing down.

2 - Click on the arrow to the left of "Fidonet" again.  The sub menu will
disappear, and the arrow change to point right, however the "Resources" menu
directly underneath will not move up as it should do.

3 - Click on the arrow to the left of "Resources".  The whole menu will jump up
to fill the gap as it should have done in the first place!

Found using Build ID: 2000081608

Comment 1

[deneen]

Shouldn't you be setting the display attribute?

Try display: none; .

Comment 2

[Colin Stewart]

Sorry I should have checked this first: I am in fact setting the display
attribute to make the div hide/show.  I set to none to hide it and block to
display it.  I've attached the JS file to make it a bit easier to see what is
going on.

Comment 3

[Colin Stewart]

Attachment: The JavaScript file which sets the display to none

Comment 4

[deneen]

if you remove COL#twistycol and COL#contentcol, it works.  (there appears to be
a little oddity on my end with the fidonet one because the length of the "How to
get on fidonet" link makes the table resize..)

I'm not sure what the bug is here.. (if there is one, or perhaps I am
overlooking something..)

I tried changing COL#twistycol to col.twistycol and using classes in the html,
but the effect is the same.

Comment 5

[Colin Stewart]

I'm still pretty sure that this is a bug.  I'm not sure why specifying the width 
of the table columns would stop the display: none attribute taking.  

This did use to work in Mozilla, but it was sometime ago (M15 to M16) that I 
last checked that it worked.

Can this bug be moved to NEW if more than one person can see it happening?

Comment 6

[Asa Dotzler [:asa]]

setting bug status to New

Comment 7

[karnaze (gone)]

Reassigning to attinasi.

Comment 8

[Marc Attinasi]

Accepting. Thanks for the report, I'll investigate.

Comment 9

[Marc Attinasi]

Attachment: Simple Testcase showing that setting display on a DIV does cause reflow

Comment 10

[Marc Attinasi]

I attached a simple, working testcase to start building up: given the
information from previous contributors, this looks like something to do with the
COL anyway so I'll start there when I get the chance.

Comment 11

[Marc Attinasi]

Looking for help narrowing this down...

Comment 12

[Hixie (not reading bugmail)]

Attachment: Simple and self explanatory testcase.

Comment 13

[Hixie (not reading bugmail)]

Once this is fixed, the following bugs visible on the test case should be 
reexamined:
   * The table cell is narrower when its contents are displayed than when it
     has no child frames.
   * When the table re-expands after the contents are redisplayed, the table
     border has a small gap in it near the top on both sides (and the cell's
     border has a hap on the left side).
   * The text is not displayed centered vertically in the cell. (There is too
     much space at the top of the DIV.)
   * The HTML element is not shrink-wrapping (known, filed, bug)
   * If the table is made narrow enough to 'wrap the <br>', it actually does so.
     (We should be collapsing trailing whitespace.) This actually removes the
     vertical alignment problem, suggesting that the <br> is doing weird things.
     This is a filed bug (BR should be a normal element like <span/>, and styled
     in ua.css.)
   * If the table's containing block is made narrower than the cell's specified 
     width, the cell is shrunk and the table is sized as a normal block with
     width:auto would be. This may or may not be correct behaviour, I forget.

Comment 14

[Marc Attinasi]

Chris, can you check this out? setting the DIV to display:none causes a reflow
when not in a table cell, but when in a table no reflow happens (see last two
test cases)

Comment 15

[Gianni Mariani]

This URL also seems to have div problems.

http://www.icopyright.com/1.528.000099181

Would this be the same bug ?
(needless to say this URL renders sensibly on NS4.X and IE4+5X.)

Comment 16

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 17

[ajbu]

The URL from this bug is no longer available. The two attachments seem to work 
as expected for me on Windows 2000, Mozilla build 2001022605. Fixed?

Comment 18

[Keyser Sose]

Seems to WORKSFORME
Platform: PC
OS: Windows 98
Mozilla Build: 2001022620

Comment 19

[Boris Zbarsky [:bzbarsky]]

worksforme, linux build 2001-02-25-21.  Hixie's testcase does show some of the
bullet point problems (though not all of them), but the reflow is happening
correctly.

Marking worksforme based on comments.