If `PreareEditor()` returns `NS_OK`, but if the instance is deleted at returning
from it, `GetTextEditor()` will access `mTextEditor`. Therefore, this patch
makes `PrepareEditor()` return error if the instance is destroyed at its end.
Differential Revision: https://phabricator.services.mozilla.com/D55775
--HG--
extra : moz-landing-system : lando
They are really complicated and can run script while the instance is being
destroyed. Therefore, they should have their own `AutoTextControlHandlingState`
as "kungFuDeathGrip".
Differential Revision: https://phabricator.services.mozilla.com/D55773
--HG--
extra : moz-landing-system : lando
The destructor of `AutoTextControlHandlingState`is marked as
`MOZ_CAN_RUN_SCRIPT`, but it's not checked at build time. And this does not
need to be created when the method does not run script. Therefore, we should
mark its constructor as `MOZ_CAN_RUN_SCRIPT` instead since it's stack only
class so that its constructor and destructor are always called from same
method.
Differential Revision: https://phabricator.services.mozilla.com/D55772
--HG--
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Currently, "input" event is fired when the `AutoScriptBlocker` in `SetValue()`
is deleted. So, for keeping same behavior, the post processing after calling
`TextEditor` methods should be done before editor dispatches "input" event.
Fortunately, `TextInputListener::OnEditActionHandled()` is a good chance to
do that. Therefore, this patch makes it notify `TextControlState` and
`AutoTextControlHandlingState`.
Note that ideally, each method of `TextEditor` should return
`NS_ERROR_OUT_OF_MEMORY` coming from
`AutoTextControlHandlingState::OnEditActionHandled()`. However, it requires
a lot of changes in editor classes, and the case is really rare since editor
does not use fallible allocation. Therefore, it must be okay to crash in
editor if `OnEditActionHandled()` returns `NS_ERROR_OUT_OF_MEMORY`.
Depends on D51395
Differential Revision: https://phabricator.services.mozilla.com/D51396
--HG--
extra : moz-landing-system : lando
Currently, nobody guarantees that `TextControlState` won't be deleted while
it handles something with `MOZ_CAN_RUN_SCRIPT` methods.
This patch hides its destructor (and constructor) for making only
`TextControlState` itself can delete its instances. Then, if instance owner
wants to delete it while handling action(s), the oldest `AutoHandlingState`
will delete the `TextControlState`.
Depends on D51392
Differential Revision: https://phabricator.services.mozilla.com/D51393
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
It mostly works out, because we return an int32_t then just cast it to uint32_t,
but it would be better to return the right thing to start with.
Differential Revision: https://phabricator.services.mozilla.com/D36129
--HG--
extra : moz-landing-system : lando
BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep = true,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(aDeep,#UnbindFromTree(#g' $file; done
$ ./mach clang-format
And fix the two callers and little use of the aDeep argument (see the "Manual
changes" patch attached to bug).
Differential Revision: https://phabricator.services.mozilla.com/D32898
--HG--
extra : moz-landing-system : lando
Even less so on reframe, where it's just unsound to do so. I had to give a value
to eSetValue_Internal, since otherwise I cannot check for its presence. I can
further special-case the reframe case if you prefer.
Differential Revision: https://phabricator.services.mozilla.com/D20133
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
When editor is modified as part of user action, aFlags of
nsTextEditorState::SetValue() includes eSetValue_BySetUserInput. In this case,
TextEditor (if there is) or the method itself (if there is no editor yet)
should dispatch "input" event by themselves because we will need to initialize
InputEvents more since we're going to implement Input Event specs.
Note that even with this patch, password field stops dispatching "input" event
with call of HTMLInputElement::SetUserInput(). This is caused by a hidden bug
of TextEditRules. This will be fixed in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D12245
--HG--
extra : moz-landing-system : lando
Currently, a lot of code dispatch "input" event and some of them dispatch
"input" event with wrong interface and/or values. Therefore this patch
creates nsContentUtils::DispatchInputEvent() to make all of them dispatch
correct event.
Unfortunately, due to bug 1506439, we cannot set pointer to refcountable
classes of MOZ_CAN_RUN_SCRIPT method to nullptr. Therefore, this patch
creates temporary RefPtr<TextEditor> a lot even though it makes damage to
the performance if it's in a hot path.
This patch makes eEditorInput event dispatched with
InternalEditorInputEvent when "input" event should be dispatched with
dom::InputEvent. However, this patch uses WidgetEvent whose message is
eUnidentifiedEvent and setting WidgetEvent::mSpecifiedEventType to
nsGkAtoms::oninput when "input" event should be dispatched with
dom::Event because we need to keep that eEditorInput and
InternalEditorInputEvent are mapped each other.
Differential Revision: https://phabricator.services.mozilla.com/D12244
--HG--
extra : moz-landing-system : lando
Allow untrusted Events and Custom events to be dispatched at disabled form element. This is for interop and some developers have asked for this.
Differential Revision: https://phabricator.services.mozilla.com/D10000
--HG--
extra : moz-landing-system : lando
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
--HG--
extra : moz-landing-system : lando
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
--HG--
extra : rebase_source : 5dba46f61d70ec647cae16383b62961ac72d2f47
The dom.forms.autocomplete.formautofill check in nsContentUtils::InternalSerializeAutocompleteAttribute
will control if values other than "on" and "off" are supported.
MozReview-Commit-ID: 48X3OzvuOpV
--HG--
rename : dom/html/test/forms/test_input_autocomplete.html => dom/html/test/forms/test_autocomplete.html
extra : rebase_source : b759672d2e9ef3b1e63fd999d149cf753df60539
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
nsTextEditorState::GetValue() refers nsITextControlElement::IsPlainTextControl()
via nsTextEditorState::IsPlainTextEditor(). However, it always returns true and
virtual call with QI. So, we should get rid of these unnecessary methods.
MozReview-Commit-ID: 3gHdGrzlys4
--HG--
extra : rebase_source : a1be33a18e93e64b8cc87e4f12d5e494b14520bf
In order to speed up Required/IsRequired(), instead of querying for the
@required attribute, we're now using the NS_EVENT_STATE_REQUIRED flag to know
whether an element's value is required.
For this to work correctly, we need to set NS_EVENT_STATE_REQUIRED earlier,
that is, in AfterSetAttr(), before any consumer of IsRequired(). We also need
to update or clear our required states when input type changes, since we may
have changed from a required input type to a non-required input type or
vice versa.
Note that NS_EVENT_STATE_REQUIRED/OPTIONAL is now part of the
EXTERNALLY_MANAGED_STATES.
MozReview-Commit-ID: Bjiby9GqJSB
IsRequired() helper function returns the current 'required' state of the
element, that is, whether its required attribute is set or not. This will be
used only for input elements that @required applies.
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
In order to facilitate the movement of code with side-effects called by Element::SetAttr to Element::BeforeSetAttr and Element::AfterSetAttr, Element::AfterSetAttr should have access to the old value of the attribute. This includes information about whether there was previously a value set or not.
Accomplishing this involved passing an additional argument through functions that find and change the old attribute value in order to ensure that we can differentiate between an empty old value and an absent old value (attribute was not set).
Note that while I tried to ensure that accurate values (and their absence) are reported to Element::AfterSetAttr, I largely ignored SVG. While the old value reported for SVG values should be however accurate the value already being reported to SetAttrAndNotify was, SVG elements do not currently report unset values properly because they will never pass a null pointer to SetAttrAndNotify.
MozReview-Commit-ID: K1mha8CNFZP
--HG--
extra : rebase_source : 42776eb01451d371e4aebcc17fe3dd112c8d268b
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58