73587 - hiding and then trying to unhide items, freezes Moz

Status: VERIFIED DUPLICATE of bug 70648

(Core :: DOM: Core & HTML, defect)

Description

[Byron Ferguson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) Gecko/20010215
BuildID:    2001021508

I use a JS function to set an items visibilty based on user click
it will hide the item just fine, but it will not set the value of "diplay" back
to "block", or if it does the item is not rendered.  Clicking on the item once
more to 'hide' it as it should causes Moz to peak the CPU and thus having to be
killed.  The image next to the 'trigger' link is updated properly thru the same
function.

Reproducible: Always
Steps to Reproduce:
1) click 'script'
2) both items in lt. blue below should dissappear, and the folder icon change to
a closed folder
3) click on 'script' again, the items below shouldn't show up but the icon
changes back to an open folder
4) click on 'script' again, Moz then peaks the CPU and has to be killed

Actual Results:  noted above

Expected Results:  it should have hidden the items (as it did), but then
redisplay them once 'block' is reinstated

Comment 1

[Fabian Guisset]

Confirmed Mozilla 0.8, Mozilla 0.8.1, and nightly build 2001032604
On windows95 it doesn't hog the cpu to 100%, but mozilla does freeze.
hang keyword, fixing URL field (double http:// sends you to www.w3.org.. known bug?)

Comment 2

[Johnny Stenback (:jst)]

Mozilla gets stuck in an infinite loop in nsBlockFrame::DoRemoveFrame() (the
last outer-most loop), reassigning to attinasi. Here's part of the stack trace:

nsBlockFrame::DoRemoveFrame() line 5586
nsBlockFrame::RemoveFrame() line 5534 + 16 bytes
FrameManager::RemoveFrame() line 850
nsCSSFrameConstructor::ContentRemoved() line 9154 + 58 bytes
nsCSSFrameConstructor::RecreateFramesForContent() line 11046 + 28 bytes
nsCSSFrameConstructor::AttributeChanged() line 9780 + 16 bytes
StyleSetImpl::AttributeChanged() line 1272
PresShell::AttributeChanged() line 4391 + 57 bytes
nsDocument::AttributeChanged() line 1705 + 32 bytes
nsHTMLDocument::AttributeChanged() line 1364
...

Comment 3

[Marc Attinasi]

I'll investigate. Can anyone suggest what the urgency might be? Is this common?

Comment 4

[Byron Ferguson]

The bug has been reported in all version of Mozilla I've tested, as well as 
within NS4 (which should be expected)

I would suggest the urgency to be at least a bug fix in the next release.  
Seeing as this is a problem with the CSS specifications not acting properly. 
But I'm new to bug reporting, and therefore do not expect to carry a great deal 
of weight.

Comment 5

[Fabian Guisset]

Probably the same issue as bug 70648

Comment 6

[Marc Attinasi]

Dup of bug 70648 - thanks.

*** This bug has been marked as a duplicate of 70648 ***

Comment 7

[Fabian Guisset]

VERIFIED dup