In particular:
* Always handle meta viewport in RDM. This fixes bug 1625999 too by
making touch simulation enabled and disabled consistent.
* Restore the resolution to 1 when toggling RDM. This is just simpler,
and we're not keeping around the visual viewport offsets anyways
so...
* Deal with the change more easily, at the same point we switch
scrollbars etc.
Differential Revision: https://phabricator.services.mozilla.com/D206266
LogicalAxis is one of the Logical* enums. Converting it from enum to
enum class increases type safety. To run with the pre-existing code,
type casting was added when needed. Comments have been edited where
needed.
Differential Revision: https://phabricator.services.mozilla.com/D206108
GPUVideoImage::GetAsSourceSurface() is heavy weight. It seems better to prevent to call it if possible.
The change handles only a case that CanvasTranslator is used, SurfaceDescriptor is RemoteDecoderVideoSubDescriptor::Tnull_t and OptimizeShadow is not used.
DrawTargetRecording::DrawSurfaceDescriptor() also holds layers::Image of SurfaceDescriptor. It is necessary to keep the Image alive in CanvasDrawEventRecorder until end of its usage in CanvasTranslator.
Differential Revision: https://phabricator.services.mozilla.com/D205677
While we are computing the transform-box:stroke-box, for CSS Transforms or
Motion path Transforms, we have to avoid the cyclic dependency not only
for the SVG geometry frame itself, but also for the desendants of
the SVG container frame. Therefore, we just compute its fill-box (i.e.
make |getStroke| be false).
https://github.com/w3c/csswg-drafts/issues/9640
Differential Revision: https://phabricator.services.mozilla.com/D203184
Most of the time, we don't need to call Document::GetDocumentURI in
nsLayoutUtils::PaintFrame, as it is only used when we are logging or
dumping to the console. We should avoid calling it because this might be
quite large in the case of data URIs and result in OOM crashes. This is
most commonly observed with rasterizing SVG images.
Differential Revision: https://phabricator.services.mozilla.com/D197637
https://hg.mozilla.org/integration/mozilla-inbound/rev/621ab19e86db (bug 1097464) is where the IsPreserve3DLeaf call was added. At that time FindReferenceFrame did exist and did not call IsPreserve3DLeaf.
FindReferenceFrame is used in more places and all the places that one would expect to cause breakage. I searched and I do not see any evidence that preserve3d leaves should be reference frames.
The only case where a frame would be IsPreserve3DLeaf but not transformed is when it has backface hidden. I see no reason by backface hidden would cause a reference frame.
I believe that the way that we handle preserve3d has changed significantly since that patch landed, so if it was correct then, likely to not be correct now.
Differential Revision: https://phabricator.services.mozilla.com/D197439
The return value of nsLayoutUtils::AsyncPanZoomEnabled only changes if we descend into a frame whose display root widget is different. But that is not possible, we do not descend into any frames that are in different widgets.
Differential Revision: https://phabricator.services.mozilla.com/D197237
The return value of nsLayoutUtils::AsyncPanZoomEnabled only changes if we descend into a frame whose display root widget is different. But that is not possible, we do not descend into any frames that are in different widgets.
Differential Revision: https://phabricator.services.mozilla.com/D197237
This will make possible to animate custom properties on Gecko side. For now, the
animation code keeps only dealing with nsCSSPropertyID, so behavior is unchanged.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D190816
Differential Revision: https://phabricator.services.mozilla.com/D191059
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
Also, drop `nsLayoutUtils::ComputeGeometryBox()` and avoid doing mapping
in `ComputeHTMLReferenceRect()` and `ComputeSVGReferenceRect()`. The
caller should handle it properly because each property uses its own mapping
between CSS box and SVG box.
Note:
1. mask-clip-3.html is copied from mask-clip-1.html but just replace
css boxes with svg boxes.
2. mask-clip-4.html is copied from mask-clip-2.html but just replace
svg boxed with css boxes.
Differential Revision: https://phabricator.services.mozilla.com/D188316
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
