Not convinced this will help with bug 1809492, so different bug... But
these are places where I noticed we call nsITreeView from a member.
Differential Revision: https://phabricator.services.mozilla.com/D166527
Not a complete fix (there are some callers from reflow which are not
particularly great), but this should make the code more robust.
Differential Revision: https://phabricator.services.mozilla.com/D165042
This shouldn't change any behavior, it just refactors the code to use a shared string-cropping function.
It's still an approximation, and theoretically could be quite inaccurate in the case of complex text shaping,
but in practice is "good enough" for the kind of UI-element display where we use it.
Differential Revision: https://phabricator.services.mozilla.com/D161328
This is basically copied from how nsTextBoxFrame handles truncation, and avoids breaking surrogate pairs
(or other grapheme clusters such as base character + diacritic). It's still a "poor man's" version
of truncation that doesn't correctly measure the string in the presence of complex font shaping.
Longer-term, we should unify all this kind of truncation/ellipsizing of labels etc to use an implementation
based on CSS text-overflow, but that doesn't yet support center-cropping so it's not a drop-in replacement.
So I think we should do this as an interim measure to fix the most egregious brokenness, and make treeview
cells at least work similarly to textbox labels.
Tested manually; seems difficult to do automated tests as it'd be sensitive to exact glyph metrics.
Differential Revision: https://phabricator.services.mozilla.com/D161251
The XUL behavior in nsBox.cpp is fairly different to what the non-XUL
layout code paths do. In particular, canOverride=false means that the
min-{width,height} properties cannot go under the min widget size of the
widget, but that doesn't mean that intrinsic sizes don't affect the
final size of the widget.
This is very visible if you turn on flex emulation on Windows or macOS,
where the toolbar has an appearance that returns
width=0,height=N,canOverride=false.
With flex emulation we'd collapse the item to be zero-width, which is
not good at all.
The good thing is that this is no longer exposed to the web
(non-native-theme always returns canOverride=true), and our front-end
code doesn't seem to rely on this, so we can just remove support for
canOverride=false.
Differential Revision: https://phabricator.services.mozilla.com/D158608
All its members are optional, so we can just use it as a plain struct
rather than Maybe<> all around, which simplifies the code and prevents
silly bugs like bug 1779592.
Mostly automatic via:
rg -l 'SVGImageContext' . | xargs sed -i 's/Maybe<SVGImageContext>/SVGImageContext/g'
With trivial build fixes.
Not intended to change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151846
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
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
