(I think the change DOMCSSDeclarationImpl::GetCSSDeclaration fixes a
purely theoretical bug that would happen if it were possible to get
ahold of a CSS rule without calling either
CSSStyleSheet::EnsureUniqueInner (which is called by
CSSRuleListImpl::IndexedGetter) or Declaration::SetImmutable (which is
called by rule matching, including that triggered by
inIDomUtils::GetCSSStyleRules). If that were possible, then mutating
such a declaration would mutate the shared Declaration, and then call
WillDirty which would clone the now-mutated Declaration, leading to the
mutation applying to both sheets that shared it rather than just the one
that should have been modified.)
This is the simplification allowed by bug 978833 patch 11 (and part of
what we would otherwise have needed to duplicate in @page and keyframe
rules; we'd also have needed to duplicate the object split between the
internal object and the DOM-exposed object, but for style rules that's
probably worth keeping for the memory savings).
--HG--
extra : commitid : 4LV6uqm7iYf
This inheritance was previously needed only by a subset of the classes
derived from css::Rule (css::StyleRule, nsCSSKeyframeRule,
nsCSSPageRule). After patch 12, it is now needed by none.
--HG--
extra : commitid : CEFVRbS42w6
Note that this adds a new public API to css::Declaration; the equivalent
API is removed from css::StyleRule and nsCSSPageRule in patch 13. But
the removal and addition need to be on opposite sides of patch 12.
This fused allocation is no larger than having a pointer, and it removes
having to worry about cycles.
--HG--
extra : commitid : EOrsMKswNMP
(This is part of a longer term plan to rename nsIStyleRule to StyleData
and nsIStyleRuleProcessor to StyleDataSource. I'm not doing all of that
here, though.)
--HG--
extra : commitid : DZGpUQO2Fey
This is done in preparation for making it implement nsIStyleRule, which
happens in patch 3, and which is used in patch 12.
--HG--
extra : commitid : 56cV7yfXq59
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
They are kept around for the sake of the standalone glue, which is used
for e.g. webapprt, which doesn't have direct access to jemalloc, and thus
still needs a wrapper to go through the xpcom function list and get to
jemalloc from there.
Each nsCSSStyleSheet has a pointer to a nsCSSStyleSheetInner. The
nsCSSStyleSheetInner is shared across multiple stylesheets, in
general. The nsCSSStyleSheetInner owns the rules and the child
stylesheets.
What this means is that a given rule object is effectively owned by
multiple sheets. However, cycles can only form through rule objects
that have been JS-wrapped, and if we're JS-wrapping a rule object that
means we have ensured that it's owned by only one stylesheet.
Therefore, we only traverse and unlink mInner if it's uniquely owned
by our sheet.
Similarly, if our child sheets or any of their rules have been
JS-wrapped, that means that we must have an mInner that we own
outright.