We should consider step and step base when deciding whether to show second and
millisecond field, since step and step base can affect the valid time intervals,
and the valid intervals may have second/millisecond part.
MozReview-Commit-ID: H4mJvLTvBOM
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
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
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
Per spec [1], date/time inputs fall into this category:
"For input elements without a defined input activation behavior, but to which
these events apply, and for which the user interface involves an explicit
commit action but no intermediate manipulation, then any time the user commits
a change to the element's value, the user agent must queue a task to first fire
an event named input at the input element, with the bubbles attribute
initialized to true, and then fire an event named change at the input element,
with the bubbles attribute initialized to true."
So, we fire input/change events when:
- User selects a date/time from the picker
- User changes the value using up/down keys in a already complete date/time
value
- User changes the value using the number keyboard in a already complete
date/time value
- User clears the value (using reset button or using backspace)
MozReview-Commit-ID: E7Jc5qMKZj4
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
The container of a radio group is the form, if it belongs to a form, or the
document object otherwise.
When moving a radio out of a form, we should add it back to a radio group.
Similary, before moving the radio to a form, we should remove it from the
original radio group.
MozReview-Commit-ID: 22WsEhz2SXH
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
In order to reduce the size of HTMLInputElement for performance gain, we're
going to allocate input type=file related member variables only when type=file.
Since the inner fields of date/time input are now <span> instead of <input>
text, we are adding an API for binding code to set the focus state of the
bound input element when inner fields are focused/blurred.
MozReview-Commit-ID: 9wvu57xT6HZ
This removes the requirement that BeforeSetAttr comes before AttributeWillChange
(which needs the preparsed new value).
MozReview-Commit-ID: 87C6Mjc7ARh
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.
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
At this point, all this method does is ensure editor initialization and then ask
the editor state for various information. Let's cut out the middleman.
MozReview-Commit-ID: p491umScJO
This is a terrible hack, asking input[type=range] in our video control
xbl binding content continue to handle mouse/touch event, even if the
event is being defaultPrevented by the content.
MozReview-Commit-ID: G1huxbS7oeq
