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: http://www.goli.at/phil/mozilla/bugs2.html 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.

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

I see the same behavoir in IE also.

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.

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).

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.

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?

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).

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.

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.

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: visible"). 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.

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: http://www.ssw.uni-linz.ac.at/sswstyle/Menu/DHTML40.html (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?

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?

WFM.

does not crash on win2k 2002-03-18-09 build, marking verified