Closed Bug 63118 Opened 25 years ago Closed 25 years ago

Bug in Style Context Sharing

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: alan-lists, Assigned: attinasi)

References

()

Details

(Keywords: regression)

Attachments

(3 files)

Win95 Build 2000121608, style conext sharing on. When I go to http://www.brainjar.com/dhtml/menubar/demo.html and click on a menu item a blured showed effect displays below the file menu. If I turn off style context sharing with set moz_disable_style_sharing=1 and run mozilla from that window the CSS menu works fine. FYI, here is a link to the authors page describing his script. http://www.brainjar.com/dhtml/menubar/index2.html
Keywords: regression
Summary: Bug in Style Context Sharing → Bug in Style Context Sharing
this is probably related to the problems seen in bug 63016. I see this one on Linux as well, so OS -> All.
OS: Windows 95 → All
:))
Investigating... thanks for reporting.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.8
So far I have learned a couple of interesting things: 1) if I modify more than one style property at a time the problem occurs. If I only modify one property at a time, in the testcase it is visibility, then it looks fine. 2) if I make the menu DIV display:none, and then set it to display:block to show it, then I can modify all of the properties that I want and it works fine. This is probably because display:none causes no frames to be created for the element, so there is no sharing occuring at load time... I'm still looking, but I'll attach a minimized testcase showing the one-property vs. multiple-property scenario in case anyone else want to dig in too.
I've found the problem. When sibling elements have the same style rules, their frames will share a style context. This has been the case since before I got involved in the Style System, presumably it was put in by Peter Linss. Anyway, the problem happens when a modification is made to a shared style context: the data is re-resolved correctly, but the fact that the style context is shared is not known by the context or the context data, so the post-changed style data ends up being shared as well. I removed the code that does the sharing of contexts among siblings, and the problem goes away, but I'd like to see if I can come up with a way to have the context sharing among siblings get along with the more general style data sharing. At the very least, I need to understand how much benefit the context sharing among siblings is giving us vs. the more general style data sharing.
*** Bug 63016 has been marked as a duplicate of this bug. ***
Just a note: disabling sibling sharing is not an option: the space savings we gain from style data sharing are all but lost if we disable sibling sharing. So, I'm working on a way to get the shared context to be 'broken off' on the element that is having it's style rules changed, before the context data is modified, so that the other frames that are sharing that data are not affected.
*** Bug 63437 has been marked as a duplicate of this bug. ***
I have a tentative fix for this now. The problem is that sibling frames with identical style rules are sharing entire style contexts, and when one of those gets its style updated it is getting its own unique style context, but only after the original, shared, context is having its data changed. The solution is to have the ReResolveStyle method pass TRUE for the aForceUnique parameter, thus forcing the style context to be unique before the style changes are applied to the style data. I'll attach the patch for preliminary review, but I am still testing it.
sr=buster just for the record, also r=karnaze
Fix checked in: nsFrameManager.cpp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 63425 has been marked as a duplicate of this bug. ***
Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
...no really
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: