Otherwise the user can select, but if you're in an iframe the iframe won't be
correctly focused.
This also matches other browsers, see:
data:text/html,<input autofocus><input disabled value=abc>
data:text/html,<input autofocus><button disabled>Foo</button>
And so on. This effectively undoes bug 375008. We could make this more targeted
somehow, but I don't think it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D67597
--HG--
extra : moz-landing-system : lando
Set the flag on the affected classes, which are:
- CallbackTimeoutHandler
- nsJSArgArray
- CallbackObject
- Console
- MessageEvent
- IDBIndexCursor
- ExtendableMessageEvent
- JSPurpleBuffer
Differential Revision: https://phabricator.services.mozilla.com/D68196
--HG--
extra : moz-landing-system : lando
Converts dom.w3c_pointer_events.implicit_capture to a static pref, removes the initializer in PointerEventHandler.
Differential Revision: https://phabricator.services.mozilla.com/D67204
--HG--
extra : moz-landing-system : lando
Converts `intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition` to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D67203
--HG--
extra : moz-landing-system : lando
Converts dom.datatransfer.mozAtAPIs to a static pref and adds the `do_not_use_directly` field, since the pref is used in combination with an additional check in `DataTransfer::MozAtAPIsEnabled`.
Differential Revision: https://phabricator.services.mozilla.com/D67202
--HG--
extra : moz-landing-system : lando
Converts dom.events.testing.asyncClipboard to a static pref. In its original usage, it called a getter that also added information to the log. This uses the do_not_use_directly field to indicate that the getter should still be used for logging.
Differential Revision: https://phabricator.services.mozilla.com/D67186
--HG--
extra : moz-landing-system : lando
Since we cannot use HTMLInputElement.GetInputMode since we still support
mozAwesomebar, inputmode attribute isn't sanitized. Since I would like to reduce
comparing cost, it should be lower case except to mozAwesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D67770
--HG--
extra : moz-landing-system : lando
Since we cannot use HTMLInputElement.GetInputMode since we still support
mozAwesomebar, inputmode attribute isn't sanitized. Since I would like to reduce
comparing cost, it should be lower case except to mozAwesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D67770
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
Converts dom.w3c_pointer_events.implicit_capture to a static pref, removes the initializer in PointerEventHandler.
Differential Revision: https://phabricator.services.mozilla.com/D67204
--HG--
extra : moz-landing-system : lando
Converts `intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition` to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D67203
--HG--
extra : moz-landing-system : lando
Converts dom.datatransfer.mozAtAPIs to a static pref and adds the `do_not_use_directly` field, since the pref is used in combination with an additional check in `DataTransfer::MozAtAPIsEnabled`.
Differential Revision: https://phabricator.services.mozilla.com/D67202
--HG--
extra : moz-landing-system : lando
Converts dom.events.testing.asyncClipboard to a static pref. In its original usage, it called a getter that also added information to the log. This uses the do_not_use_directly field to indicate that the getter should still be used for logging.
Differential Revision: https://phabricator.services.mozilla.com/D67186
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
The patch adds similar to mousemove compression on IPC layer.
https://searchfox.org/mozilla-central/rev/49ed791eec93335abfe6c2880f84c324e73e47e6/dom/ipc/PBrowser.ipdl#764-774
Touch events can't be compressed all the time, because each touch event
may contain changes to several touches.
To disable compression in some cases, another IPC message is sent.
The messages have exactly the same arguments, but by changing the message type,
compression is disabled for that message on IPC layer.
The patch tries to take rather conservative approach by disabling compression
in many cases. Compression is enabled only if the same touches are being changed,
or old touches and some new touch are changed (so the changed touches are a superset of the old touches).
The patch does not do anything with PointerEvent.getCoalescedEvents(). That implementation
would be quite a bit different and riskier for the next coming Fenix release.
Differential Revision: https://phabricator.services.mozilla.com/D63261
--HG--
extra : moz-landing-system : lando
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
--HG--
extra : moz-landing-system : lando
`InputEventOptions` should be able to take target ranges for `beforeinput`
event. However, it requires to include `StaticRange.h` from `nsContentUtils.h`
even though most `nsContentUtils.h` users don't need it. Therefore, this patch
moves it from `nsContentUtils.h` to new header file.
And makes `nsContentUtils::DispatchInputEvent()` moves the target ranges
from `InputEventOptions` to `InternalEditorInputEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D64729
--HG--
extra : moz-landing-system : lando
`InputEvent.getTargetRanges()` can be used only when event type is
`beforeinput`. So, it may be used for feature detection of `beforeinput`
event because Chrome does not implement `onbeforeinput` event handler attribute.
Therefore, this patch makes it behind the pref for `beforeinput` event.
Differential Revision: https://phabricator.services.mozilla.com/D64728
--HG--
extra : moz-landing-system : lando
It's a testcase for Office Online Server duplicated from `test_bug1514940.html`.
The original test listens to `CheckKeyPressEventModel` event which is fired
when the `keypress` event model is changed from the default mode. Therefore,
this test also needs to listen to the event for avoiding intermittent failure
which is caused by running the tests before the mode change.
However, unfortunately, for keeping the performance of web apps which don't
need our mode changes, we can check the event only on debug build. Therefore,
this patch makes the test run only on debug build.
Finally, this patch renames `test_bug154940.html` too because it tests
special behavior on specific web app and the new test name explains it like
the test for Office Online Server.
Differential Revision: https://phabricator.services.mozilla.com/D64919
--HG--
rename : dom/events/test/test_bug1514940.html => dom/events/test/test_use_split_keypress_event_model_on_old_Confluence.html
extra : moz-landing-system : lando