This can happen because we don't have a nice mechanism to update the
validity bits in all cases where the computed "language" changes.
That's not really a regression, and I'm on PTO, so for now we just deal
with it. The "bad input" message seems appropriate for this case rather
than returning garbage numbers.
Differential Revision: https://phabricator.services.mozilla.com/D82402
This restores our previous behavior with the new <input type=number>
implementation (see the changes in test_input_number_l10n.html, which undoes the
changes of the regressing bug), and adds a test that shows that we display the
localized value properly.
Differential Revision: https://phabricator.services.mozilla.com/D66822
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--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
When we call nsContentUtils::IsPatternMatching, we swallow JS engine errors
unconditionally returning true.
This is bad, because if it happens in one of the value sets that arguably
shouldn't change the state of the element, we end up returning an arbitrary
value (true) which may or may not match the previous state of the element.
Handle error explicitly instead, by not updating the state.
Differential Revision: https://phabricator.services.mozilla.com/D45727
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
The XBL binding implementation relied on nsDateTimeControlFrame to call into
its nsIDateTimeInputArea implementation. This is correct because the XBL binding
is only constructed when the element has a frame. If the value is set while the
element is hidden, the XBL binding will pick up the correct value during construction.
That is not the case for UA Widget. As it is constructed when the DOM is attached,
relying on nsDateTimeControlFrame to send an event when attributes change means
the event won't be sent to the already constructed UA Widget.
This patch fixes that by moving the event dispatching calls originating from
HTMLInputElement out of nsDateTimeControlFrame, so they will behave correctly in
the absence of the frame.
I've also moved the gut of nsDateTimeControlFrame::HasBadInput() to
DateTimeInputTypeBase::HasBadInput(). Content script should be allowed to validate
the input without the frame.
Sadly this means the XBL implementation and the UA Widget implementation
have further diverged. The complexity should go away when we could finally
remove the XBL implementation.
nsDateTimeControlFrame still dispatches a few events to UA Widget, in
AttributeChanged() and SyncDisabledState(), as they are originated from the layout.
The name of the events in AttributeChanged() are incorrect though -- I am correcting
that in this patch too.
Differential Revision: https://phabricator.services.mozilla.com/D15601
--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.
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
We use a bitfield in HTMLInputElement to cache whether the input element has the
@pattern set, and skip pattern mathching in HasPatternMismatch() if the
attribute is not set.
--HG--
extra : rebase_source : 797deb99bfee31bda824c809052083b66d62fd7c
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
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.
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
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
