nsDocument::GetAnimationController() will lazily create an animation controller
which, in some call sites, is unnecessary.
This patch first calls HasAnimationController() and only calls
GetAnimationController() if it returns true. This avoids creating an animation
controller in situations where one is not necessarily required.
MozReview-Commit-ID: 4cdpLRvMVJU
--HG--
extra : rebase_source : 125a59c0b0535d5df9a9964538b3784ddb1212c7
Our current machinery for enabling stylo requires a docshell - if there isn't
one, we default to the Gecko style system.
When getComputedStyle operates on an element without a presshell, it uses the
caller's presshell instead. If the element has previously been styled with
one style system (but no longer has a presshell), and the caller uses a
different style backend, using the caller's style system can cause crashes when
we pull bits of cached data off the DOM (like cached style attributes).
So we want to throw when window.getComputedStyle(element) is called for a
(window, element) pair with different style backends (which is what the next
patch in this bug does).
However, that causes a few failures where stylo-backed documents try to do
getComputedStyle on an XHR document (which, without a docshell, will use the
gecko style system).
So this patch does some work to propagate the creator's style backend into
various docshell-less documents. This should allow both chrome (which uses gecko)
and content (which uses stylo) to use getComputedStyle on the response document
for XHRs they create.
Note that the second patch in this bug will make
chromeWin.getComputedStyle(contentObj) throw. If we discover code that does
that, we can just make it invoke the content's getComputedStyle method over Xrays.
MozReview-Commit-ID: 5OsmHJKq5Ui
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
--HG--
extra : rebase_source : 66c9a9e391c2f9e142575f42fd47b37334ec5752
extra : source : 97a08873177c0f18edffdb1b5589c77843a50553
This is refcounted as we'll need to hold strong references to the ImageTracker
from style structs that load images.
MozReview-Commit-ID: 994gE9tOjAn
--HG--
extra : rebase_source : 2d50059e51b42251c89a92a954cef7b49720ceba
There's a few things mashed together in this patch:
-- Enable animations in glyph documents
-- Make gfxSVGGlyphsDocument monitor the document's refresh driver to detect
updates
-- Forward updates to the gfxFontEntry
This also adds a bunch of buffer sanity checks to the code. This may not be
strictly necessary, thanks to OTS, but I think we should code defensively here
too.
--HG--
extra : rebase_source : 26b11505aa143fae6f63cd5858c87a259bb54b50