Split the class inheritance trees for nsIDragService and nsIDragSession.
Remember that, before the start of this patch series, the inheritance
diagram was:
nsDragService -> nsBaseDragService -> nsIDragService + nsIDragSession
and the only instance was a singleton. We switched it to:
nsDragService -> nsDragSession -> nsBaseDragService -> nsIDragService + nsBaseDragSession -> nsIDragSession
and maintained the singleton. This allowed us to allow us to move things to
the new classes without breaking behavior. We are done with that,
so we can now change the inheritance to its final form:
nsDragService -> nsBaseDragService -> nsIDragService
nsDragSession -> nsBaseDragSession -> nsIDragSession
Of course, we also need to properly construct and release the
nsIDragSessions (formerly part of the singleton), so that is done here as
well. That happens in nsBaseDrag[Service|Session] for parent process drags
and in nsDrag[Service|Session]Proxy for content. This is all fairly
straightforward, except in the case of gtk, where we need to change
some callback behavior.
Differential Revision: https://phabricator.services.mozilla.com/D211084
This is a straightforward move. It does take the liberty of breaking out an
EndDragSessionImpl method, which will be needed later.
Differential Revision: https://phabricator.services.mozilla.com/D211083
Content process callers must call nsIDragService::GetCurrentSession with the
correct widget under the drag. For all callers, it is a sanity check.
Differential Revision: https://phabricator.services.mozilla.com/D211065
This comes back to bug 42557 and co. It only does something
half-reasonable on Windows (on macOS we just lie and make z-order
tracking be latest-active tracking), and given we don't use the special
zorder flags elsewhere I'm pretty sure we should be able to just rip
this off... On some DEs like Wayland we can't re-stack toplevel windows.
Differential Revision: https://phabricator.services.mozilla.com/D213602
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
When using mouse on GeckoView, dblclick event isn't fired. Android doesn't
have a state of double click for mouse, so we have to emulate it like
Windows widget.
The default of timeout values are from android.view.GestureDetector's double
tap.
Differential Revision: https://phabricator.services.mozilla.com/D209654
When the Android frontend attempts to pause or resume the compositor
there is a chance this may fail. When this happens, the compositor
will automatically be reinitialized. However, it will currently be
reinitialized in the previous state, not the state the frontend
intended. For example, if the compositor fails to resume then it will
be reinitialized but remain in a paused state, displaying a blank
screen to the user.
To avoid this, we update the value of mCompositorPaused prior to
attempting to pause or resume the compositor. This means when
NotifyCompositorCreated eventually gets called, it knows the correct
state in which to initialize the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D202165
When the Android frontend attempts to pause or resume the compositor
there is a chance this may fail. When this happens, the compositor
will automatically be reinitialized. However, it will currently be
reinitialized in the previous state, not the state the frontend
intended. For example, if the compositor fails to resume then it will
be reinitialized but remain in a paused state, displaying a blank
screen to the user.
To avoid this, we update the value of mCompositorPaused prior to
attempting to pause or resume the compositor. This means when
NotifyCompositorCreated eventually gets called, it knows the correct
state in which to initialize the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D202165
When the Android frontend attempts to pause or resume the compositor
there is a chance this may fail. When this happens, the compositor
will automatically be reinitialized. However, it will currently be
reinitialized in the previous state, not the state the frontend
intended. For example, if the compositor fails to resume then it will
be reinitialized but remain in a paused state, displaying a blank
screen to the user.
To avoid this, we update the value of mCompositorPaused prior to
attempting to pause or resume the compositor. This means when
NotifyCompositorCreated eventually gets called, it knows the correct
state in which to initialize the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D202165
Android's drag and drop API will set a dropped item on `drop` event. But other
platforms will be set during `dragstart` event.
Editor's drag and drop event listener checks current dropped item on some
events such as `dragover` event in
`EditorEventListener::DragEventHasSupportingData`. Since there is no way to
set dropped item on `dragover` event, GeckoView will set temporary dropped
item with MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D200618
This implementation supports
- HTML drag & drop API.
- Drop and drop for text/plain or text/html from/to external application.
Differential Revision: https://phabricator.services.mozilla.com/D197330
Remove `nsIWidget::SetNativeData()` and all implementations thereof, as
none of them have had any functionality or use since bug 1338172.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D177568
We see a fair number of crashes caused by failing to create an EGL
surface when resuming the compositor on Android. We believe that in
the vast majority of these cases the Surface we have been provided by
the OS is in an invalid state, and therefore we will never succeed in
creating an EGL surface from it.
Currently when creating the EGL surface fails we raise a NEW_SURFACE
webrender error. This causes us to fall back through webrender
configurations, reinitialize the compositors, and eventually crash
when we are still unable to resume. None of this will help when the
Android Surface we have been provided is in this invalid state.
This patch therefore avoids raising the webrender error initially, and
instead gives the widget an opportunity to handle the failure. The
widget uses the new GeckoView API added in the previous patch in this
series to request a new Surface from the application. This will cause
another resume event immediately afterwards with a new - and hopefully
valid - surface, allowing the EGL surface to be created and the
compositor to be successfully resumed. If we are still unable to
create an EGL surface after this, then we will raise the webrender
error as before, likely eventually resulting in a crash.
Differential Revision: https://phabricator.services.mozilla.com/D176721
The detection is inadequate and the workaround does not work on all
versions of Android. Later patches in this series will replace this
with something better.
Differential Revision: https://phabricator.services.mozilla.com/D176719
We see a fair number of crashes caused by failing to create an EGL
surface when resuming the compositor on Android. We believe that in
the vast majority of these cases the Surface we have been provided by
the OS is in an invalid state, and therefore we will never succeed in
creating an EGL surface from it.
Currently when creating the EGL surface fails we raise a NEW_SURFACE
webrender error. This causes us to fall back through webrender
configurations, reinitialize the compositors, and eventually crash
when we are still unable to resume. None of this will help when the
Android Surface we have been provided is in this invalid state.
This patch therefore avoids raising the webrender error initially, and
instead gives the widget an opportunity to handle the failure. The
widget uses the new GeckoView API added in the previous patch in this
series to request a new Surface from the application. This will cause
another resume event immediately afterwards with a new - and hopefully
valid - surface, allowing the EGL surface to be created and the
compositor to be successfully resumed. If we are still unable to
create an EGL surface after this, then we will raise the webrender
error as before, likely eventually resulting in a crash.
Differential Revision: https://phabricator.services.mozilla.com/D176721
The detection is inadequate and the workaround does not work on all
versions of Android. Later patches in this series will replace this
with something better.
Differential Revision: https://phabricator.services.mozilla.com/D176719
Although `GeckoViewSupport::Transfer` will re-attach `SessionAccessibility`,
it doesn't wait for previous `SessionAccessibility` is disposed completely
since `SessionAccessibility::OnWeakNonIntrusiveDetach` makes tasks only.
When worst case,
1. Create a task for calling SessionAccessilibity::SetAttached(false) on Android UI thread.
2. Create a task for calling SessionAccessilibity::SetAttached(true) on Android UI thread.
3. Attach new JNI object to SeessionAccessibility
4. Run 1's task on Android UI thread, then create a task for disposing JNI object on Gecko thread.
5. Run 2's task on Android UI thread.
6. Run 4's task on Gecko thread. JNI object is detached incorrectly if JNI object is recycled.
If reattaching same JNI object, we detach new object unfortunately. Since I add
MozPromise By Part 1, we can wait for it to use this API.
Depends on D175335
Differential Revision: https://phabricator.services.mozilla.com/D175336
Actually, `NativeWeakPtr::Detach` may not release JNI ojbect immediately because
it depends on JNI object's `OnWeakNonIntrusiveDetach`i implementation.
`SessionAccessibility`'s `OnWeakNonIntrusiveDetach` implementation uses the
runnable to run on Android UI thread then disposer runs on main thread, so
if Detach is finished, JNI object isn't detached yet.
If calling `NativeWeakPtrHolder::Attach` immediately with same/recycled Java
object after `NettiveWeakPtr::Detach`, it is possible to run disposer for JNI
object by `OnWeakNonIntrusiveDetach` after Attach is finished. So it may
release newer attached object unfortunately.
So I would like to add a way to waiting for detach JNI object using
`MozPromise`.
Also, `MozPromise.h` includes `Natives.h` header (for `GeckoResult` support).
So I cannot modify inline method to use `MozPromise` due to recursive. So I
split implementation with `NativesInlines.h` as workaround.
Differential Revision: https://phabricator.services.mozilla.com/D175335
If an issue occurs when generating the PDF stream, we should be able to
send an error. The prior function (SendError()) was for stream readers
to use. The error state here can occur during writing.
Created a WriteError() option to set an error state that will cause
an IOException when reading to indicate the stream is in an inconclusive
state and to stop reading from it.
Differential Revision: https://phabricator.services.mozilla.com/D175918
`HandleMotionEvent` have a race condition of destroying `nsWindow` (in Gecko
main thread) and dispatching touch event (Android UI thread). When destroying
the window, it can accept motion event.
So we should check whether window is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D174390
This bug implements and opens window.print() for Android in Nightly.
Adds "GeckoView:DotPrintRequest" and "GeckoView:DotPrintFinish" events.
GeckoView:DotPrintRequest requests a PDF of the current window.print
page for Android to print. GeckoView:DotPrintFinish releases the static
browser clone created by window.print. PDF generation was additionally
adjusted to get the expected canonical browser context when printing
iframes.
Differential Revision: https://phabricator.services.mozilla.com/D171159
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
APZ now ensures that GetHandledResult() is Unhandled when appropriate,
so the widget code doesn't need to special-case eIgnore any more.
Differential Revision: https://phabricator.services.mozilla.com/D164585
This effectively backs out the fix for bug 1746336, while keeping the test
added in that bug (PanZoomControllerTest#touchActionWithWheelListener)
passing using a different fix approach (remembering the eager status
and using it in the computation of the delayed result).
Differential Revision: https://phabricator.services.mozilla.com/D164114
Hiroyuki Ikezoe