Bug in Style Context Sharing

VERIFIED FIXED in mozilla0.8

Status

()

P3
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: alan-lists, Assigned: attinasi)

Tracking

({regression})

Trunk
mozilla0.8
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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
(Reporter)

Updated

18 years ago
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

Comment 2

18 years ago
:))
(Assignee)

Comment 3

18 years ago
Investigating... thanks for reporting.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 4

18 years ago
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.
(Assignee)

Comment 5

18 years ago
Created attachment 20980 [details]
Reduced Testcase: shows that the menu can be displayed OK if no other properties except visibility are modified...
(Assignee)

Comment 6

18 years ago
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.
(Assignee)

Comment 7

18 years ago
*** Bug 63016 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

18 years ago
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. ***
(Assignee)

Comment 10

18 years ago
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.
(Assignee)

Comment 11

18 years ago
Created attachment 21089 [details] [diff] [review]
Patch to nsFrameManager to for unique style contexts in ReResolvingStyleContext
(Assignee)

Comment 12

18 years ago
Created attachment 21090 [details]
Simpler testcase with the same problem

Comment 13

18 years ago
sr=buster
just for the record, also r=karnaze
(Assignee)

Comment 14

18 years ago
Fix checked in: nsFrameManager.cpp
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

18 years ago
*** 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.