Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Original Revision: https://phabricator.services.mozilla.com/D211067
Differential Revision: https://phabricator.services.mozilla.com/D221156
See the previous patch commit message for the desired behavior. Keep
non-explicit sizing working the same, but make explicit sizing account
for the button box size. This matches other browsers, and generally
makes sure that the specified number of columns fit.
Unfortunately this is not testable by WPT because spinners are not
cross-platform / specified anywhere, but I added a Gecko WPT.
This is needed because we want implicit width of number and text
controls be the same, but explicit width be different to account for the
spinners. See:
data:text/html,<input type="number"><br><input type="text"><br><input type="number" min="1" max="9"><br><input type="text" size="1">
For example. This patch on its own shouldn't change behavior.
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
This change adds a new layout.forms.textarea-sizing-excludes-auto-scrollbar.enabled pref that controls the height calculations for textareas.
With the pref enabled (the default) textareas only include the scrollbar size in the height calculations when overflow-x is scroll, this matches Chromium and WebKit.
Also adds a corresponding WPT for this.
Differential Revision: https://phabricator.services.mozilla.com/D210796
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
The removed reftsts test basically the opposite, and are sufficiently
covered by the WPTs that we start passing, so just remove them.
Differential Revision: https://phabricator.services.mozilla.com/D204797
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
Tests are added as tentative, because the behaviour when there's no content,
or when there's placeholder text, seem very differnt for each browser.
Differential Revision: https://phabricator.services.mozilla.com/D185958
Tests are added as tentative, because the behaviour when there's no content,
or when there's placeholder text, seem very differnt for each browser.
Differential Revision: https://phabricator.services.mozilla.com/D185958
It is always called from TextControlState, and always ends up in
TextControlState::ValueEquals, so we can avoid some indirection and just
use that.
Depends on D183282
Differential Revision: https://phabricator.services.mozilla.com/D183283
This is somewhat arbitrary, as the behavior of the 'size' attribute is not clearly specified
for non-fixed-width fonts where "character width" is a vague concept. So there's no absolute
"right" or "wrong" result, but there are cases where our current behavior feels quite wrong
to authors.
There are two adjustments here that aim to make the behavior more consistent and predictable.
First, rather than using the font's "average" char width (which is itself not a clearly-
defined or reliably-set metric) as the basic multiplier for the 'size' attribute, prefer
to use the width of the zero glyph (0), if present. This makes size-attribute-based input
fields behave more consistently with fields sized using the CSS 'ch' unit, rather than
having apparently-random inconsistencies between the two.
Second, the existing code adds a "padding" factor based on the font's maxAdvance, but this
can be quite excessive with modern fonts, where there may be outliers such as logo glyphs
or long ligatures that are much wider than typical characters. E.g. the macOS system font
has a triple-em-dash ligature; or the Ubuntu font, which declares an advanceWidthMax of
3511 units, although the widest glyph I can find is the "ffl" ligature with a width of 1053
units.
To limit the effect that such outliers (or incorrect metadata) can have, I'm proposing to
clamp the "max" width that we use here to twice the "char width" derived from the zero glyph
or the font's declared average. So we're still doing the "IE-like" addition of some extra
width when using non-fixed-space fonts, but it won't become as huge as it currently does
in some cases (depending on font details).
Differential Revision: https://phabricator.services.mozilla.com/D176922
This isn't needed for nsTextControlFrame because its ComputeAutoSize
implementation doesn't return an unconstrained line-height for inputs,
so we never end up in the UNCONSTRAINEDSIZE case, but it's needed for
date/time inputs.
Use GetLineHeight while at it, since it's the inflated line-height which
is what we want, and may be cached so we can avoid computing it.
Maybe in the future we can make date/time inputs just use
nsTextControlFrame, which would prevent this from happening in the
future.
Depends on D175745
Differential Revision: https://phabricator.services.mozilla.com/D175746
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
For ToResolvedValue implementation purposes we wouldn't need to split
out the vertical / font / line-height arguments and we could just pass
around the ComputedStyle, but the lh unit would need that distinction,
(because computing lh on font properties should use the parent style).
Differential Revision: https://phabricator.services.mozilla.com/D168705
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
