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
When a tree row in the sidebar is selected, the background of that selected row
is styled with `-moz-appearance: -moz-mac-(active-)source-list-selection`.
We have two ways of rendering such selections:
1. With vibrancy, on 10.10+ if the sidebar itself uses vibrancy, and
2. With a solid fill, on 10.9 or if the sidebar itself does not use vibrancy.
In the Firefox main browser window, sidebar styling crosses document boundaries.
```
<hbox id="browser">
<vbox id="sidebar-box"> <-- this one has -moz-appearance: -moz-mac-source-list (or not)
<browser> (bookmarksSidebar.xhtml or historySidebar.xhtml)
<window>
<tree> <-- this contains the tree body frame which renders the tree contents,
including the selection backgrounds
```
We detect whether "the sidebar itself uses vibrancy" by walking up the frame tree
and looking for a frame with `-moz-appearance: -moz-mac-source-list`.
In the past, this lookup was inconsistent between nsTreeBodyFrame.cpp and theme rendering,
and it stopped at document boundaries. This patch makes the implementations more
consistent and allows it to cross document boundaries.
The old code only worked with the given DOM structure because `-moz-appearance: -moz-mac-source-list`
was repeated on the <tree> element. I'd like to remove that duplication.
The new code works correctly if `-moz-appearance: -moz-mac-source-list` is only set
on <vbox id="sidebar-box"> and not repeated on the tree.
Depends on D51465
Differential Revision: https://phabricator.services.mozilla.com/D78924
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
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
There were some callers in nsRangeFrame that were already not-null-checking.
All platforms have a native theme and should we add new ones they could use
nsBasicNativeTheme.
Differential Revision: https://phabricator.services.mozilla.com/D65169
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
This also fixes some backwards logic in nsBlockFrame::ReflowDirtyLines, and adds
some static assertions to nsGenericHTMLElement that almost cause a very subtle
bug.
Depends on D63792
Differential Revision: https://phabricator.services.mozilla.com/D63793
--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 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 also fixes some of the issues with -moz-image-region, where we just minted
an auto out of the blue.
Depends on D43472
Differential Revision: https://phabricator.services.mozilla.com/D43474
--HG--
extra : moz-landing-system : lando
Now, `TextEditRules` should use the new editor API to mask/unmask characters
if it's for a password editor. With this change, it does not need to manage
masked characters and unmasked characters separately since the anonymous
text node always have unmasked characters and `nsTextFrame` will mask the
characters at painting time.
Differential Revision: https://phabricator.services.mozilla.com/D38005
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
Move ApplyOpacity(), CanApplyOpacity(), Paint() and PaintWithClip() methods to nsPaintedDisplayItem
Differential Revision: https://phabricator.services.mozilla.com/D30225
--HG--
extra : moz-landing-system : lando
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
