Currently, only the grid container needs the containing block size to resolve
the transferred min and max sizes for `repeat()` function in
`nsGridContainerFrame::ComputeIntrinsicISize()`.
This patch is a preparation for Bug 1865438. `mContainingBlockSize` will be used
there, so it does not change any behavior yet.
Differential Revision: https://phabricator.services.mozilla.com/D221333
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
Now, we have `nsFocusManager::GetFocusedElementStatic()` which returns focused
element if the `nsFocusManager` instance is available. Therefore, if
`nsFocusManager::GetFocusedElement()` users do not use other methods of
`nsFocusManager`, they can use `nsFocusManager::GetFocusedElementStatic()` and
make themselves simpler.
Note that some callers return early if `nsFocusManager` is not available, but
they do not return error and `nsFocusManager` instance is available in most
time of the life time of the process. Therefore, we can simply stop using the
early return.
Differential Revision: https://phabricator.services.mozilla.com/D217527
It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
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.
Differential Revision: https://phabricator.services.mozilla.com/D211067
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.
Differential Revision: https://phabricator.services.mozilla.com/D215440
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.
Differential Revision: https://phabricator.services.mozilla.com/D215549
Split out from the other patch for readability. This doesn't change
behavior but unifies where we store the buttons of
number/search/password inputs.
Differential Revision: https://phabricator.services.mozilla.com/D215548
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
David Shin