Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--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
This patch converts datetimebox.xml to datetimebox.js and loads it as a UA Widget,
while touches things here and there to make it work.
In HTMLInputElement manages the lifecycle of the datetimebox UA Widget.
It is loaded when in <input> has type date or time, or have its type switch to date or time.
nsDateTimeControlFrame is changed so that when UA Widget is enabled,
it would not generate <xul:datetimebox>.
Like bug 1483972, a check is added in nsCSSFrameConstructor::CreateGeneratedContentItem()
to make sure we don't generate pseudo content inside <input>.
Assertions in IntlUtils is changed to allow UAWidget to call the methods.
Depends on D9056
Differential Revision: https://phabricator.services.mozilla.com/D9057
--HG--
rename : toolkit/content/widgets/datetimebox.xml => toolkit/content/widgets/datetimebox.js
extra : moz-landing-system : lando
This patch simplifies the nsIDateTimeInputArea interface, implemented by the
datetimebox bindings, to a point that is easier to convert it to dispatch events,
by doing the following:
- hasBadInput() is re-implemented in C++ in nsIDateTimeControlFrame since
C++ needs the return value synchronously.
- SetValueFromPicker() and SetPickerState() are avoided completed since they
are simply called by HTMLInputElement methods exposed to the frame
script. They are avoided by having the frame script access the NAC and call
the nsIDateTimeInputArea methods directly.
- Merge setEditAttribute() and removeEditAttribute() to updateEditAttributes()
which takes no arguments, and have the method access the attribute values by
reading the values from <input>.
This patch is a scaled-down version of the patch proposed in bug 1456833.
The event approach is only usable in UA Widget version of datetimebox because
there is no way to avoid leaking events to the document without Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D9056
--HG--
extra : moz-landing-system : lando
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
(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
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