Closed Bug 9013 Opened 25 years ago Closed 25 years ago

problems setting display to none dynamically near tables

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: peterl-retired)

Details

Attachments

(10 files)

The JavaScript
2.08 KB, text/javascript
Details
The CSS (not too useful for bug, but helps see things)
2.14 KB, text/css
Details
The XUL+HTML, to work in Bugzilla
2.24 KB, text/xul
Details
Second example Javascript
2.64 KB, text/javascript
Details
Second example CSS
1.67 KB, text/css
Details
Second example XUL+HTML, to work in Bugzilla
2.06 KB, text/xml
Details
Second example, alternate CSS
1.71 KB, text/css
Details
Second example, alternate XUL+HTML, to work in Bugzilla
2.08 KB, text/xml
Details
Reattaching attachment 729 using text/xul
2.06 KB, text/xul
Details
Reattaching attachment 731 using text/xul (not text/xml)
2.08 KB, text/xul
Details
This bug only happens in Nav Quirks mode (which I know isn't used for XUL in Apprunner), but it could be something that can happen in other situations, so I'm reporting it anyway. The document to be attached has mixed XUL/HTML. The three tabs at the bottom should set display to block for one div and none for the other two. The three HTML divs are all within an XUL box element. If one of the DIVs has a table containing a tbody (doesn't happen for an entirely empty table), once it is set to display: block *dynamically*, it can't be set to display: none, and there end up being *two* box elements (as seen with Visual Debugging). If (as is *not* done in the example to be attached) the element with the table in it has display block (rather than none) initially, it can be hidden once, but once it is shown again, it won't go away. As the comments in the JavaScript file indicate, setting the background color along with display causes different things to happen - it ends up not showable rather than not hideable. If this is confusing, ask...
Actually, this isn't just a compat mode issue, but in standard mode it requires using the buttons that I took out of the trimmed down version attached to the bug. (I imagine it's the same problem, but you never know...)
In both cases, doing "Dump Content" shows that the style is correctly set, but the div with display none is still being shown. That is, this div is shown: div id=$1c93e639 class=schedule style=display: none; refcount=4<
Severity: normal → blocker
I am moving this up to blocker because it is blocking the schedule demo that I'm working on (for NS). I will attach the test case where I have problems in standard mode. The test case contains three files: HTML, JS, and CSS. Thoroughly tested on: * Linux, viewer (switched into standard mode), pull of ca. 1999-07-01 Also tested on: * Same, except opt build from mozilla.org, 1999-06-30 and other dates In the example to be attached (in 3 files: JS, XUL, and CSS), there are two tabs, "List" and "Add". Only one should be displayed at a time, and there is a function that switches the display property between them. Initially, the List tab is displayed, and the red tabs can be used to correctly switch between the two tabs. However, if the "ShowSchedule()" button is pressed, the tabs no longer work correctly. The Add tab is shown and hidden, but the List tab always stays shown. Even more interestingly, they are *next to* each other, even though they are two html:div elements in the same box. The feature in the ShowSchedule() function that seems to trigger this is the insertion of a row into the table in the List tab. (Probably you should ignore that when ShowSchedule() is called while the file is loading, this doesn't seem to happen. But I'm mentioning it anyway.) Finally, I will attach an alternate version of the CSS file that may provide some insight, and an XUL file that refers to it instead of the original version. It has some width and height rules removed. When they are removed, switching between the tabs while the switching still works correctly causes strange effects: there are areas that are not drawn over.
For some reason, the attachments aren't working from Bugzilla. I suspect it could have been an LF->CRLF conversion in the XUL file that messed up .firstChild, etc, though I'm not sure. They should work if you download them, I think. They worked for me, with absolute URLs, before I uploaded them. Aargh. If you want me to put them up on a web page, let me know...
Attachment 747 [details] is now crashing when you hit ShowSchedule(). Here's the top of the stack trace from the 07-07 build from mozilla.org: #0 0x4092bcc5 in nsCSSFrameConstructor::CreateContinuingFrame () #1 0x4092bec1 in nsCSSFrameConstructor::FindPrimaryFrameFor () #2 0x409ad31b in StyleSetImpl::FindPrimaryFrameFor () #3 0x4087ca5f in PresShell::GetPrimaryFrameFor () #4 0x4092beac in nsCSSFrameConstructor::FindPrimaryFrameFor () #5 0x409ad31b in StyleSetImpl::FindPrimaryFrameFor () #6 0x4087ca5f in PresShell::GetPrimaryFrameFor () #7 0x40929340 in nsCSSFrameConstructor::ContentAppended () #8 0x40929527 in nsCSSFrameConstructor::ContentInserted () #9 0x409ad11e in StyleSetImpl::ContentInserted () #10 0x4087c786 in PresShell::ContentInserted () #11 0x40a73afc in XULDocumentImpl::ContentInserted () #12 0x4088ba51 in nsGenericHTMLContainerElement::InsertChildAt () #13 0x4088b37f in nsGenericHTMLContainerElement::InsertBefore () #14 0x408e4bf9 in nsHTMLTableSectionElement::InsertBefore () #15 0x408e3c13 in nsHTMLTableSectionElement::InsertRow () #16 0x401505d5 in NS_NewScriptHTMLTableRowElement () #17 0x402c0272 in js_Invoke () I'm seeing the same crash (when doing the same thing) on the much larger page that this was simplified from.
I can actually get crashes with a number of quite different stack traces all resulting from the ShowSchedule() button. Sometimes it doesn't crash. Sometimes you hit Add, then ShowSchedule(), and it crashes. The trace above is from Add, then List, then ShowSchedule(), and is the only trace that I've seen on both attachment 747 [details] and my big file. There is a second stack trace (pretty similar) that I've seen on both, and a third (a little more different) only on the attachment. Are stack traces from opt builds at all useful to you?
The crash in attachment 747 [details] seems fixed in 1999-07-08-18-M8 from mozilla.org, on Linux. However, the original bug remains.
Severity: blocker → major
I worked around this in the demo. Lowering to major.
This has come back in the demo (the worked-around one that worked before). See the 4 when-com.* files in http://www.fas.harvard.edu/~dbaron/nstmp/M9-3/. You'll need to download them because of bug 11112. You'll also need a build no earlier than Aug 15 because of bug 10712 (Win only) and bug 11577 (all). If you click the "Add" button at the bottom of the panel in when-com.xul, enter some data, and click submit, the Add part doesn't go away. It should, and used to. troy, is there a chance your changes could have something to do with this? Or do you think XUL changes caused the change?
BTW, this is not fixed by using GFX widgets, but I don't think the buttons are GFX yet.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Verified fixed, Linux apprunner 1999-10-08-08-M11.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: