Switching visibility of table-elements causing strange display-errors




DOM: CSS Object Model
17 years ago
17 years ago


(Reporter: Philipp Metzler, Assigned: jst)


({crash, testcase})

Windows NT
crash, testcase

Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
Mozilla 0.9.7 Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221

1. go to this webpage and click the buttons:

i just tried it also with the latest nightly: Mozilla 0.9.8+
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020126

at least the buttons still change their colors but it doesn't crash anymore.

Comment 1

17 years ago
Created attachment 66720 [details]
Switching visibility of table-elements causing strange display-errors

same as http://www.goli.at/phil/mozilla/bugs2.html


17 years ago
Component: DOM Views and Formatting → DOM Style


17 years ago
Keywords: testcase

Comment 2

17 years ago
I see the same behavoir in IE also. 

Comment 3

17 years ago
The colors are changing, I am using the build 01-27-2002-11-trunk on win2k.
but there is a crash if history.go(0) is removed from the function.

Comment 4

17 years ago
Confirming that the attached testcase crashes the browser, although I had to
close the browser window.

It's not just table elements.  I think it's caused when any element with a
parent set to display:none is itself set to display:none (or visibility:hidden).

Attatching a simplified testcase.  It displays a link, and some blue text. 
Click the link, minimise and restore the browser.  The blue text is now black.

On more complex pages, all sorts of things happen to the text colours.  Some
effects occur immediately, some on a reflow, and some only when you
maximise/minimise the browser.  YMMV; I think it's stomping over some style data
somewhere (which I guess explains the crashes).

Comment 5

17 years ago
Created attachment 66983 [details]
Minimal testcase showing style weirdness

Minimal testcase. Note that .style.display = 'none' can be replaced with
.style.visibility = 'hidden' for the same effect.  This is independent of
strict/quirks mode.

Comment 6

17 years ago
I forgot:
Build 2002012903.

Sorry for the spam.
All the problems described in this bug workforme in a current nightly
(2002-01-19-21) on Linux.

Is this windows-only?
Severity: normal → critical
Keywords: crash

Comment 8

17 years ago
I crash when hitting the buttons on 0.9.8 on win2k. Looks like there are still
crashes in the DOM in the end ;-)
Marking NEW. eapp status (shopping cart crashing).
Ever confirmed: true
Whiteboard: [eapp]


17 years ago
Priority: -- → P3

Comment 9

17 years ago
no problems on netscape 6.2 by the way - problems occured with mozilla 0.9.7 i think
Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Keywords: nsbeta1+

Comment 11

17 years ago
removing eapp. 

eapp was incorrectly used to change this to nsbeta1+. Removing nsbeta1+ since
this was never an eapp bug nor nominated through the eapp process.
Keywords: nsbeta1+
Whiteboard: [eapp]

Comment 12

17 years ago
I've been bitten by the same bug as well while creating a new menu for a page
using DHTML and CSS. I was using a table with 2 rows; the upper row is always
visible and contains the menu headings with onMouseOver/onMouseOut handlers
(which don't always trigger either, but that's a different bug), while the lower
row contains the "dropdowns", which are either totally hidden ("display: none"
for the 2nd row) or hidden except for one ("display: table-row" for the 2nd row,
with all other TDs set to "visibility: hidden" and only one set to "visibility:

Now, the problem was that if I first turned on visibility for the dropdown to
show, Mozilla crashed immediately. Setting the TRs style to "display: table-row"
first and then changing the TDs visibility does work, but I don't think every
page on the internet can be expected to do it in that order, can it? :)

And so while there's a workaround, I'd guess this should definitely be fixed
before 1.0 getting released...
WFM, build 2002-03-09-08 (trunk) on Windows 98 SE.

Comment 14

17 years ago
Also works for me as of Mozilla Release 0.9.9; still, I've cooked up a testcase
using the menu I was designing which crashes (at least) Mozilla 0.9.7 and 0.9.8
100% of the time when you mouse over any of the menu headings:


(Of course, in this version I'm deliberately changing the visibility of hidden
elements whereas in the "good" version I'm doing it the other way round; still,
it shouldn't crash because of that.)

In the interim, for the menu used on our pages I'm just sniffing the User Agent
(which I do anyway so I can return plaintext only for lynx and w3m) for the date
after "Gecko/" and fall back to returning a normal imagemap without dynamic
menus if it's less than 20020311; I guess that should be on the safe side, right?

Comment 15

17 years ago
This bug appears fixed as of 0.9.9.  I'm unable to reproduce the problem on
either testcase attached, nor on the (more complex) internally-developed page I
originally noticed the problem with.  Suggest we resolve it FIXED or WORKSFORME,
unless anyone else can reproduce the problem?

Comment 16

17 years ago
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 17

17 years ago
does not crash on win2k 2002-03-18-09 build, marking verified
You need to log in before you can comment on or make changes to this bug.