This is weirdly placed in the colors dialog, and adds a global selector
to the UA sheet for no great reason.
This sub-setting doesn't really make a lot of sense. We don't let you
force underlines in any way, so any site CSS will override it (unlike
colors, where you can actually override the site).
Just move this to the UA sheet properly.
Differential Revision: https://phabricator.services.mozilla.com/D188326
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
Also update offset-path-url-001.html because it seems its ref html is
incorrect per the spec. We are using its `<coord-box>` (i.e. the reference box
of its containing block) as the viewport and user coordinate system, so its
offset-starting-position should be independent from its current position
from CSS reflow. The SVG shape element always provides the offset starting
position.
So I tweak offset-path-url-001.html a little bit to make it passed for all
browsers, and add some other tests to cover the case mentioned above and
other cases.
Differential Revision: https://phabricator.services.mozilla.com/D184431
Note that rect() computes to the equivalent inset() function as well.
i.e. Given `rect(t r b l)`, the equivalent function is
`inset(t calc(100% - r) calc(100% - b) l)`.
The implementation is straightforward, and we don't have to change
anything in cpp because it is always `inset()` when building the gfx::Path.
The tests for clip-path will be added in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D183528
Per spec
https://drafts.csswg.org/css-shapes-1/#basic-shape-computed-values, and
the spec issue, https://github.com/w3c/csswg-drafts/issues/9053,
all <basic-shape-rect> functions compute to the equivalent inset() function.
i.e.
`xywh(x y w h)` computes to
`inset(y calc(100% - x - w) calc(100% - y - h) x)`
The basic concept is to use `BasicShapeRect` as the specified value of
`<basic-shape-rect>`, i.e. inset()/xywh()/rect(), and its computed value is
the equivalent `InsetRect`, and so it becomes possible to interpolate among
these three functions.
Also, we can drop BuildXywhPath() and ComputeRect() because now there is
only inset() function when building gfx::Path.
Besides, tweak the test, offset-path-shape-xywh-003.html, because the original
test, `xywh(10% 10% 80% 80%)`, has to calculate `calc(100% - 10% - 80%)`.
Its result is `Percentage(0.099999964)` in Rust code, and then it makes us
compute an imprecision inset rect when building the gfx::path, which results in
a transform with the sub-pixel translation. So change it to
`xywh(10% 10% 90% 90%)` to avoid adding fuzzy tolerance.
Differential Revision: https://phabricator.services.mozilla.com/D183221
The fuzzy in the test happens on the round because we use the different way
to draw the round of clip-path (compared to border-radius property) in
the render backend, so there are some tiny differences.
Differential Revision: https://phabricator.services.mozilla.com/D182421
I'd like to reuse the data in RayReferenceData for all basic shapes,
so unpack RayReferenceData and drop this struct.
Also, use `nsPoint` for the current position and use `nsRect` for coord-box
because we use these types (i.e. app units) in ShapeUtils.
Besides, remove the usage of Maybe from nsStyleTransformMatrix.h and
just accept the pointer of ResolvedMotionPathData to avoid including
the entire header.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181008
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
The definition of `<basic-shape>` includes other types of basic shapes,
e.g. path(), xywh(), rect(). So we put them together to match the spec.
However, some properties only use the subset of basic shapes, so we use
the bitflags to choose the supported basic shape at the parse time.
Also, remove StyleBasicShapeType because no one uses it.
Only refactoring in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D179624
Take care to restore only the parts of the gfxContext that we need to because saving and restoring the complete gfxContext is expensive.
Differential Revision: https://phabricator.services.mozilla.com/D178304
The change here is to the lifetime of the gfxContext (and any groups it has) - reverting it to that prior to bug 1751025
I don't know whether that affect SVGClipPathFrame but that's the only other place the lifetime changed that I can see.
Differential Revision: https://phabricator.services.mozilla.com/D177974
Move SVGUtils:HitTestChildren into its only caller
Remove unreachable code post bug 829802
Remove code that checks for the bounding box when there is opacity as it does nothing useful.
Differential Revision: https://phabricator.services.mozilla.com/D177739
It's null because there it's an empty pattern frame. SVGPatternFrame::GetPaintServerPattern returns null because SVGPatternFrame::PaintPattern returns null because SVGPatternFrame::GetPatternWithChildren returns null.
Differential Revision: https://phabricator.services.mozilla.com/D174713
This trivially reproduces with ui.textScaleFactor=150 or so.
This needs to match ImageDocument::GetZoomLevel, for the math here to
work out.
Differential Revision: https://phabricator.services.mozilla.com/D174367
