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

RESOLVED WORKSFORME

Status

()

P3
normal
RESOLVED WORKSFORME
18 years ago
18 years ago

People

(Reporter: colin, Assigned: karnaze)

Tracking

({css1, helpwanted, testcase})

Trunk
x86
Windows 95
css1, helpwanted, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: (py8ieh: check 2000-10-07 05:25 comment), URL)

Attachments

(3 attachments)

(Reporter)

Description

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

18 years ago
Shouldn't you be setting the display attribute?

Try display: none; .
(Reporter)

Comment 2

18 years ago
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.
Summary: Setting a DIV to hidden does not cause re-flow → Setting a DIV to display: none does not cause re-flow
(Reporter)

Comment 3

18 years ago
Created attachment 13051 [details]
The JavaScript file which sets the display to none

Comment 4

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

(Reporter)

Comment 5

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

18 years ago
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 7

18 years ago
Reassigning to attinasi.
Assignee: clayton → attinasi

Comment 8

18 years ago
Accepting. Thanks for the report, I'll investigate.
Status: NEW → ASSIGNED

Comment 9

18 years ago
Created attachment 16009 [details]
Simple Testcase showing that setting display on a DIV does cause reflow

Comment 10

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

18 years ago
Looking for help narrowing this down...
Keywords: helpwanted
Whiteboard: {needs narrowed testcase}
Created attachment 16436 [details]
Simple and self explanatory testcase.
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.
Keywords: css1, testcase
QA Contact: petersen → chrisd
Whiteboard: {needs narrowed testcase}

Comment 14

18 years ago
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)
Assignee: attinasi → karnaze
Status: ASSIGNED → NEW

Comment 15

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

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...
QA Contact: chrisd → ian

Comment 17

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

18 years ago
Seems to WORKSFORME
Platform: PC
OS: Windows 98
Mozilla Build: 2001022620
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Whiteboard: (py8ieh: check 2000-10-07 05:25 comment)
You need to log in before you can comment on or make changes to this bug.