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
This patch doesn't change behavior; GetCrossDocParentFrameInProcess() is just a
wrapper for GetCrossDocParentFrame(), which is what we were calling before.
The "InProcess" version of this API (which we're migrating to in this patch) is
used to annotate GetCrossDocParentFrame() callsites that have been vetted as
being OK with the fact that this API returns null at the boundary of a
cross-origin iframe, if fission is enabled.
In this patch, the one call that I'm migrating is inside of XUL code
(specifically for the rendering of XUL trees); and we only expect to be
rendering XUL in a single process: Firefox's parent process. So this code
should be entirely OK with the fact that this API doesn't cross process
boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D108708
(Almost?) all other scrollbar performed scrolling goes through apz already (this effort was called "desktop_zooming_scrollbars").
This one mode was missed. It uses a repeating timer and setting the curpos attribute to trigger scrolling.
Unfortunately xul trees use this path as well, so we have to keep the old path around for them.
This makes one notable change in behaviour. Both before and after this patch single clicks on scrollbar buttons pass ENABLE_SNAP to the scroll from when they request scrolling (in nsScrollbarButtonFrame::HandleButtonPress). However for repeat scrolling when clicking and holding (which is handled by nsScrollbarFrame::MoveToNewPosition), before this patch the scrolling would not use ENABLE_SNAP. This is not super clear because MoveToNewPosition sets the curpos attributes, and then ScrollFrameHelper::CurPosAttributeChanged( would get called in response to that, and it would call ScrollToWithOrigin to the do scrolling, and it does not specify the snap mode, but the default is DISABLE_SNAP. This patch changes that so that we explicitly pass ENABLE_SNAP in MoveToNewPosition. It seems that this was likely overlooked (not hard to do when it's not clear like this) when adding snapping support. It makes sense to handle snapping the same way for single clicks and clicking and holding. If this turns out to be the wrong idea we can easily change it back.
Needs a test.
Differential Revision: https://phabricator.services.mozilla.com/D105288
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This doesn't hold with fractional scale values. Right now GTK truncates
the scale factor, Windows rounds, and non-native theme rounds as well.
With this native theme will propagate correctly the floating point
values.
I tried to not change behavior meaningfully in any of the other themes,
mostly to avoid risk. GTK and Windows can be trivially tweaked to
support fractional scale factors properly if we wanted to, but seems
better to not do that as part of this patch.
Depends on D98099
Differential Revision: https://phabricator.services.mozilla.com/D98100
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
