It seems mask-origin/mask-clip/clip-path use different mapping for
geometry-box. We should specialize each one. In this patch, we focus on
clip-path.
Differential Revision: https://phabricator.services.mozilla.com/D188146
When computing the size of an image for CanvasRenderingContext2D.drawImage(),
use the fallback size of 300 x 150 if the image contains no width or
height. This may occur if the SVG contained no width or height attribute.
Depends on D182487
Differential Revision: https://phabricator.services.mozilla.com/D182488
This patch allows us to extract a VideoPixelFormat for a VideoFrame when
backed by a GPUVideoImage. This in turn is used by SurfaceFromVideoFrame
for canvas drawing. With a concrete surface format, we can avoid
readbacks with WebGL in particular and dramatically improve performance
in existing demos.
Differential Revision: https://phabricator.services.mozilla.com/D188853
In general the canvas size and the surface size should match. However if
we are in the process of updating an OffscreenCanvas's size, it is
possible we may return a surface with a different size if an ImageBitmap
is created, or we draw using, the placeholder HTMLCanvasElement. In that
case we should ensure the surface we yield is the same size as the
current intrinsic size of the HTMLCanvasElement.
Differential Revision: https://phabricator.services.mozilla.com/D186376
Use edge-inclusive intersection like IntersectionObserver, to make
zero-size iframes that are in the viewport considered visible. This is
consistent with how we treat zero-sized in-process iframes.
Differential Revision: https://phabricator.services.mozilla.com/D185808
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
This patch adds a new method to convert from a VideoFrame to a
SurfaceFromElementResult, which is used by canvas, WebGPU and
ImageBitmap to do necessary conversions to a native surface.
Differential Revision: https://phabricator.services.mozilla.com/D181117
This patch adds a new method to convert from a VideoFrame to a
SurfaceFromElementResult, which is used by canvas, WebGPU and
ImageBitmap to do necessary conversions to a native surface.
Differential Revision: https://phabricator.services.mozilla.com/D181117
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
No change in behavior here; this is to prepare for offscreen-canvas workers
to be able to access the pref (following patch).
Depends on D181636
Differential Revision: https://phabricator.services.mozilla.com/D181637
So now we use <coord-box> to decide which box we should use. Also, we
have to tweak the calculation of path length to take the top left point
into consideration, for padding-box and content-box. border-box is the
default value, so other tests should cover it.
Differential Revision: https://phabricator.services.mozilla.com/D180397
We apply offset-position and "at <position>" to ray function. However,
only use it on the main thread. For compositor animation, we will finish
it in the following patches.
No need to add tests because there are tests in the WPT upstream repo already:
css/motion/offset-path-ray-011.html
css/motion/offset-path-ray-012.html
css/motion/offset-path-ray-013.html
css/motion/offset-path-ray-014.html
Those tests should cover what we do in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D179861
The transform on the stacking context helper has the current scale, not the largest scale of the animation. The scale on the stack context helper holds this value thanks to the logic in ChooseScale.
Before webrender we would just look at the current matrix on the gfx context so it would have final size to draw at for the animation.
I have a fix that also fixes the blob recordings/image region case but it is a little more invasive so I want to land this first. The 3rd reftest will ensure that we can't turn on blob recording without fixing that case.
Differential Revision: https://phabricator.services.mozilla.com/D175627
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
The clamping is overaly pessimistic because the returned `Rect` is still
float-based, and the call site does its own clamping to `nscoord`.
Clamping to float's numeric limit causes significant floating point errors
when clipping the transformed rect, resulting in incorrect transforms.
Differential Revision: https://phabricator.services.mozilla.com/D178081
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
The transform on the stacking context helper has the current scale, not the largest scale of the animation. The scale on the stack context helper holds this value thanks to the logic in ChooseScale.
Before webrender we would just look at the current matrix on the gfx context so it would have final size to draw at for the animation.
I have a fix that also fixes the blob recordings/image region case but it is a little more invasive so I want to land this first. The 3rd reftest will ensure that we can't turn on blob recording without fixing that case.
Differential Revision: https://phabricator.services.mozilla.com/D175627
