Closed Bug 49314 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Layout, defect, P3)

x86
Windows 95
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: colin, Assigned: karnaze)

References

()

Details

(Keywords: css1, helpwanted, testcase, Whiteboard: (py8ieh: check 2000-10-07 05:25 comment))

Attachments

(3 files)

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
Shouldn't you be setting the display attribute? Try display: none; .
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
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.
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?
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to attinasi.
Assignee: clayton → attinasi
Accepting. Thanks for the report, I'll investigate.
Status: NEW → ASSIGNED
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.
Looking for help narrowing this down...
Keywords: helpwanted
Whiteboard: {needs narrowed 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}
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
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
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?
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
Closed: 24 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.

Attachment

General

Creator:
Created:
Updated:
Size: