This change introduces a clang plugin which checks for uses of
`NS_DECL_CYCLE_COLLECTING_ISUPPORTS` in a `final` class. These should instead
use `NS_DECL_CYCLE_COLLECTING_ISUPPORTS_FINAL`.
Not using the `_FINAL` variant can slip in under code review, and still build,
but depending on how the unified builds work out might cause a build error. This
can result in someone making changes to e.g. moz.build having to do some wildly
unrelated follow up working cleaning these up before their build passes.
By introducing a clang plugin to catch these, we can prevent them entering into
tree, and hopefully have a happier and healthier codebase for it.
Differential Revision: https://phabricator.services.mozilla.com/D304799
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
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
I've not understand why the crash occurs. To reproduce the crash, we
need the following conditions:
1. `mTextListener` is `nullptr` when `SetValue()` is called [1]
2. `mEditorInitialized` is `true` when setting the value [2]
`mTextListener` is initialized when the text control frame is
initialized [3]. So, there are 2 possible scenarios:
1. `PrepareEditor()` is called before the frame is initialized
2. `PrepareEditor()` creates the editor during a call of `SetValue()`
It seems that the first scenario is impossible because `PrepareEditor()`
needs `mSelCon` and the shadow DOM which are created when the frame is
created [4].
Additionally, the second scenario should be impossible too because
`PrepareEditor()` does nothing during setting value [5].
So, to reproduce the crash, it might require to destroy the frame
temporarily and set the value. However, I haven't found the case yet.
Interestingly, the crash report has not been reported in 150. However,
the most crash reports came from the release channel. Therefore, the
reproducible website may not be used by our tests. Thus, we cannot
consider whether it's already fixed.
Additionally, `TextControlState::mTextListener` may be recreated with
complicated situation changes and once it's created, the handling things
should be handled with the latest one. However,
`AutoTextControlHandlingState` keeps storing the old one which are set
when they are created.
To avoid complicated things about `TextInputListener` instance, we
should make `TextControlState::mTextListener` (renamed to
`mTextInputListener` in this patch) live until the `TextEditor` is
completely discarded when the text control element is disconnected or
the `<input>` element type is changed to a non-singleline text control.
Then, `TextEditor` and `TextControlState` can work with the single
`TextInputListener` instance. Then, `AutoTextControlHandlingState` does
not need to store the instance because it can refer the instance via
`TextControlState`.
1. https://searchfox.org/firefox-main/rev/5ff69e076a8d8cc38707e29d5a8d7c42d5798a8b/dom/html/TextControlState.cpp#2288-2289
2. https://searchfox.org/firefox-main/rev/5ff69e076a8d8cc38707e29d5a8d7c42d5798a8b/dom/html/TextControlState.cpp#2288-2289,2407-2408
3. https://searchfox.org/firefox-main/rev/5ff69e076a8d8cc38707e29d5a8d7c42d5798a8b/layout/forms/nsTextControlFrame.cpp#413-414,427-428
4. https://searchfox.org/firefox-main/rev/5ff69e076a8d8cc38707e29d5a8d7c42d5798a8b/dom/html/TextControlState.cpp#1556-1557
5. https://searchfox.org/firefox-main/rev/5ff69e076a8d8cc38707e29d5a8d7c42d5798a8b/dom/html/TextControlState.cpp#1484-1487
Make `TextInputListener` live longer
Differential Revision: https://phabricator.services.mozilla.com/D292688
When reframed, our frame selection might be reinitialized, losing the
drag state. Fix that up. A bit hacky, better ideas welcome, but I think
it's ok.
Differential Revision: https://phabricator.services.mozilla.com/D292907
When reframed, our frame selection might be reinitialized, losing the
drag state. Fix that up. A bit hacky, better ideas welcome, but I think
it's ok.
Differential Revision: https://phabricator.services.mozilla.com/D292907
There's no need to go through `SetValue()` etc, the value isn't supposed
to change, we're just changing where it's stored. Handle this the same
way as we handle the selection state.
The test_password_unmask_API changes restore behavior from before
bug 2020358 (I forgot to update the assert message). I don't think we
care much one way or another.
Differential Revision: https://phabricator.services.mozilla.com/D286300
Move more text editor handling to the DOM, and remove more dead layout
code.
We need to move NeedToInitializeEditorForEvent down to
TextControlElement since the eager initialization of textarea was
papering over stuff.
The change needed in test_bug300691-1.html is a progression, I think.
Plain focus() generally puts the caret at the start rather than the end.
Differential Revision: https://phabricator.services.mozilla.com/D285755
Move more text editor handling to the DOM, and remove more dead layout
code.
We need to move NeedToInitializeEditorForEvent down to
TextControlElement since the eager initialization of textarea was
papering over stuff.
The change needed in test_bug300691-1.html is a progression, I think.
Plain focus() generally puts the caret at the start rather than the end.
Differential Revision: https://phabricator.services.mozilla.com/D285755
There's still a ton of things that can be cleaned up after this, but
this setup is nicer.
For now, editor keeps getting set-up / torn down on BindToFrame. Seems
all that could be untangled, but step by step.
The preview stuff and placeholder can just be created on demand now,
rather than requiring frame reconstruction.
Also, nsSearchControlFrame and co no longer do anything of interest, so
move the still relevant bits elsewhere and remove them.
test_bug1248459.html is removed because it messes with the editor
selection using SpecialPowers, in a way such that it crosses shadow
boundaries, and messes up the selected state triggering debug asserts.
test_focus_docnav.xhtml now triggers a different code-path because of
the shadow root (rather than the frame tree traversal). Keep it working
for now by replacing it with something that isn't a shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D282953
It's called by `TextEditor` after (maybe) modifying the value before
dispatching `input` event.
First, it updates the enabled state of the undo/redo commands. However,
it's managed by the window. Therefore, it does not make sense to depend
on the frame.
Then, it updates the various state of the related objects. For making
them work with destroyed `TextEditor`, this patch makes `TextEditor`
keep storing the latest value with caching the `Text` while it's
handling something.
Differential Revision: https://phabricator.services.mozilla.com/D276790
Textarea no longer creates newlines in the middle (it only has a
trailing newline for caret positioning purposes), so this is equivalent
but avoids going through nsDocumentEncoder, nsPlainTextSerializer and so
on...
Differential Revision: https://phabricator.services.mozilla.com/D267509
PrepareEditor initializes and sets up the DOM as well so there's no need
for doing it twice.
This causes a behavior change in test_bug1785739, but I think it's a
progression, as before there were two calls to find() that ended up with
the same range.
Differential Revision: https://phabricator.services.mozilla.com/D267437
It seemed like this was the intention from the code, but it
isn't the case?
I want to use the window command table to always return the
supported commands over IPC (in order to fix bug 1964901).
Differential Revision: https://phabricator.services.mozilla.com/D263818
This is basically a wallpaper that effectively restores the previous
behavior, pending deeper refactoring of how commands are enabled /
disabled on child processes.
Differential Revision: https://phabricator.services.mozilla.com/D258881
This patch renames the `nsIContent` interface that returns a `CharacterDataBuffer`
and also renames the variables its result is assigned to at the call sites.
Differential Revision: https://phabricator.services.mozilla.com/D259934
This patch updates all occurrences of the type `nsTextFragment` into its new name, `mozilla::dom::CharacterDataBuffer`.
It also updates the includes, including sorting.
Differential Revision: https://phabricator.services.mozilla.com/D259867
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
Basically when getSelection().toString() is called, Chromium may
return an serialization on a different content than Firefox.
This patch tries to address this webcompat issue by mimicing
the same behaviour.
We should still address the spec issues, but this seems to be
an acceptable compromise.
Differential Revision: https://phabricator.services.mozilla.com/D239657
Even in these days, we notify selection listeners of selection changes
**synchronously**. Thus, we need to mark all selection change methods as
`MOZ_CAN_RUN_SCRIPT` even though they are safe in the most cases.
Depends on D241776
Differential Revision: https://phabricator.services.mozilla.com/D241778
It's currently always set to the native anonymous `<div>` for editable content
of text control element. So, it means that it's an independent selection root.
Depends on D241587
Differential Revision: https://phabricator.services.mozilla.com/D241775
Keith Cirkel