In order to make sure these APIs work properly, we have to flush style before
building the path to make sure the d property is up-to-date.
1. isPointInFill()
2. isPointInStroke()
3. getTotalLength()
4. getPointAtLength()
5. getPathSegAtLength() (note: Legacy API, only Gecko and WebKit support.)
Differential Revision: https://phabricator.services.mozilla.com/D133434
Use the style value when building the SVG path and its display items.
Besides, we should also invalid the cache when there are any CSS updates.
Differential Revision: https://phabricator.services.mozilla.com/D115566
At the very least per our coding style star should be near the pointer
type, not the variable name, but while we're at it let's also make
IsGeometryChangedViaCSS a bit more efficient, and use references.
Differential Revision: https://phabricator.services.mozilla.com/D100244
SVGSVGElement::SetCurrentScaleTranslate checks that things have changed but if we
manage to update both translate values before we get here then we'll skip the screen update
that we need.
Also
- introduces a tear off for SVGSVGElement.currentTranslate so we hand out the same object as required by the SVG idl
- removes SVGSVGElement::SetCurrentTranslate as dead code
- removes mPreviousScale and mPreviousTranslate from SVGSVGElement as they are no longer necessary
Differential Revision: https://phabricator.services.mozilla.com/D84796
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
SVGGeometryElement::IsPointInStroke calls SVGContentUtils::GetCTM and that can call
nsSVGUtils::GetTransformMatrixInUserSpace which needs layout to be up to date
Differential Revision: https://phabricator.services.mozilla.com/D79752
It turns out the `BuildPath()` method will still be exposed by DOM
API via `getTotalLength()`. So we need to fallback to `GetComputedStyleNoFlush()`
to handle display:none problem, and if the element doesn't even belong
to a document, we further fallback to 0.
`BuildPath()` being affected also means `GetStrokeWidth()`, etc. will also
be indirectly exposed to DOM API in some obscure cases. Let's add a utility
to handle the fallback.
Differential Revision: https://phabricator.services.mozilla.com/D33247
--HG--
extra : moz-landing-system : lando
These usecases are almost the same as the geometry property stuff. It'd
be better to use `GetPrimaryFrame()->Style()` consistently rather than
using `GetComputedStyleNoFlush()` here.
Differential Revision: https://phabricator.services.mozilla.com/D32613
--HG--
extra : moz-landing-system : lando
We cached the path of an element. Previously we only need to invalidate
the cached path if an geometry attribute is changed. Now we also need
to invalidate if the corresponding CSS is changed.
Differential Revision: https://phabricator.services.mozilla.com/D30472
--HG--
extra : moz-landing-system : lando
We cached the path of an element. Previously we only need to invalidate
the cached path if an geometry attribute is changed. Now we also need
to invalidate if the corresponding CSS is changed.
Differential Revision: https://phabricator.services.mozilla.com/D30472
--HG--
extra : moz-landing-system : lando
A lot of files include nsCOMPtr without really needing it in dom/svg. (And a
few files use the nsCOMPtr type without including its header.)
For this patch, I found candidate files by just searching for files that only
had a single line that contained "nsCOMPtr", and I took the following actions:
- If the match is an #include, then remove it (replacing it with the include
for RefPtr or AlreadyAddrefed if the file uses those types instead).
- If the match is a usage of the type, then add an #include for nsCOMPtr (as
well as one for RefPtr, if the file uses that type).
(And in a few cases, I moved an adjacent #include, to get the #include list
closer to sortedness.)
I verified that the dom/svg directory continues to build successfully in
non-unified mode (i.e. if I remove UNIFIED_ from its moz.build file). So, I'm
not removing any includes that files are now inadvertantly leaning on other
compilation units to provide.
Differential Revision: https://phabricator.services.mozilla.com/D17422
--HG--
extra : moz-landing-system : lando
The patch also const-ifies a bunch of nearby fields.
MozReview-Commit-ID: IId52fm3Y7j
--HG--
extra : rebase_source : 8b84842dbb105672cce3cd90eef20290f28feb0e
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
This is consistent with most other methods that take a drawTarget parameter r=dholbert
--HG--
extra : amend_source : 77aa7f7d9cb19f9aa08014fff3b209dc151b75f3
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67