In bug 1744009[1] I changed some code that looked like:
* Get the dropdown frame intrinsic size.
* If there's overlay scrollbars, add the non-overlay scrollbar size.
That code came from bug 869314. I misread the "if there's overlay
scrollbars" bit.
There's no need to explicitly add the scrollbar width to the intrinsic
size anymore. The dropdown frame no longer exists, and the button size
is split out from the scrollbar size nowadays. There's no reason
to artificially add any size to the content frame.
[1]: https://hg.mozilla.org/integration/autoland/rev/78130d73ca75#l24.652
Differential Revision: https://phabricator.services.mozilla.com/D142834
We switch the open state storage to the element rather than the frame,
to be able to preserve it across reframes.
The code is loosely based on nsHideViewer in nsSubDocument.cpp, but it's
simpler because we don't need to do restoration shenanigans.
Differential Revision: https://phabricator.services.mozilla.com/D138689
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
The issue is that combobox display may contain some non-Latin characters
that need extra block-size to display than the one line-height
calculate by using a Latin font spec in combobox control's style.
Before this patch, when a combobox control has unconstrained block-size,
we set combobox display's block-size to combobox control's one
line-height in Reflow(), which is intended to properly initialize
`BlockReflowInput::mMinLineHeight` since combobox display has
`line-height:-moz-block-height`. However, this simply prevents the
combobox display from choosing a larger block-size after the reflow. See
bug 1716212 comment 11 for an analysis.
This patch fixes the issue by carrying combox control's computed line
height to combobox display so that its computed block-size is still
unconstrained so that it can accommodate taller characters in the
display text.
After this patch, <select><option> containing non-Latin characters
should have the same block-size as <button>, and no characters should be
clipped. Modified test_unstyled_control_height.html to test this.
Differential Revision: https://phabricator.services.mozilla.com/D120877
This patch removed the unused code which introduced by Bug 1571764
because Bug 1560824 moves the `padding-block` style to <select>'s UA
rule, so now `nsComboboxDisplayFrame` doesn't have any padding in the
block axis.
Differential Revision: https://phabricator.services.mozilla.com/D119342
This eliminates a lot of down casting from nsIFrame* to nsListControlFrame*.
Make SetDropDown() accepts nsListControlFrame* because
nsCSSFrameConstructor already passes the derived type in.
We'll replace mListControlFrame with mDropdownFrame in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D119206
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
This removes one const_cast but also adds two new ones. I think
the new ones are reasonable - conceptually the function does not
modify the input, so the input should be const. If that input
is returned as the output then we need to strip the const because
the return value shouldn't be const (because the caller should be
free to modify it if desired).
Depends on D97622
Differential Revision: https://phabricator.services.mozilla.com/D97623
Both are aliases to IntrinsicISizeType::MinISize and
IntrinsicISizeType::PrefISize.
Remove MOZ_ASSERT in nsLayoutUtils::IntrinsicForAxis and
nsContainerFrame::DoInlineIntrinsicISize since IntrinsicISizeType is a
enum class nowadays, which cannot have other values.
I've compiled this patch with DEBUG_INTRINSIC_WIDTH defined in
nsLayoutUtils.cpp, and fixed aWM undefined in
nsLayoutUtils::MinSizeContributionForAxis().
Differential Revision: https://phabricator.services.mozilla.com/D94618
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
Changes to nsIScrollableFrame.h cause the world to rebuild which I find annoying.
This removes the inclusion into Element.h which is responsible for the
world-rebuilding and is relatively easy to eliminate. A bunch of usages of
nsIScrollableFrame get moved from .h files into .cpp files and I include the
header into .cpp files as needed.
Differential Revision: https://phabricator.services.mozilla.com/D90735
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
Now that we have outlines for them, unthemed select / buttons show two
different focus indicators, which is undesired.
Furthermore, the ones in comboboxes are basically unremovable /
unstylable, so authors end up having to use massive hacks to do it, see
bug 1580935.
This fixes it elegantly (IMO) by just rendering them when themed (which
is what these were for anyway, to match the windows theme).
Differential Revision: https://phabricator.services.mozilla.com/D75283
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
