It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
Note that this only happens for chrome: documents that have been
invasively styled by userChrome.css sheets. Content documents
are never intrinsically sized, and our own chrome: sheets that
use intrinsic sizing never set 'display:none' on the :root as
far as I know. I think this is an argument for removing support
for userChrome.css.
Differential Revision: https://phabricator.services.mozilla.com/D104715
This patch improves nsCanvasFrame::Reflow in a few ways.
First, we now iterate over mFrames and reflow every child.
This makes it more robust vis-à-vis the order of any placeholders
and the root frame, and also resilient against a missing root
frame (this fixes the fatal assertion in this bug). We now
also actually reflow all placeholders which wasn't the case
before. It seems like a prudent thing to do.
I also added a separate nsReflowStatus for each child.
We now also call SetOverflowAreasToDesiredBounds() in all
cases. We failed to do that in the 'mFrames.IsEmpty()' case
before, which triggered the assertions in bug 1655630 and
bug 1392106.
Differential Revision: https://phabricator.services.mozilla.com/D103592
layout/forms/crashtests/1182414.html is one of the tests
that triggered an assertion without this patch:
"ASSERTION: must have doc root as canvas frame's only child: 'overflow->OnlyChild()', layout/generic/nsCanvasFrame.cpp:710"
(because we pushed both the :root frame and a placeholder)
Differential Revision: https://phabricator.services.mozilla.com/D98859
It's straightforward to determine which writing mode is required to pass
to ComputedLogicalMargin() by looking at any subsequent method called on
the margin.
For example, if we see
```
ComputedLogicalMargin().BStartEnd(wm);
```
the writing mode needed to pass to `ComputedLogicalMargin()` is `wm`.
Differential Revision: https://phabricator.services.mozilla.com/D95661
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
Fixes tooltips/menus in responsive design mode. A few accesibility tests
had to be adjusted since tooltips are now automatically created
for them.
Differential Revision: https://phabricator.services.mozilla.com/D72400
Both PresShell() and PresContext() are cached in nsIFrame. This
simplifies the setup for the callers to
nsCSSFrameConstructor::CreateContinuingFrame().
Differential Revision: https://phabricator.services.mozilla.com/D66600
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The trickier part is that we represent -moz-image-rect as a Rect() type instead
of image with non-null clip-rect. So we need to add a bit of code to
distinguish "image request types" from other types of images.
But it's not too annoying, and we need to do the same for fancier images like
image-set and such whenever we implement it, so seems nice to get rid of
most explicit usages of nsStyleImage::GetType().
Differential Revision: https://phabricator.services.mozilla.com/D62164
--HG--
extra : moz-landing-system : lando
Otherwise code like StyleChildrenIterator won't find it, plus it is the right
thing to do anyway.
You don't really want this to inherit from the root element, even though given
this content is under our control (only in chrome documents) it is less of an
issue.
Differential Revision: https://phabricator.services.mozilla.com/D56637
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
Rounding in layout pixels is very close to snapping in raster pixels if
there are no transforms involved. This is why it worked most of the time
and fell flat in many edge cases. In future parts of this series, we
will trust scene building and frame building to do the heavy lifting for
snapping purposes.
Differential Revision: https://phabricator.services.mozilla.com/D45058
--HG--
extra : moz-landing-system : lando
