Before this patch, `nsCheckboxRadioFrame` and `nsSelectsAreaFrame` are shown as
`Frame` and `Block` in the frame tree dump. This patch gives them proper names
so that it is easier to find their implementation when looking at the frame tree
dump.
Differential Revision: https://phabricator.services.mozilla.com/D201667
`nsIFrame::GetCursor()` can never return `Nothing()` after bug 1687239, which
removes `nsPluginFrame`. Therefore `mLastFrameConsumedSetCursor` in
`EventStateManager` can never be true.
Differential Revision: https://phabricator.services.mozilla.com/D200890
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
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
Some context:
- Our HTML parser treats element creation, attribute-parsing, and
"DoneCreatingElement"-calls as being separate operations, and it can yield
between them.
- HTMLInputElement doesn't sanitize its values until DoneCreatingElement has
been called, presumably sanitization itself depends on values (e.g. min/max)
that might not have been parsed yet.
- So if the HTML parser yields at just the right point (before
DoneCreatingElement), then we might generate and reflow a nsRangeFrame whose
underlying values (on the element) haven't yet been sanitized.
This patch handles this situation by exposing a getter to tell us whether
DoneCreatingElement has been called. If that getter returns false, we assume
that value-sanitization hasn't happened, and we disregard the element's
(presumed-to-be-unsanitized) numeric values when determining the
range's thumb-position.
Differential Revision: https://phabricator.services.mozilla.com/D198331
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
We fail some because we right now we have a track pseudo for meter/progress.
I plan to fix this, but a lot of these frame classes are basically copy-pasta,
so I wanted to get rid of them first.
Differential Revision: https://phabricator.services.mozilla.com/D192097
These only paint inner box shadows and borders, both of which we support with
WR display items, so we probably never hit fallback rendering for this and don't
call this method. But in case we do, it should be fine to use blob rendering
for it these days.
Depends on D188490
Differential Revision: https://phabricator.services.mozilla.com/D188491
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
Calling `UpdateDefaultPreventedOnContent` separately from
`PreventDefault()` is error-prone. This patch should make it
safer.
Differential Revision: https://phabricator.services.mozilla.com/D186052
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
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
This allows us to deprecate `mozInputSource` for the Web while
avoiding console warnings for internal uses, which now use the
ChromeOnly `inputSource` attribute.
Differential Revision: https://phabricator.services.mozilla.com/D183643
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
