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
Refactor dmabuf buffer mapping, warn when we're mapping buffer with modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D59676
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
With this change we have the same setup for prefers-reduced-motion so that
we can change the value with the same manner in automated tests.
Differential Revision: https://phabricator.services.mozilla.com/D59023
--HG--
extra : moz-landing-system : lando
Now both of GTK and MacOSX backends use the same machinery, LookAndFeelInt, for
prefers-reduced-motion. And we are going to use it on Android as well so it'd
make sense to move the code into there.
On Windows we can also use the same LookAndFeelInt machinery and probably
all we have to do is to call SendNotifyMessage with SPI_SETCLIENTAREAANIMATION
in SetPrefersReducedMotionOverrideForTest.
Differential Revision: https://phabricator.services.mozilla.com/D59022
--HG--
extra : moz-landing-system : lando
With this change we have the same setup for prefers-reduced-motion so that
we can change the value with the same manner in automated tests.
Differential Revision: https://phabricator.services.mozilla.com/D59023
--HG--
extra : moz-landing-system : lando
Now both of GTK and MacOSX backends use the same machinery, LookAndFeelInt, for
prefers-reduced-motion. And we are going to use it on Android as well so it'd
make sense to move the code into there.
On Windows we can also use the same LookAndFeelInt machinery and probably
all we have to do is to call SendNotifyMessage with SPI_SETCLIENTAREAANIMATION
in SetPrefersReducedMotionOverrideForTest.
Differential Revision: https://phabricator.services.mozilla.com/D59022
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
This patch makes `nsContentUtils::DispatchInputEvent()` dispatch `beforeinput`
event too. And also adds `onbeforeinput` event handler which is really
important for feature detection (although Chrome has not implemented this
attribute yet: https://bugs.chromium.org/p/chromium/issues/detail?id=947408).
However, we don't implement `InputEvent.getTargetRanges()` in this bug and
implementing `beforeinput` event may hit bugs of some web apps. Therefore,
this patch disables `beforeinput` event by default even in Nightly channel.
Differential Revision: https://phabricator.services.mozilla.com/D58125
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
GCC warns about it and it's right. There's code null-checking the return value
of this function, so we should either initialize it or assert it's never null.
Depends on D59648
Differential Revision: https://phabricator.services.mozilla.com/D59649
--HG--
extra : moz-landing-system : lando
We need to enable dmabuf backend for textures and webgl backend independently.
There's no gain from dmabuf texture backend right now but it brings performance improvements
as WebGL framebuffer.
Depends on D59485
Differential Revision: https://phabricator.services.mozilla.com/D59486
--HG--
extra : moz-landing-system : lando
CompositorWidgetChild is about to be responsible for creating,
destroying, and presenting a shared buffer that CompositorWidgetParent
will draw into. To do this, it will need the window handle,
transparency mode changes, window size changes, and window size mode
changes.
Its creation is also about to become fallible, so it needs a separate
initialization routine.
Differential Revision: https://phabricator.services.mozilla.com/D57430
--HG--
extra : moz-landing-system : lando
This is useful if you get a certificate-related error and want
to inspect the broken certificate.
Differential Revision: https://phabricator.services.mozilla.com/D58170
--HG--
extra : moz-landing-system : lando
This is the server certificate, if any, as a
java.security.cert.X509Certificate.
Differential Revision: https://phabricator.services.mozilla.com/D58156
--HG--
extra : moz-landing-system : lando
Since `XPCOMEventTarget` uses JNI, this patch makes it possible for consumers to
retrieve and invoke methods on one without needing to worry about whether JNI
is actually up yet.
To achieve this, we create the `IXPCOMEventTarget` interface, and observe that
both of its methods can be handled by a proxy if JNI is not ready:
* Calls to `dispatch` may be enqueued until JNI is up;
* Observe that, when JNI is not up yet, the result of `isOnCurrentThread`
can never be `true`.
Once JNI is up and the event targets have been resolved, the proxies are
replaced with the real, concrete `XPCOMEventTarget`s and are no longer used for
the remainder of the Gecko instance's lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D57837
--HG--
extra : moz-landing-system : lando
PlatformCompositorWidgetDelegate was meant to be a pure virtual base
class for all the functions that nsWindow could call that would
either go to an in-process compositor widget or an OMTC widget.
By that definition, it does not seem like CompositorWidgetParent should
be a subclass, since nsWindow cannot directly call its methods and
currently CompositorWidgetParent has several "do nothing"
implementations of the interface methods because they don't really
belong.
This changeset remedies this by refactoring CompositorWidgetParent so
it is no longer an implementor of PlatformCompositorWidgetDelegate. Now
the only implementors are CompositorWidgetChild and InProcessWin-
CompositorWidget, which makes sense because they are both directly
called through the nsWindow delegate.
It also eliminates some of the methods that seem like they don't belong
in PlatformCompositorWidgetDelegate.
Differential Revision: https://phabricator.services.mozilla.com/D57429
--HG--
extra : moz-landing-system : lando
This looks like a large change, but it's really just moving stuff
around.
It takes the logic in WinCompositorWidget and duplicates it into
its only 2 subclasses: InProcessWinCompositorWidget and
CompositorWidgetParent.
This is because CompositorWidgetParent is about to change *a lot*, but
InProcessWinCompositorWidget will basically stay the same. This is an
easy way to verify that I don't accidently break
InProcessWinCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D57428
--HG--
extra : moz-landing-system : lando
Using LookAndFeelInt to query system colors is awkward, it's normally used for
eIntID_XX values.
Differential Revision: https://phabricator.services.mozilla.com/D58744
--HG--
extra : moz-landing-system : lando
Once we start supporting different model IDs for different windows of the same
application we need to make sure that the normal windows have a model ID and
the jump lists and recent documents are tagged with the same ID. We do this by
always having an app default model ID, when no window specific model ID is set
the app default is used.
At some point we may want to extend the jump list stuff to support using a
different model ID but that isn't needed right now.
Differential Revision: https://phabricator.services.mozilla.com/D57152
--HG--
extra : moz-landing-system : lando
I did some cleanup while here: This now uses the callback's lParam
instead of a global, and does the enumeration of all windows only if
the foreground window doesn't already belong to this process (which
was proposed in bug 259816 comment 68 but didn't make it into the patch).
Differential Revision: https://phabricator.services.mozilla.com/D57922
--HG--
extra : moz-landing-system : lando
nsWindow::UpdateOpaqueRegion() is used from Main thread and it collides with
moz_container_get_wl_surface() where opaque region is used and which is called from Compositor thread.
As a fix don't set opaque region directly for mozcontainer but rather just use a flag to signalize
there's an update needed and calculare/set the opaque region at moz_container_get_wl_surface() or
moz_container_egl_window_set_size().
Differential Revision: https://phabricator.services.mozilla.com/D58840
--HG--
extra : moz-landing-system : lando
This looks like a large change, but it's really just moving stuff
around.
It takes the logic in WinCompositorWidget and duplicates it into
its only 2 subclasses: InProcessWinCompositorWidget and
CompositorWidgetParent.
This is because CompositorWidgetParent is about to change *a lot*, but
InProcessWinCompositorWidget will basically stay the same. This is an
easy way to verify that I don't accidently break
InProcessWinCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D57428
--HG--
extra : moz-landing-system : lando
The idle-inhibit protocol allows idle wake locks on Wayland
without any of the supported D-Bus interfaces running.
Differential Revision: https://phabricator.services.mozilla.com/D49095
--HG--
extra : moz-landing-system : lando
