Using concrete class rather than interface classes (nsI*Editor) will allow to reduce QI and some virtual calls. Therefore, Editor classes should be used as concrete class as far as possible.
Unfortunately, if classes referring editor are initialized via scriptable interface, we cannot do this because nsI*Editor is still not marked as builtinclass. Therefore, their editor may be implemented by JS. E.g., inline nsIInlineSpellChecker.init() and nsIDocShell.editor. Such remaining cases should be fixed after nsI*Editor classes are marked as builtinclass.
Note that this patch also creates nsIdentifierMapEntry.h which is separated from nsDocument.h because ShadowRoot.h needs the class but exposing nsDocument.h to the global and includes it causes bustage on Linux and Android. Therefore, for fixing the include hell, this patch touches them and ContentChild.cpp.
MozReview-Commit-ID: i6fLWw6Qeo
When editor has focus, input.value setter will call UpdateOverlayTextVisibility via nsTextInputListener::EditAction -> nsTextControlFrame::SetValueChanged at first. But SetValue will call UpdateOverlayTextVisibility again via ValueWasChanged.
So it is unnecessary to call UpdateOverlayTextVisibility on nsTextEditorState::SetValue when we have the editor.
MozReview-Commit-ID: Hw3Bh64Euo6
We get previous input.value twice in HTMLInputElement::SetValue and nsTextEditorState::SetValue when setting input.value. Since nsTextEditorState::GetValue uses DocumentEncoder, it is expensive. So we should use old value as parameter of nsTextEditorState::SetValue if possible.
MozReview-Commit-ID: A1UPfETTVCn
nsIPlaintestEditor.setText still use BeginPlaceHolderTransaction and EndPlaceHolderTransaction. But since input.value setter doesn't create undo transaction, it is unnecessary to save/restore selection via AutoPlaceHolderBatch. So before calling setText, we should reset selection to reduce saving and restoring selection.
Save/Restore selection is ~7% of input.value setter.
MozReview-Commit-ID: 6yBKCtRmkQt
Although we use StartBatchChanges and EndBatchChanges in nsTextEditorState::SetValue, we have a path that EndBatchChanges isn't called. So we should use RAII class to call EndBatchChanges correctly.
MozReview-Commit-ID: 6bjtTT9wItA
See bug 1346723. I would like to turn off undo when not user interaction. Except to Gecko, other browsers don't create undo history by input.value setter.
MozReview-Commit-ID: 9P1eOKTXCXN
When not using eSetValue_BySetUserInput, we should use SetText transaction instead for fast path. For backward compatibility, when input.value setter is by user interaction, I keep original way. Because the original way doesn't replace all text when some string matches.
MozReview-Commit-ID: IDm7Y1NBmaK
Currently, edit commands for native key bindings are stored in widget. This is
stateful and really complicated in content process because it needs to cache
them.
We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination. Then, child process can handle it even if it's delayed
event or it's a nested event.
This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().
MozReview-Commit-ID: BGRvBrLz5lp
input.value setter removes editor flags and max-length to set value. To clean up code, I would like to use RAII class to set and restore it.
Actually, when the frame is being destroyed by InsertText, it isn't restored. But it might be safe since the flags is set again on nsTextEditorState::PrepareEditor by focus.
MozReview-Commit-ID: J0OYYluWD8z
Actually, we use GetValue to check whether value is empty or not for placeholder. But since GetValue uses TextEditor::OutputToString when on editor, it is expensive. Since editor has DocumentIsEmpty method, we should use it for this case.
MozReview-Commit-ID: rQX8yjnWQz
maxlength will be set by nsTextControlFrame::AttributeChanged via RestyleManager. If element is display:none, RestyleManager won't call Frame's AttributeChanged. So we should always initialize maxlength when setting focus.
Also, wrap attribute for textarea element will be updated by HTMLTextAreaElement even if display:none. So this issue doesn't occur. maxlength might have to be updated by HTMLInputElement. But it is unnecessary to update editor's maxlength on display:none since this is used on focused editor.
MozReview-Commit-ID: JHODOBTv62v
Otherwise we end up calling into editor code and doing a bunch of work even though the value hasn't actually changed, when a value with \r in it is set repeatedly.
This introduces two behavior changes:
1) In cached mode, we used to treat unknown selection directions as "none".
Now we treat it like "forward", consistently with the "have an editor" mode.
2) Before this change, in cached mode, we did not fire "select" events on
selectionDirection changes.
MozReview-Commit-ID: 4nBCAm3mAiz
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionEnd changes.
3) Changes the IDL type of HTMLInputElement's selectionEnd attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: J3Gkhr8VnbS
This introduces three behavior changes:
1) Before this change, in cached mode, we did not enforce the "start <= end"
invariant.
2) Before this change, in cached mode, we did not fire "select" events on
selectionStart changes.
3) Changes the IDL type of HTMLInputElement's selectionStart attribute to
"unsigned long" to match the spec and HTMLTextareaElement.
MozReview-Commit-ID: JM9XXMMPUHM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
MozReview-Commit-ID: AEW9D1zG6sM
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
