When animating geometry attribute, we need to notify style system about the change of SMIL override style.
Differential Revision: https://phabricator.services.mozilla.com/D30361
--HG--
extra : moz-landing-system : lando
We need some utilities to convert SVG unit and attrenum to CSS unit and property id.
This is useful when we need to pass parsed geometry property directly to CSS.
Differential Revision: https://phabricator.services.mozilla.com/D30777
--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
This patch makes SVG retrieve metrics from CSS style.
It doesn't handle <svg> element because geometry properties for
outer <svg> element has been partially implemented long ago, it
needs special change.
It doesn't deal with the impact on SMIL.
Differential Revision: https://phabricator.services.mozilla.com/D29992
--HG--
extra : moz-landing-system : lando
This patch maps SVG geometry attributes to CSS property, so that the
values set via SVG attribute will be known by CSS.
It doesn't deal with how the value is used.
Differential Revision: https://phabricator.services.mozilla.com/D29960
--HG--
extra : moz-landing-system : lando
As I said over bug 1549593, the eventual goal is to use ArcSlice in all
inherited properties. But this seemed like a good first candidate that doesn't
require me to move around a lot more code, since we were already using cbindgen
for the path commands.
Differential Revision: https://phabricator.services.mozilla.com/D30134
--HG--
extra : moz-landing-system : lando
Since now most CSS transform related bugs are fixed, it's clear that the
purpose of nsSVGUtils::GetTransformMatrixInUserSpace() should solely be to
replace SVGElement::PrependLocalTransformsTo(eUserSpaceToParent).
After fixing Bug 972041, the only other usecase (Bug 1247218) no longer exists.
OTOH, there is a problem when the parent has a viewbox transform, in that case,
SVGElement::PrependLocalTransformsTo() doesn't include it, but
nsLayoutUtils::GetTransformToAncestor() does.
In fact, it's much easier to compute the transform matrix directly based on
the implementation of nsDisplayTransform::GetResultingTransformMatrixInternal(),
which is also the function internally called by nsLayoutUtils::GetTransformToAncestor().
In particular, we don't need to look at 3D stuff since our matrix is inherently 2D.
Differential Revision: https://phabricator.services.mozilla.com/D28970
--HG--
extra : moz-landing-system : lando
We use nsSVGUtils::GetTransformMatrixInUserSpace to support
CSS transform in getCTM.
Differential Revision: https://phabricator.services.mozilla.com/D28969
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
We should not treat <iframe> as <object> for SVG, otherwise there will
be unexpected sizing and other webcompat problem (e.g. getScreenCTM).
It behaved correctly before, the change was introduced to solve a double
zooming problem (bug 843480) for <iframe>. Actually the zooming problem
can be solved by avoiding zooming when the window frame is an <iframe>.
Differential Revision: https://phabricator.services.mozilla.com/D28313
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
We implements getBBox for tspan. The implementation also has consistent
behavior as getBoundingClientRect.
Differential Revision: https://phabricator.services.mozilla.com/D27428
--HG--
extra : moz-landing-system : lando
We implements getBBox for tspan. The implementation also has consistent
behavior as getBoundingClientRect.
Differential Revision: https://phabricator.services.mozilla.com/D27428
--HG--
extra : moz-landing-system : lando
We need device pixel, but TransformFramePointToTextChild returns in css pixel,
thus a scaling is necessary.
Differential Revision: https://phabricator.services.mozilla.com/D27322
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
We should use nsLayoutUtils::GetTransformToAncestor instead of
nsSVGUtils::GetUserToCanvasTM to get the transform matrix. Because the former
will also take CSS transform into account while the latter won't.
Differential Revision: https://phabricator.services.mozilla.com/D26441
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
The change to the EventTargetChainItem constructor is because we're changing mTarget to be const (to avoid taking extra stack refs to the EventTarget), so have to set it in the constructor instead of setting it after creating the object.
Differential Revision: https://phabricator.services.mozilla.com/D25813
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
We also allow leading and trailing spaces for pair to be consistent with length,
number, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25050
--HG--
extra : moz-landing-system : lando
We also allow leading and trailing spaces for pair to be consistent with length,
number, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25050
--HG--
extra : moz-landing-system : lando
With the current code we'll eventually detect the cycle, but will take much
more, creating many shadow trees unnecessarily. Take for example the following:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="133" height="232774">
<style>
symbol { display: block }
</style>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<symbol id="svg-sprite" viewBox="0 0 133 230866">
<title>svg-sprite</title>
<use xlink:href="#svg-sprite" width="500" height="500" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="228958" />
</symbol>
<use xlink:href="#svg-sprite" y="1601" width="133" height="230866" />
</svg>
Before this patch, we'd create an svg use element subtree for #svg-sprite. That
subtree will contain two other <use> elements, one under the <symbol>, one not
under it.
Both point to #svg-sprite, but we fail to detect we're an ancestor since the
element #svg-sprite we're looking at is the clone of the #svg-sprite element.
Thus we need to take a look at mOriginal instead (which is the <use> element
under #svg-sprite) rather than at the clone.
Yeah, I had to draw the trees, it's messy :)
Blink and WebKit do something slightly different (they check the element id
directly[1]). That's not 100% correct, since you can have multiple elements with
the same ID.
[1]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_use_element.cc?l=560&rcl=861855dcb8c39ba8d42497247d433277858df79b
Differential Revision: https://phabricator.services.mozilla.com/D24565
--HG--
extra : moz-landing-system : lando
Current impl at SVGMotionSMILType::Interpolate has some wrong assertions, it's probably caused by overlooking the special behavior of to-animation. These assumptions also lead weird animation in the product build. Now we take to-animation into account, and implement similar behavior as Chrome and Safari.
Differential Revision: https://phabricator.services.mozilla.com/D23095
--HG--
extra : moz-landing-system : lando
We had an assertion here that assumed progression along a motion path must be
positive, but that's not the case when we have decreasing values of
the `keyPoints` attribute. The assertion wasn't justified and nothing
depended on it being valid, so let's just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D23354
--HG--
extra : moz-landing-system : lando
When only width is needed, we should not compute height, and vice versa. Otherwise
there are exponentially repeated computations for nested svg elements, which will
make the tab unresponsive due to 100% CPU usage for exponentially long time.
Differential Revision: https://phabricator.services.mozilla.com/D20947
--HG--
extra : moz-landing-system : lando
As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
Instead of storing them as LengthPercentage | Number, always store as
LengthPercentage, and use the unitless length quirk to parse numbers instead.
Further cleanups to use the rust representation can happen as a followup, which
will also get rid of the boolean argument (since we can poke at the rust length
itself). That's why I didn't bother to convert it to an enum class yet.
Differential Revision: https://phabricator.services.mozilla.com/D21804
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
ImageLoadingContent will take care of updating element to correct state, we don't need to do this.
Especially for HTMLImageElement, because it may not reload the image after BindToTree (
e.g. the selected source isn't changed), clearing broken state may put element into
incorrect state.
The original code seems from https://bugzilla.mozilla.org/show_bug.cgi?id=491063#c32
for a performance reason, however I test the http://mozilla.pettay.fi/moztests/1x1image.html
again on recent codebase, I don't see difference with/without applying this patch.
--HG--
extra : rebase_source : 2de29cced4ad0a18a5a6908641305203cc88a5f4
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This function is invoked elsewhere in this file as "::ParseNumber(...)", which
only works if it's declared outside of any namespace. So, it needs to be moved
outside of the mozilla namespace in order to be referenced that way (and to be
truly a static function that's private to this .cpp file).
I'm not sure why this builds at all in unified mode, but however it works, it's
cheating, apparently.
Also: this patch adds a 'using' statement for the mozilla namespace, for
e.g. the RangedPtr usages in this function definition (since it no longer lives
inside of a namespace mozilla{} block).
Depends on D15232
Differential Revision: https://phabricator.services.mozilla.com/D15233
--HG--
extra : moz-landing-system : lando
And while I'm here, I'm giving SVGDataParser.h a more specific/efficient string
include, to just provide the *forward-decl* of nsAString for this file's
"nsAString&" usage in a function prototype.
Depends on D15231
Differential Revision: https://phabricator.services.mozilla.com/D15232
--HG--
extra : moz-landing-system : lando
These are to support of usages of "SVGElement" in these files, so they
problably only started needing this namespace as of bug 1515187. In any case,
they're currently relying on picking up this "using" statement from other files
in unified builds, so let's just make the usage explicit by giving them their
own "using" statement.
Also, I'm fixing up the #include for SVGElement.h in these files to use the
full mozilla/dom include path (and to make these files include their own .h
file first).
Differential Revision: https://phabricator.services.mozilla.com/D15231
--HG--
extra : moz-landing-system : lando
Bug 828240 switched the children only transform on an outer svg from applying to
each of the anonymous child's children to applying directly to the anonymous
child instead. So now when the viewBox changes on an outer svg, we need to
update (just) the overflow of the anonymous child. The children only transform
on an inner svg still applies to the children of the inner svg, so we continue
updating those children in that case.
Hit testing uses overflows as part of the testing process, so was broken by the
lack of overflow updates.
Differential Revision: https://phabricator.services.mozilla.com/D5668
--HG--
extra : moz-landing-system : lando
Bug 828240 switched the children only transform from applying to each of the
anonymous child's children to applying directly to the anonymous child instead.
So now when the viewBox changes, we need to update (just) the overflow of the
anonymous child, where previously we were updating the overflows of each of the
children (which was having no effect I guess, since they no longer have the
child only transform applied to them).
Hit testing checks for hits using overflow, so was broken by the lack of
overflow update on the anonymous child (combined with the fact that the
anonymous child is now transformed by the children only transform).
Differential Revision: https://phabricator.services.mozilla.com/D5668
--HG--
extra : moz-landing-system : lando
Animated images inside of SVGs and used in XUL frames did not get the
configured animation image mode from the pres context.
Differential Revision: https://phabricator.services.mozilla.com/D8586
The patch also removes some conditional tests involving unitMap[i] that are
now redundant due to preceding null tests against unitAtom.
MozReview-Commit-ID: CJpktlS4k15
--HG--
extra : rebase_source : fb40a9b9cb52062e2aa5312aab00a99780a387a7
The patch also const-ifies a bunch of nearby fields.
MozReview-Commit-ID: IId52fm3Y7j
--HG--
extra : rebase_source : 8b84842dbb105672cce3cd90eef20290f28feb0e
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
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.
Ran into a couple of test failures because I was leaving
mAttributes empty for empty things like MergeAttributes, and
only setting mType. Since mType is now redundant though, and
since it's the only use of PrimitiveType, I figured I'd just
remove it entirely.
Depends on D4900
Differential Revision: https://phabricator.services.mozilla.com/D6209
--HG--
extra : moz-landing-system : lando
This replaces the hash map of attributes with a tagged union. In
this case, all filter attributes will be stored in line, with the
exception of some more complex attributes which have an internal
nsTArray of floats. This should help avoid all the hashing and
extra heap allocations.
Depends on D4899
Differential Revision: https://phabricator.services.mozilla.com/D4900
--HG--
extra : moz-landing-system : lando
This is a more conservative optimization for bug 1417699. There's no
reason we need to be copying these everywhere, so let's just go ahead
and implement moves.
Differential Revision: https://phabricator.services.mozilla.com/D4899
--HG--
extra : moz-landing-system : lando
Referrer policy argurment is passed from sheet/doc to URLExtraData, default
value is RP_Unset. We use default value in some cases, particularly when there's
no certain spec talks about that (svg for example)
MozReview-Commit-ID: 5VAX1ZUXD3i
Differential Revision: https://phabricator.services.mozilla.com/D1922
--HG--
extra : moz-landing-system : lando
We define the standalone types for using derive macro easily and overriding
the behaviors of this traits. This could avoid defining the general
behavior of booleans.
Depends on D4788
Differential Revision: https://phabricator.services.mozilla.com/D4813
--HG--
extra : moz-landing-system : lando