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
--HG--
extra : rebase_source : f33132e668fff48230f79990802a3d7e23e85207
Unfortunately, nsGenericHTMLElement::GetAssociatedEditor() cannot use concrete classes because it may return nsIEditor which is set via nsIDocShell.editor. The editor set to nsIDocShell may be implemented by JS since nsIEditor isn't marked as builtinclass.
MozReview-Commit-ID: 6GY9LOYp4hM
--HG--
extra : rebase_source : 3e0464067b30daf8254805458c5358d7ea644be8
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
--HG--
rename : dom/base/nsDocument.h => dom/base/nsIdentifierMapEntry.h
extra : rebase_source : c57bdfc1c13775acdcfd4732d8157d04d6b6613f
dom/html/HTMLCanvasElement.cpp:1369:12 [-Wunused-member-function] unused member function 'Revoke'
dom/html/HTMLCanvasElement.cpp:1411:12 [-Wunused-member-function] unused member function 'Revoke'
MozReview-Commit-ID: 1fmfUIO8VR6
--HG--
extra : source : 4c2087ccc105ad859c0ec0000db6032498d394ba
extra : intermediate-source : 75a8b5c0dc389d1a97b19d6b063f0b7b881931fc
extra : histedit_source : d026af384d4d282fa7c9f73a39f1f749112ce75d
Annoyingly, setting the pref doesn't magically make the function appear on the
current window, so we create an iframe and retrieve it from there.
MozReview-Commit-ID: 9fOr4YJOzXh
--HG--
extra : rebase_source : d23643b388538955cc831a3b6e1473232ab5498a
The old setup unset the HasDirAuto flag when changing the "dir" attr away from
the value "auto", and reset it when setting it to "auto", before calling
SetDirectionalityFromValue. But SetDirectionalityFromValue doesn't depend on
the HasDirAuto flag, and that flag is set correctly for us by nsGenericElement,
so we don't have to manage it ourselves at all.
The callers outside BeforeSetAttr/AfterSetAttr just preserved the flag value, so
there's no behavior change at all for them.
MozReview-Commit-ID: AC8uV3cOtH2
If all fields in date/time input box are available but the input element's
value is empty, implies that it has been sanitized. In this case, we'll set the
'bad input' validity state. If any of the fields is cleared, we'll remove the
'bad input' validity state, as incomplete field does not imply 'bad input'.
MozReview-Commit-ID: 4EBpH5CWqXM
In this patch, we change it so that we always set the input element's value
once all fields are available and let DOM HTMLInputElement sanitize it. The
value after sanitization is not updated in the displayed input box, but may
display an error message (this will be done in Part 2) if needed.
Also, when any of the field's value is deleted, we will set input element's
value back to the empty string, so that a value is not accidentally submitted.
MozReview-Commit-ID: 9NAL8UlkoBK
Annoyingly, setting the pref doesn't magically make the function appear on the
current window, so we create an iframe and retrieve it from there.
MozReview-Commit-ID: 9fOr4YJOzXh
--HG--
extra : rebase_source : d23643b388538955cc831a3b6e1473232ab5498a
The old setup unset the HasDirAuto flag when changing the "dir" attr away from
the value "auto", and reset it when setting it to "auto", before calling
SetDirectionalityFromValue. But SetDirectionalityFromValue doesn't depend on
the HasDirAuto flag, and that flag is set correctly for us by nsGenericElement,
so we don't have to manage it ourselves at all.
The callers outside BeforeSetAttr/AfterSetAttr just preserved the flag value, so
there's no behavior change at all for them.
MozReview-Commit-ID: AC8uV3cOtH2
--HG--
extra : rebase_source : c71739095e4b65e7db10f6174a875891f97738d6
Currently, nsGenericHTMLElement::CopyInnerTo uses SetInlineStyleDeclaration to clone CSS attributes. However, if we used SetParsedAttr instead, the declaration block would be addref'ed instead of being cloned.
We need to mark the declaration block as immutable in that situation so that the attribute is copied on write.
MozReview-Commit-ID: QMm23bfwqD
--HG--
extra : rebase_source : a7d8596e2f52bef21e56b9a979638c970be4c603
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
--HG--
extra : rebase_source : f751289b42b4d9d5c389042f688c53bde47d1620
Now that the side effects of parsing have been relocated to BeforeSetAttr and AfterSetAttr (Bug 1365092), we can easily switch nsGenericHTMLElement::CopyInnerTo from reparsing attributes to cloning them. They are still reparsed, however, in the case where the owning document is changing since Base URIs may have changed.
MozReview-Commit-ID: 2TlUUyBx6bL
--HG--
extra : rebase_source : b581e797a24230d012cf79c1fc567c05d9acc746
