The UTC time was generating incorrect months when the browser was used in a timezone that has a negative UTC offset. The value returned from Date.UTC was then parsed by new Date() which was converted to the local timezone. Date.UTC(1970, 0, 1) would return a time of 0 which would then become December 1969.
Differential Revision: https://phabricator.services.mozilla.com/D13879
--HG--
extra : moz-landing-system : lando
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
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
It's difficult to create new test which checks "input" events caused by
all edit operations especially when text is inserted from our UI. Therefore,
this adds "input" event type checks into existing tests.
Additionally, this adds new test for MozEditableElement.setUserInput() whose
behavior needs to be fixed in this bug.
Currently, InputEvent interface should be used only on text controls or
contenteditable editor when dispatching "input" event.
https://w3c.github.io/input-events/#events-inputevents
You may feel odd to use different event interface for same "input" events.
However, other browsers also use InputEvent interface only in the cases. So,
we should follow them for now.
Differential Revision: https://phabricator.services.mozilla.com/D12243
--HG--
extra : moz-landing-system : lando
This makes it possible to navigate by headings when using accessibility technology.
Information labels displayed when removing the master password are also restored.
Differential Revision: https://phabricator.services.mozilla.com/D11792
--HG--
extra : rebase_source : 42f156dbccf074445cf7e08d8de246058437c91b
Currently the "PDFJS:Child:handleEvent" message listener isn't removed when the `FindEventManager` is unloaded.
If the user re-loads the current (PDF) document, using e.g. the F5 key, the old message listener will thus persist, causing subsequent find event to be handled more than once. This is quite bad, since it causes one (or more) matches to be skipped over when the user attempts to search after re-loading the document.
This patch restores the re-auth test pref previously comment out,
and redirect the re-auth to nsIOSReauthenticator on Windows and macOS.
Noted that nsIOSReauthenticator is never called during tests because we can't automate that dialog.
Differential Revision: https://phabricator.services.mozilla.com/D9853
--HG--
extra : moz-landing-system : lando