No behavior change, since `GetLastFocusMethod` is only checked by `HTMLInputElement.cpp` / `nsGlobalWindowInner.cpp` for FLAG_BYKEY, and some JS code for `FLAG_BYMOUSE`.
But this makes the next patch more straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D115900
CLOSED TREE
Backed out changeset 61d8ca98120b (bug 1712724)
Backed out changeset 46b1d60b6b6b (bug 1712724)
Backed out changeset 36504d508b34 (bug 1712724)
No behavior change, since `GetLastFocusMethod` is only checked by `HTMLInputElement.cpp` / `nsGlobalWindowInner.cpp` for FLAG_BYKEY, and some JS code for `FLAG_BYMOUSE`.
But this makes the next patch more straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D115900
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
For inserting text from OS in special cases, e.g., when inserting 2 or more characters
per keydown or inserting text without key press, we use a set of composition events on
macOS, but the other browsers don't use composition events. Instead, they expose only
`beforeinput` event and `input` event. We should follow their behavior for web-compat
because `beforeinput` events for IME composition are never cancelable, but the
`beforeinput` events for the cases are cancelable of the other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D114826
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
Creating an event with type NSEventTypeSmartMagnify does not work with either NSEvent mouseEventWithType or NSEvent otherEventWithType (they both hit an assert in the appkit code). So the best we can do is call the same function.
Differential Revision: https://phabricator.services.mozilla.com/D107792
Previously, we would only send web progress events from the toplevel
BrowserParent, as other frames would never have the browser-child.js framescript
loaded in them, and so would never start sending events. This change moves the
decision to begin sending events into BrowserChild itself around the same time
as it would've happened previously with the framescript.
This new callsite should still avoid sending events for the creation of the
initial about:blank document in the BrowserChild, while not skipping any other
events, as before.
Differential Revision: https://phabricator.services.mozilla.com/D105558
This patch is plumbing to get a path and a flags word through from the content
process to the graphics process, to pass to `wr_api_start_capture_sequence`.
Differential Revision: https://phabricator.services.mozilla.com/D106229
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
Now, there are no users of this API. However,
`nsIWidget::SynthesizeNativeMouseMove()` is still used by `EventStateManager`.
Even though it's just redirected to `nsIWidget::SynthesizeNativeMouseEvent()`,
but it hides the native event message from `EventStateManager`. Therefore,
this patch keeps the widget API for now.
Differential Revision: https://phabricator.services.mozilla.com/D105762
Surprisingly, they don't take modifiers, and
`nsIWidget::SynthesizeNativeMouseEvent()` which are implementations of
`nsIDOMWindowUtils::SendNativeMouseEvent()` treat given modifier flags
are native's ones, and handle modifiers only on macOS. Therefore, this
patch makes them handle native modifiers of Gecko.
Unfortunately, I'm not so familiar with Android API, and in the short
term, I don't need the support on Android. Therefore, this patch just
adds a TODO comment on Android widget.
Additionally, we don't have a simple way to set modifier only while
posting a mouse input on Windows too. It requires complicated code.
Therefore, I don't add the support for it on Windows too.
Differential Revision: https://phabricator.services.mozilla.com/D105758
In OOP iframes, we don't have desktop zoom value specifically in each iframe
documents, instead we have a transform matrix,
nsIWidget::WidgetToTopLevelWidgetTransform(), on each the __top__ level OOP
iframe document that the matrix includes the desktop zoom scale value along with
translations by ancestor scroll containers, ancestor CSS transforms, etc.
Note that if the document is not in OOP iframes, i.e. it's in the top level
content subtree, the transform, nsIWidget::WidgetToTopLevelWidgetTransform()
doesn't include the destktop zoom value, so for documents in the top level
content document subtree, ViewportUtils::DocumentRelativeLayoutToVisual applies
the desktop zoom value via PresShell::GetResolution().
Differential Revision: https://phabricator.services.mozilla.com/D102219
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
We only use the contentBlockingAllowListPrincipal for excluding sites from content
blocking for top level documents. We don't need it in the content process and should
not compute it for every document.
Differential Revision: https://phabricator.services.mozilla.com/D100781
Currently, they are never focusable when its type is "plugin".
So, making stop them returning `IMEEnabled::Plugin` won't change
anything, but it guarantees that nobody will see `IMEEnabled::Plugin`
at runtime. This is a preparation for the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D100101
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
