It seems that you can't change the position property value to absolute. And if you have the property value set to absolute in the styling and then try changing it,the browser freezes up. This use to work in NS 6.2

same with 2002010506/linux

*** Bug 123098 has been marked as a duplicate of this bug. ***

Confirming, and reassigning over to Layout.

*** Bug 122818 has been marked as a duplicate of this bug. ***

Seems like a critical bug to fix. Without it the HTML W3C DOM is pretty useless.

As I said in bug #123098 You can still set the position to absolute But the element needs to be off the document when this is done. I think most people usually set the position when a new element is created. You just need to make sure you don't put the element on the document before setting the position.

Unless the use of IE is being promoted, I would urge that this bug be fixed before the next branch that the next release of Netscape will be based on. Although most sites may set the position before the element will be added to the document tree, there will be some site that don't such as the popular one mentioned in bug 122818. For most sites, the number of users using Netscape 6.x or Mozilla is minicule and is not worth the development resources to work around Mozilla bugs. I think enough damage was done with Netscape 6.0.

Second Ken Mori's comment. I wanted to use TurboTax online with Mozilla but was not able to in large part because of this bug.

Unsetting milestone, this should really be fixed for mozilla1.0.

Marking nsbeta1+

Adding testcase keyword

Is this only affecting the TurboTax? Adding chrisn and aruner.

I see the problem. We are destroying the style rules for the element before we have destroyed to old frames, so we don't kow that the old frames were absolutely positioned and we leave the placeholders around. Make sense? ;) The fix, I think, is to avoid blowing away the style data when an attribute changed notification comes through, resulting in a reframe, until after the old frames are destroyed, but before the new frames are created. BTW: there are other bugs on this, I see the assertion about the frame not being in the line list and I have seen that before. The reason is that the frame being checked is the positioend frame, not the placeholder as it shoudl be.

>Seems like a critical bug to fix. Without it the HTML W3C DOM is pretty >useless. :) Well, there are other things in the DOM that _do_ work, so I don't think I'd say this bug renders it useless. But, I understand your concern Ken, and it looks like this is probably fixed by my patch.

--> attinasi_layout@netscape.com

Comment on attachment 70438 [details] [diff] [review] patch to fix prevent deleting of style information before reframing: fixes problems with positioned and floated frames on attribute changes I'm going to say sr=jst on this one, but someone who really understands this code should give this a thorough review.

I'll try to get Hyatt to review it, he understands the code, but may not be available.

Comment on attachment 70438 [details] [diff] [review] patch to fix prevent deleting of style information before reframing: fixes problems with positioned and floated frames on attribute changes r=kmcclusk@netscape.com

Comment on attachment 70438 [details] [diff] [review] patch to fix prevent deleting of style information before reframing: fixes problems with positioned and floated frames on attribute changes a=shaver for 0.9.9.

Fix checked: /cvsroot/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,v <-- nsCSSFr ameConstructor.cpp new revision: 1.706; previous revision: 1.705

Verified in the April 22nd (2002-04-22-03).