Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
For now, replicate the label + icon structure.
Use pseudo-elements for them. We could use select.css instead, but we
need a way to to prevent the display fix-up from applying (this is
needed because otherwise <select style=display:flex> starts getting the
label and button on different lines), and pseudo-elements is easier.
Use a <span> for the icon since we basically otherwise have a hidden,
unfocusable button and it simplifies the styling that way.
Use the same for the input file content since it simplifies the logic on
the frame constructor.
nsListControlFrame gets some clean-up as well since I was trying to make
sense of nsISelectFrame, but I could split that out if needed.
Tests for bug 323656 fail now because it tests explicit inheritance from
the <select> to the <option>, and now that goes through a <slot>.
Other elements have the same issue, see
https://github.com/whatwg/html/issues/3748. So for now remove those
tests.
Differential Revision: https://phabricator.services.mozilla.com/D280041
This is what papered over this in non-printing scenarios. Reflow() is
generally too late, as RedisplaySelectedText() uses a script runner to
mutate the DOM and will only be updated on the _next_ reflow.
Differential Revision: https://phabricator.services.mozilla.com/D262333
So that we have the right index when creating the anonymous content,
without needing to reflow first.
This is the low-risk fix for uplift. More complete fix to come.
Differential Revision: https://phabricator.services.mozilla.com/D262329
This matches the pre-regression behavior. I matched select's
break-inside behavior, but we might want to make that !important, since
the old code always used unconstrained bsize for the button contents?
Differential Revision: https://phabricator.services.mozilla.com/D258190
This removes the implementation of nsHTMLButtonControlFrame, instead
reusing nsBlockFrame + align-content (or the relevant display type for
flex / grid / columns / etc).
This matches what Blink does and, for the most part, it is trivial.
It requires moving some special cases around, and override inline flow
display, tho so that buttons don't suddenly start fragmenting in the
inline axis.
It adds a tiny fix for a writing-mode mismatch in
nsBlockFrame::AlignContent(), covered by
layout/reftests/writing-mode/1138356-1-button-contents-alignment.html
containing-block-change-button tests are tweaked to avoid overflowing
the 600px viewport from WPT reftests causing scrollbar fuzziness.
contain-layout-baseline-005.html removes the <select> element just like
https://chromium-review.googlesource.com/c/chromium/src/+/5479489
removed the <button>s, since they align the same now, added a test for
that.
Differential Revision: https://phabricator.services.mozilla.com/D257149
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
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
These frames have very similar implementations in `GetMinISize()` and
`GetPrefISize()`. Therefore, add helpers to avoid code duplication. The helpers
are named `IntrinsicISize()` to match existing helpers in flex & grid container.
Drop "Get" in `GetIntrinsicISize()` for `nsFieldSetFrame` and
`nsComboboxControlFrame` to match our coding style because it always returns a
value.
Differential Revision: https://phabricator.services.mozilla.com/D216002
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
This simplifies our combobox code a bit more:
* Reflow() is only needed to compute the label isize.
* Frame construction uses a setup more similar to <input type=file> to
get the right frame tree, removing a bunch of special code.
* Lots of special code removed all over the place.
Differential Revision: https://phabricator.services.mozilla.com/D203010
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
These flags are generally always set simultaneously via
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS. This commit changes the three
remaining places where only NS_BLOCK_FLOAT_MGR is set:
1. nsFileControlFrame, used by <input type="file">
2. nsComboboxControlFrame used by <select>
3. nsSelectsAreaFrame, used by <select multiple>
(1) and (2) create their own child frames that can't be styled by
authors. (3) wraps its children into a -moz-scrolled-content which
already prevents them from taking collapsing margins with their parent.
So it is safe to add NS_BLOCK_MARGIN_ROOT here.
Differential Revision: https://phabricator.services.mozilla.com/D198523
nsCSSFrameConstructor::ConstructSelectFrame is the only place where
these functions are called and the flags parameter is always set to
NS_BLOCK_FLOAT_MGR.
Differential Revision: https://phabricator.services.mozilla.com/D198520
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
In practice, this is only ever true on the native windows theme. All
other themes return true for ThemeDrawsFocusForWidget for Button and
Menulist, which are the relevant appearance values here. So make this
more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D187856
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
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
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
This patch doesn't change behavior but I had it lying around in my
machine, and makes the code a bit easier to follow, so no reason not
to land it IMO.
Differential Revision: https://phabricator.services.mozilla.com/D154886
Jonathan Kew