Closed
Bug 63118
Opened 25 years ago
Closed 25 years ago
Bug in Style Context Sharing
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.8
People
(Reporter: alan-lists, Assigned: attinasi)
References
()
Details
(Keywords: regression)
Attachments
(3 files)
4.27 KB,
text/html
|
Details | |
1.54 KB,
patch
|
Details | Diff | Splinter Review | |
558 bytes,
text/html
|
Details |
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•25 years ago
|
Keywords: regression
Summary: Bug in Style Context Sharing → Bug in Style Context Sharing
![]() |
||
Comment 1•25 years ago
|
||
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
Assignee | ||
Comment 3•25 years ago
|
||
Investigating... thanks for reporting.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.8
Assignee | ||
Comment 4•25 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•25 years ago
|
||
Assignee | ||
Comment 6•25 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 8•25 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.
Assignee | ||
Comment 10•25 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•25 years ago
|
||
Assignee | ||
Comment 12•25 years ago
|
||
Comment 13•25 years ago
|
||
sr=buster
just for the record, also r=karnaze
Assignee | ||
Comment 14•25 years ago
|
||
Fix checked in: nsFrameManager.cpp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•25 years ago
|
||
*** Bug 63425 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
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
Comment 17•23 years ago
|
||
verified that http://bugzilla.mozilla.org/attachment.cgi?id=21090&action=view
works on windows trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•