The test case is a special case that changes focused element from a text control
to an editing host. Therefore, without a focus change, focused editor is
changed from a `TextEditor` to `HTMLEditor`. At this time, `IMEContentObserver`
needs to switch the observing target from the anonymous content if `<input>` to
children of it.
However, the editable content becomes completely changed without a focus change
in the DOM. Therefore, `IMEStateManager` needs to synthesize a fake focus move
for IME. Therefore, this patch make `IMEStateManager` recreate
`IMEContentObserver` if active one is not observing editable content for the
focused element under "current" conditions at checking it. (When
`IMEContentObserver` is being destroyed, it sends "blur" notification to IME
and the new `IMEContentObserver` instance posts "focus" notification with
all editable content data. I.e., recreating `IMEContentObserver` generates
a fake focus move from IME point of view.)
Additionally, there is the opposite case, that is, editing host of an `<input>`
whose type is not a text control may become a text control. Therefore, this
adds new WPTs to check the handler is the text editor for the text control or
the HTML editor. The tests passed on Firefox and Chrome at least.
FYI: I guess that in this case, we need to kick `focus` event listener of the
`HTMLEditor`, but anyway, users cannot change the content because it's the
case that an atomic content is the editing host. Therefore, I don't touch
about that in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D193262
`<input>` and `<textarea>` can be an editing host. If so, setting focus to
the elements causes `IMEContentObserver` observing HTML editing under the
text control element instead of observing the native anonymous tree for the
elements. Therefore, if `IMEContentObserver` observes it with `HTMLEditor`,
it does not need to notify `IMEContentObserver` of the `value` changes.
Differential Revision: https://phabricator.services.mozilla.com/D191163
This one is tricky because form controls, though I think I got it right...
This fixes a pre-existing bug where we're not following the spec for readonly
inside content-editable.
I filed this as bug 1850390 but other browsers match the spec so add a test and
fix it while at it. This allows cheaper checks for readonlyness in a couple
places.
Differential Revision: https://phabricator.services.mozilla.com/D186896
This avoids a lot of useless time on things like GetValueAsDecimal(),
where we get the default value as a string, parse it as a number for
sanitization reasons, localize it to a string, just to parse it back to
a number.
Differential Revision: https://phabricator.services.mozilla.com/D183284
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
Now, most users of `EditorBase::IsInPlaintextMode()` are `HTMLEditor` itself.
There are some exceptions:
`EditorBase::GetDesiredSpellCheckState()` uses it to consider whether the root
(`<body>` if `HTMLEditor`) element's `specllcheck` attribute should be referred
or document's editing state. I think that this should just check
`IsHTMLEditor()`, but I think it must be okay to keep this as-is for now.
`EditorEventListener::KeyUp()` uses it to consider whether `Ctrl` + left/right
`Shift` switches the text direction of the editing host if and only if user
installed both LTR/RTL keyboard layouts and running in Windows. I think that
this should keep working in plaintext mail composer because nobody can control
the direction in plaintext editor. Therefore, this needs to check either
`IsTextEditor()` or `IsPlaintextMailComposer()` returning `true`.
`EditorEventListener::DragEventHasSupportingData()` uses it to consider
whether the editor accepts styled text and files. Therefore, it needs to check
either `IsTextEditor()` or `IsPlaintextMailComposer()` returning `false`.
Finally, we can stop setting `nsIEditor::eEditorPlaintextMask` to `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D181866
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
This is an edge case which couldn't be fixed in bug 1835353.
In the testcase, `TextControlState` has new frame for the new
`<input type="number">` when its `stepUp()` is called. However, its
`TextEditor` has not been recreated yet because it's not safe yet. Therefore,
`SetValueWithoutTextEditor()` is called, but I added the new path notifying
`IMEContentObserver` of the value changes does not run if `mBoundFrame` is not
`nullptr`. I don't remember why I did so (probably for avoiding performance
regressions as far as possible), but it does not make sense not to notify
`IMEContentObserver` if only `mTextEditor` has not been recreated because
`IMEStateManager` has not been reinitialized `IMEContentObserver` with new
anonymous `<div>`s yet because it requires new `TextEditor` instance.
Differential Revision: https://phabricator.services.mozilla.com/D180767
`IMEContentObserver` can observe the value changes only while the text control
has anonymous `<div>` element because it observers the DOM mutation. The
anonymous `<div>` is alive (connected) only while the text control element
has a frame (recreated at each reframe). Therefore, `IMEContentObserver`
cannot observe the value changed during reframing.
This patch makes `TextControlState` notify `IMEContentObserver` of setting
new value directly only when it does not have `mBoundFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D179358
It was intentionally disabled in bug 271154 in 2004 for protecting users use
PC in public spaces. However, in these days, only protecting from undo
transactions is not enough and most users must use smart phones instead.
Therefore, let's revert the change for compatibility with the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D178904
If `TextControlState:mTextListener` is set to `nullptr`, at least one of
`TextControlState::mBoundFrame` or `TextControlFrame::mTextEditor` must be
set to `nullptr`. Therefore, when `TextControlState` realizes the odd state,
it should crash immediately. Then, we can investigate how to reproduce the
situation from crash reports.
Differential Revision: https://phabricator.services.mozilla.com/D174944
Before this patch, we had two `checkVisibilty` methods on the
nsISelectionController interface, backed by several layers of implementation,
ultimately backed by a single function on nsTextFrame (which didn't actually
do anything meaningful with any of the parameters).
As it turns out, this API only had one caller, in HTMLEditUtils.cpp.
This patch converts that caller to directly query nsTextFrame (if the given
node's primary frame is indeed a nsTextFrame). The direct function-call is
renamed to HasVisibleText(), to be a bit clearer about it being text-specific
and also to avoid confusion with the (unrelated) recently-specified HTML
checkVisibility() API.
With these changes, we can remove the API from the nsISelectionController
interface and its implementations.
This patch also updates the HTMLEditUtils::IsInVisibleTextFrames documentation
(with s/all/any/) to reflect the reality of what the nsTextFrame impl actually
does.
Differential Revision: https://phabricator.services.mozilla.com/D160563
Before D99291 the initialization was always done via SetSelectionRange because IsDirty was always true after input construction (because SetValue always set the flag regardless of whether actual change happened). Now the flag is always false initially, so we need to explicitly initialize the editor.
Differential Revision: https://phabricator.services.mozilla.com/D154995
Bug 1776896 happened because we have manual code to cleanup every member
for reuse. Instead, reuse the individual block of memory and use the
destructor to clean up.
Differential Revision: https://phabricator.services.mozilla.com/D150489
One unfortunate-ish thing of storing it in TextControlState is that we
can't preserve it across type changes, but that seems ok for now
according to my conversations with Serg.
In the future we might want to move the value to HTMLInputElement itself
or something, we'll see, but this should help folks fix some
long-standing quality issues in the password manager / autofill
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D150148
I'd like to use it in `IMEData.h`. However, adding new include into it may
cause bustage with MinGW, and it's included by `nsIWidget.h` because `nsIWidget`
requires some classes defined in `IMEData.h`. Therefore, I'd like to make a
new header file for avoiding the include hell.
Differential Revision: https://phabricator.services.mozilla.com/D138007
`select` event on text controls now dispatched immediately before
`selectionchange`. However, it needs to create `AsyncEventDispatcher` for
each. This cost may not be expensive, but they are called really a lot even
if there is no corresponding event listener.
Therefore, this patch makes `nsPIDOMWindow` and `EventListenerManager` have
`MayHave*EventListeners` flag separately for each, and makes
`SelectionChangeEventDispatcher` does not try to do create
`AsyncEventDispatcher` when there is no corresponding event listener.
Differential Revision: https://phabricator.services.mozilla.com/D131750
`TextControlState` is alive during reframing, but `TextEditor` is not so.
Therefore, `TextControlState` should take the `PasswordMaskData` before
`TextEditor` is destroyed. And if `TextEditor` is recreated, and the value
hasn't been modified, unmasked range should be restored in the new editor.
Depends on D118757
Differential Revision: https://phabricator.services.mozilla.com/D118758
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
It's used only by password field, i.e., only by `TextEditor`, and used
temporarily. Additionally, there is some space in `TextEditor`. So, we
can get rid of it, and make `TextEditor` store it directly.
Note that this allows to skip expensive `nsIEditor::SetFlags()` calls by
`AutoRestoreEditorState`. This may improve setting `<input>.value` performance.
Differential Revision: https://phabricator.services.mozilla.com/D118266
With the previous patch, we know `nsIEditor::eEditorWidgetMask` always
matches with `EditorBase::IsTextEditor()`. And it's not referred from JS
(including comm-central and BlueGriffon). So, we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D118262
They are used by setting text value of `TextEditor` or replacing a misspelled
word with a new word in both `TextEditor` and `HTMLEditor`. Therefore,
they should be in the `EditorBase` rather than `TextEditor`.
Note that the path of the former case may be in a hot path. Therefore, we need
to keep redirecting to `TextEditor` for keeping the performance only in the
case.
Depends on D115785
Differential Revision: https://phabricator.services.mozilla.com/D115786
Capping selection range in SetValue early makes the subsequent SetSelectionRange call unable to detect actual selection range change. This patch defers it so that select events can be consistently fired.
Differential Revision: https://phabricator.services.mozilla.com/D115729
Should be much simpler and doesn't need to deal with the different
stuff. We already have pseudo-classes for this, :autofill and
:placeholder-shown.
I initially wrote this because this is the only limitation that forces
us to have the placeholder text as a direct child of the text control
frame. In the end I kept that as-is, but this simplification is still
worth it.
We remove dom.placeholder.show_on_focus because it doesn't behave
correctly (it doesn't match the :placeholder-shown pseudo-class and it
should). It was introduced in bug 807613 and never turned to false by
default. I suspect nobody will miss this, but if somebody complains
about it we can reintroduce it properly (handling the pref in DOM
instead, changing the right state bits).
Differential Revision: https://phabricator.services.mozilla.com/D108304
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D107355
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
