Actually, APZ's zoomToRect doens't support position: fixed content. If so,
we use PresShell's scrollIntoView instead to scroll focused content if it
isn't visible.
Differential Revision: https://phabricator.services.mozilla.com/D117728
On a long press touch event we fire a contextmenu event and if the contextmenu
is opening, we fire a touchcancel event. Unfortunately we had been checking
the return value, nsEventStatus, from nsIWidget::DispatchInputEvent via
nsContentUtils::SendMouseEvent to tell whether the context menu is opening or
not. So, we unintentionally fire the touchcancel event if the context menu is
NOT going to be opened because of preventDefault() in a contextmenu event
listener in the content itself.
NOTE: The oparator<< for the new PreventDefaultResult enum will be used in
APZ logging code.
[1] https://searchfox.org/mozilla-central/rev/95c41d54c3fd65d51976d5188842a69b459a7589/mobile/android/actors/ContentDelegateChild.jsm#100
Differential Revision: https://phabricator.services.mozilla.com/D115963
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
Warn when some of the pre-conditions fail and such, so that it's easy to
see what's going wrong without having to use a debugger.
Remove some useless null-checks (we were dealing with null arguments
anyways, and the return value is never null).
Depends on D114078
Differential Revision: https://phabricator.services.mozilla.com/D114079
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
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
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
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
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
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
OneShotPostRefreshObserver works as the caller registers it, and
let it deletes itself via the DidRefresh method. The issue is that
DidRefresh is not guaranteed to run, and it'll leak PresShell
if it doesn't run.
This patch allows nsPresContext to store and release the last
registered OneShotPostRefreshObserver, and converted the existing
usage of OneShotPostRefreshObserver to use that. So instead of asking
OneShotPostRefreshObserver to delete itself, we now ask nsPresContext
to release it.
Differential Revision: https://phabricator.services.mozilla.com/D99939
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
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
When show virtual keyboard, we calls ZoomToFocusedInput to scroll to focused
element. But this method only consider single line control. It means that this
doesn't scroll better position when focused element is multiple such as
content editable. Because we use element rectangle foo zoom to rect.
So I would like to change this for <textarea> and contenteditable.
If <textarea> or contenteditable, we should use caret frame to scroll to
better position.
Differential Revision: https://phabricator.services.mozilla.com/D96374
This is a best-effort thing of course, but so is the rest of the
visibility threshold stuff in practice and this should be good enough.
Differential Revision: https://phabricator.services.mozilla.com/D98360
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
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
