This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
This patch add a way to track remote target for mouse capturing. The tracking
remote target will be reset when capturing content is changed or
ReleaseCapturingContent() is called.
In order to make `mouseup` would also be dispatched to correct remote target, we
do ReleaseCapturingContent in EventSetateManager::PostHandleEvent, instead of
in nsIFrame::HandleRelease.
Differential Revision: https://phabricator.services.mozilla.com/D98592
Resetting focus would also clear selection on editable element, so get
current selected text before moving focus to findbar to make
prefill-with-selection work if the content is loaded in chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D89557
This passes the tests which are in https://github.com/web-platform-tests/wpt/pull/26472
Because of complications in #include handling, AbortFollower needs to be in a different
header file than AbortSignal, yet AbortSignalImpl needs to be available when AbortFollower is used.
Another option would have been to make DOMEventTargetHelper.h a bit different and uninline some hot methods
there or move them to another file, but that would have been equally bad and Abort* is used way less often.
AbortFollower and AbortSignalImpl are thus just moved to a new header.
Memory management is such that Listener in EventListenerManager owns the possible ListenerSignalFollower
instance which follows the relevant signal. In order to be able remove event listener,
ListenerSignalFollower has many similar fields as Listener.
ListenerSignalFollower can't easily have just a pointer to Listener* since Listener isn't stored as a pointer
in EventListenerManager.
ListenerSignalFollower is cycle collectable so that Listener->ListenerSignalFollower can be traversed/unlinked
and also strong pointers in ListenerSignalFollower itself can be traversed/unlinked.
There is an XXX in the .webidl, since nullability of signal is unclear in the spec pr.
Whether or not it ends up being nullable shouldn't change the actual C++ implementation.
Differential Revision: https://phabricator.services.mozilla.com/D97938
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
This is another regression by bug 1658948 and Windows only.
When user script calls element.focus() during keyboard event, our TSF client
implementation commits composition string.
It is unnecessary to call SetInputContext when real keybaord event is fired.
Because,
- If keybaord event is fired, virtual keybaord is already shown
- We don't open virtual keyboard when physical keyboard is available on Android
So I shouldn't call SetInputContext on user interaction by keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D98882
mLastOverFrame is a WeakFrame, it could possibly be nulled-out, for example
after restyling, and the sub-document won't be able to be notified the mouse
leaving.
Differential Revision: https://phabricator.services.mozilla.com/D98787
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
Usually, IME sets selection and considers candidate list position at starting
new composition. However, Apple Japanese IME sometimes consider the candidate
list position at retrieving the character rects before setting selection.
Therefore, we need to store last commit string's character rects, but don't
need to store it in long time because Kakutei-Undo is supported by Japanese
IMEs and they work only immediately after committing a composition. E.g.,
after moving caret, it won't be available.
Depends on D97838
Differential Revision: https://phabricator.services.mozilla.com/D97839
`IMEStateManager::OnFocusMovedBetweenBrowsers()` is called by
`BrowserParent::UnsetTopLevelWebFocusAll()` from
`nsFocusManager::WindowRaised()` when a window becomes active from the app
itself is deactivated. At this time, `aBlur` is set to the last
`BrowserParent` which had focus before inactivated, and `aFocus` is always
`nullptr` because of assuming the following code in
`nsFocusManager::WindowRised()` will call `OnFocusMovedBetweenBrowsers()` to
set focus to focused browser part at that time. However, the first call of
`OnFocusMovedBetweenBrowsers()` requesting to commit composition if there is
a composition because it believes that the focused process is just blurred and
nobody would take focus.
So, `IMEStateManager::OnFocusMovedBetweenBrowsers()` needs to wait to handle
its jobs until another its call for setting focus to the remote process when
the app is activated.
Therefore, this patch makes `IMEStateManager` manage whether the process is
active or not from the point of view of IME handling. I.e., in the main
process, it can be treated as active when a window is the focused window in
the desktop, and in a content process, it can be treated as active when the
process has focus. So, this is managed by `sIsActive`.
Then, `IMEStateManager` needs information of first blurred `BrowserParent`
and `last focused `BrowserParent` in the case for putting off to handle its
jobs. Therefore, this patch adds
`IMEStateManager::sPendingFocusedBrowserSwitchingData` to manage them.
Finally, this patch makes `IMEStateManager::OnFocusMovedBetweenBrowsers()`
cancel pending handling if first blurred `BrowserParent` and last focused
`RrowserParent`are same. And also making
`IMEStateManager::OnFocusChangeInternal()` call `OnFocusMoveBetweenBrowsers()`
if there is pending jobs of `OnFocusMoveBetweenBrowsers()`.
UThis requires an API to create the case to all windows deactive to test it.
However, there is no way to do that. Therefore, this patch does not have
any tests.
Differential Revision: https://phabricator.services.mozilla.com/D97687
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
for consistency with ErrorResult and dom::Promise, which will mean no reverse
conversion is required for rejecting Promises.
Differential Revision: https://phabricator.services.mozilla.com/D95967
The spec text has been improved a while ago, so I think we should do
this. This keeps the current moz-focusring behavior when the pref is
disabled, but when enabled it becomes effectively an alias of
focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D96697
Software keyboard is shown by user interaction. But `change` event by
`element.click()` becomes user interaction event by bug 1543439 even if
it is called by script.
Since `change` event can be fired by click() method, we shouldn't be
that it is always user interaction.
Also, we have setUserInput that is chrome API to emulate user input. It
should be defined as user interaction.
Differential Revision: https://phabricator.services.mozilla.com/D95818
Bogdan Tara
Steven MacLeod
Razvan Maries
Edgar Chen
Olli Pettay
Dorel Luca
Emilio Cobos Álvarez
Simon Giesecke
Makoto Kato
Henri Sivonen
Kagami Sascha Rosylight
Masayuki Nakano
Tom Schuster
Csoregi Natalia
Markus Stange
David Parks
Sylvestre Ledru
Gerald Squelart
Mihai Alexandru Michis
Karl Tomlinson
Tim Huang