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
Two changes:
* Make it work across document boundaries, so that it works on e.g., the
bookmarks sidebar.
* Don't bail out if there's no scrollable frame, as XUL <tree>s use raw
<scrollbar> elements without any scrollframe (gnarly). In that case, just
use the target frame, but make sure to skip over themed elements (like the
scrollbars themselves) so that we can find the right background.
The logic to check the canvas frame background etcetera was simpler in
FindNonTransparentBackgroundFrame. The only caller other than the
scrollbar darkening code is nsTextFrame, which should find a non-canvas frame
before anyways, but it doesn't hurt there.
Differential Revision: https://phabricator.services.mozilla.com/D114697
Two changes:
* Make it work across document boundaries, so that it works on e.g., the
bookmarks sidebar.
* Don't bail out if there's no scrollable frame, as XUL <tree>s use raw
<scrollbar> elements without any scrollframe (gnarly). In that case, just
use the target frame, but make sure to skip over themed elements (like the
scrollbars themselves) so that we can find the right background.
The logic to check the canvas frame background etcetera was simpler in
FindNonTransparentBackgroundFrame. The only caller other than the
scrollbar darkening code is nsTextFrame, which should find a non-canvas frame
before anyways, but it doesn't hurt there.
Differential Revision: https://phabricator.services.mozilla.com/D114697
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
I noticed we weren't doing this when looking at bug 1701910.
We remove support for auto style outlines in trees, which is unused
(checked that thunderbird and FF trees don't use outline: auto) and for
some mathml debugging code, which seems ok.
Differential Revision: https://phabricator.services.mozilla.com/D110399
There's a couple of uses of const_cast here, but I think they are
reasonable. Conceptually the input parameter is a const (in that it
is not modified) but the output shouldn't be const (because the
caller is free to modify it if it wants to). If we're returning the
input as output then we should strip the const attribute, hence
the const_cast.
Depends on D97621
Differential Revision: https://phabricator.services.mozilla.com/D97622
This patch covers thw low-hanging fruit: headers that either don't use
nsLayoutUtils.h at all, or where only method implementations that can
easily be moved to the .cpp file use it.
Differential Revision: https://phabricator.services.mozilla.com/D91504
We did not pass FLAG_HIGH_QUALITY_SCALING down to the document used to
rasterize the SVG to a surface, resulting in embedded raster images to
not use high quality downscaling.
Differential Revision: https://phabricator.services.mozilla.com/D56422
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--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
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
This patch is auto-generated by the following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D42218
--HG--
extra : moz-landing-system : lando
ComputedStyle* aComputedStyle doesn't provide any extra value over just aStyle.
Lots of these should be const and what not, oh well.
Differential Revision: https://phabricator.services.mozilla.com/D41933
--HG--
extra : moz-landing-system : lando
Before this patch, we would use fallback for all border images. Now for
all but vector images we will use the WebRender border images
primitives. Vector images are an exception because the fallback is
clever in that it upscales the vector image and clips to only draw the
region it requires. This avoids artifacting but to do something similar
for WebRender as it is currently defined, we would increase our CPU and
memory footprint as we would need to produce the entire vector image
upscaled, not just the parts we need. In the future we should change
WebRender to accept different image resources for each of the segments.
Differential Revision: https://phabricator.services.mozilla.com/D37093
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.
See the discussion in https://github.com/servo/webrender/issues/1280. I think we
should do this sooner rather than later.
Need to update a couple reftests to hardcode the new colors, waiting on try for
that but should be trivial.
This makes a few more tests pass which are just marked as failure in bug 1487407,
because I implementing the border-collapsing reusing a bunch of Gecko code,
including the table 3d border stuff.
Differential Revision: https://phabricator.services.mozilla.com/D6565
The previous border-collapse beveling implementation assumed that there would
only be one beveled border per side in the whole table, which is... not true at all.
So a bunch of borders ended up clobbering other values in mBevelBorders and
never getting painted.
I'm actually somewhat scarily surprised that only this reftest seems to fail
without this patch...
Here we reuse most of the existing one-off beveling / border rendering support
in nsCSSRendering, and convert the Gecko bevels into a WebRender display list
using rects and borders. This is only remotely possible thanks to Gecko not
supporting dotted / dashed beveled borders :)
This would slightly easier and presumably also more efficient with a triangle
display item in WR instead of (ab)using the border display item to render the
bevel, but this is probably relatively edge-casey so maybe not worth it... In
any case I've left a TODO comment there, that can be a nice followup if we deem
it worth it.
Anyway, I'm _so_ sorry for the border trick, I was this (||) close to go and
rewrite our border collapsing code, but after a few tries I realized it'd take
me a whole lot of time (instead of the day that this has taken me).
Differential Revision: https://phabricator.services.mozilla.com/D4793
When generating display lists for WebRender, we were not caching the
draw result via nsDisplayItemGenericImageGeometry::UpdateDrawResult (or
similar) after completing CreateWebRenderCommands. This is important
because reftests use this to force sync decoding for images; it may be a
reason for image-related intermittent failures on *-qr builds.
Additionally, we may have been requesting fallback in cases where fallback
could not do anything more than WebRender could. For example, if we can't
get an image container yet, there is no point in requesting fallback
because it might just be we haven't started decoding yet. We should just
return the actual draw result in such cases.