Make Link and SVGAElement agree on XLink handling, and make it more
explicit that SVGAElement needs to be a bit more special for SMIL.
Remove dead MathML XLink code.
Differential Revision: https://phabricator.services.mozilla.com/D142546
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
It seems Blink / WebKit run this even if in the same document, but it
seems less-potentially-breaking to restrict this to the cross-document
case.
Though at least on the test-case it seems it's loading from the same
origin, which is a bit dubious to restrict...
Differential Revision: https://phabricator.services.mozilla.com/D138369
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
Add the preference, dom.svg.pathSeg.enabled, so let
SVGPathElement::getPathSegAtLength(), SVGAnimatedPathData::pathSegList,
and SVGAnimatedPathData::animatedPathSegList behind the preference, and
set the preference to false by default on all channels.
Differential Revision: https://phabricator.services.mozilla.com/D133289
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
The specifics of how this is going to work are still getting spec'd /
discussed in https://github.com/w3c/csswg-drafts/issues/6576, but this
allows DevTools to work fine and the feature to be complete enough for
Nightly experimentation (with the other in-flight patches).
Otherwise devtools crashes when trying to inspect pages that use them.
Differential Revision: https://phabricator.services.mozilla.com/D124656
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
When using a mpath elememt which linked to a external path element, we use
GetDistancesFromOriginToEndsOfVisibleSegments() to do a quick check if we
really need to build the path (note: see
SVGMotionSMILAnimationFunction::RebuildPathAndVerticesFromMpathElem),
so we have to get the d property value from style in this function.
Differential Revision: https://phabricator.services.mozilla.com/D116920
Unfortunately, we still have to convert the cpp version into rust version.
However, it's still better than parsing it again.
If we want to use the css parser to parse d attribute, we may need an
extra API to get the whole input as &str from Parser.
(expect_string() doesn't work because the SVG attribute value is not a quoted
string.) It seems Parser::slice() cannot get the whole input because we don't
know the end index of the whole input string. We should fix this in Bug 1714238.
Differential Revision: https://phabricator.services.mozilla.com/D115571
So we update d property in the style system as well. This makes sure we
have the correct computed style and the correct rendering result.
Differential Revision: https://phabricator.services.mozilla.com/D115570
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
We parse the attribute and store it into CSS. We have tests already in
wpt, svg/path/property/*, but we cannot pass them for now because we
don't convert the relative commands into absolute commands. Those will
be fixed in Bug 1489392 once the spec issue is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D81238
This should ensure that we print SMIL animations, and also that we don't
mess up when the SVG use element propagates the internal values to
<symbol> / <svg>.
Differential Revision: https://phabricator.services.mozilla.com/D113177
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Emilio Cobos Álvarez
Mathew Hodson
Nicolas Silva
Cristian Tuns
Sylvestre Ledru
Boris Chiou
Chris Peterson
somdatta
Evgenia Kotovich
Noemi Erli
Alexandru Michis
Masayuki Nakano
Andrew Osmond
Daniel Holbert
Brindusan Cristian
Dana Keeler
Edgar Chen
Kris Wright
longsonr
Jonathan Kew
Bogdan Tara
Simon Giesecke