MakeAndAddRef ensures that the freshly-allocated object immediately gets a
refcount of 1 (before it's even passed to AddScriptRunner). This avoids
several potential footguns that otherwise exist with a zero-refcount
freshly-allocated object.
It also makes the ownership-transfer semantics more clear
(via the already_AddRefed type that it produces) - AddScriptRunner is taking
ownership of the object, rather than using it temporarily while the caller
maintains ownership.
Differential Revision: https://phabricator.services.mozilla.com/D299039
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
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
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
We've tried to give `nsFileControlFrame` its own frame type "FileControl", but
it caused a crash and we revert its frame type back to "Block" in Bug 1825623.
That prevents the crash, but the frame tree is not correct since
`nsFileControlFrame` will have `nsBlockFrame` as its next-in-flow.
The proper way to fix the crash is disallowing the form control frame to split,
similar to what we did for `nsTextControlFrame` in
https://searchfox.org/mozilla-central/rev/fc76676f61ee37b4c5420649cad6677164a29405/layout/forms/nsTextControlFrame.cpp#670
This patch doesn't mean to promote frame type usage, but it might help the
broader frame type audit in the future once we switch frame type to QueryFrame
in bug 1555477.
Note this patch might have potential behavior changes since calling
`IsBlockFrame()` on `nsFileControlFrame` now returns `false` instead of `true`.
However, we have other concrete frames such as `nsMathMLmathBlockFrame`,
`nsSelectsAreaFrame`, etc. which have frame type "Block", and callers who need
to check `nsBlockFrame` and its subclasses are probably already using
`IsBlockFrameOrSubclass()`.
Differential Revision: https://phabricator.services.mozilla.com/D212188
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
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
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
That goes back to the introduction of display lists, but I don't think
it's needed, and in fact it causes correctness issues, since the file
selector button is exposed to the web and the implementation removed
here skips painting things like floats.
Differential Revision: https://phabricator.services.mozilla.com/D175079
nsCSSFrameConstructor::CreateContinuingFrame creates a frame based on the
result of nsIFrame::Type(). The regressing bug changed the nsFileControlFrame
type from Block to its own FileControlType type, which meant that we stopped
creating nsBlockFrame continuations for it.
Fix it by restoring the previous behavior: changing the Type() back to return
Block, and using QueryFrame instead to check for the specific
nsFileControlFrame where we need to.
This is all rather messy, see bug 1555477 for related discussion.
Differential Revision: https://phabricator.services.mozilla.com/D175062
Factor a MiddleCroppingBlockFrame that does the double reflow shenanigans.
That should both be faster and easier to reason about. The only thing we need
to be careful about is to use the current inline coord from the line layout if
present to compute the real available isize.
Differential Revision: https://phabricator.services.mozilla.com/D173668
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
This is the main patch for the bug. It aims to change the grapheme cluster
break's `Next()` API by implementing SegmentIteratorUtf16 interface, and adapt
the callers. It shouldn't change the behavior.
While rewriting the caller, one caveat worth mentioning is the loop termination
condition. If the old code relies on `!AtEnd()` as the loop termination
condition, and it advances the iterator at the end of the loop, it meant
to *skip* its logic when the break position is at the end of the string. For
example, see the `mozTXTToHTMLConv::NumberOfMatches`.
This patch also hooks grapheme cluster break iterator into
Segmenter::TryCreate() interface.
Existing test coverage for the file changed:
- netwerk/test/unit/test_mozTXTToHTMLConv.js
- layout/reftests/forms/input/file/dynamic-max-width.html
Differential Revision: https://phabricator.services.mozilla.com/D135643
Include "nsLayoutUtils.h" in nsFileControlFrame to get rid of warnings in my
editor because it uses utilities such as `nsLayoutUtils::AppUnitWidthOfString`.
We compile it without issues because of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D135640
During a `TextControlState` alive, `PasswordMaskData` should be alive too.
Otherwise, we cannot keep unmasked range at reframing.
Depends on D118756
Differential Revision: https://phabricator.services.mozilla.com/D118757
Daniel Holbert