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
On Android when SWGL is enabled, occasionally when switching tabs it
refuses to render the new tab. The user will instead be left with the
contents of the previous tab, or if they have just switched to firefox
they will be left with a black screen.
This occurs when SyncResumeResizeCompositor is called from java code
prior to the gecko compositor having been created. This results in us
delaying the call to UiCompositorController::ResumeAndResize().
Instead, once the compositor eventually gets created we call
UiCompositorController::Resume() (without the resize).
This means that the compositor widget is left with a zero size, and
RenderCompositorLayersSWGL bails early on compositing as a result.
To fix this, we cache the X, Y, width, and height arguments passed to
SyncResumeResizeCompositor. Then to resume the compositor when it
eventually gets created, we call ResumeAndResize() with the cached
values, rather than just calling Resume.
Differential Revision: https://phabricator.services.mozilla.com/D161046
In bug 1772839 we were seeing a large number of crashes due to
encountering a webrender error after exhausting all fallback
configurations. At least in some cases, this was due to the compositor
being resumed with an Android Surface that was already in an abandoned
state, meaning we can never succeed in creating an EGL Surface.
We added a check for this condition, and a workaround, to the
GeckoView java code. However, we are still seeing crash reports
matching this signature. To help determine whether these are also due
to the Surface being abandoned, or due to some other reason, this
patch adds a deliberate crash much earlier in the pipeline if we
detect an abandoned Surface.
Differential Revision: https://phabricator.services.mozilla.com/D160042
The android magnifier widget does not work when using our
SurfaceControl rendering path, as we no longer render in to the
Surface provided by the SurfaceView, but instead into a child Surface
we have created and attached the SurfaceControl.
To fix this, we create a SurfaceView subclass, MagnifiableSurfaceView,
which allows us to set an override Surface to be used by the
magnifier. This class works by overriding getHolder() to return a
custom SurfaceHolder, which returns our override Surface rather than
the default one when called by the Magnifier class.
Depends on D157308
Differential Revision: https://phabricator.services.mozilla.com/D157309
In order to fix the magnifier widget being broken, the previous patch
in this bug added a mechanism to disable and enable the SurfaceControl
rendering path. This caused some glitches to occur, so we removed the
calls to that code in bug 1783542, but the code remained.
As we now have an alternative solution to fix the magnifier widget, we
no longer require this code. This patch therefore reverts the original
patch, to lead the way for the new solution in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D157308
When turning on fission, OOP child frame doesn't receive touch events such as
`touchstart`.
When dispatching touch event from GeckoView side, some informations such as
`mLayersId` are missing since copy constructor of `MultiTouchInput` doesn't
copy all information.
Since the structure of Input data has a lot of members, we should use
`std::move` instead of copy constructor of `InputData`. It can avoid
unnecessary copy.
Differential Revision: https://phabricator.services.mozilla.com/D154242
On Android we previously added a rendering path using the
SurfaceControl API, in order to work around an Android OS bug when
recovering from a GPU process crash. Unfortunately the Magnifier
widget (shown when moving a text selection caret) does not work when
rendering using SurfaceControl.
This patch makes it so that we temporarily disable the SurfaceControl
path when a text selection is active, allowing the Magnifier to work.
Unfortunately this means that if a GPU process crash occurs while
there is an active selection we will be unable to recover. Hopefully
this turns out to be a relatively rare occurence.
Differential Revision: https://phabricator.services.mozilla.com/D153454
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
When the session storage prefs are enabled, GeckoSession updateSessionState will provide the bundle of information, including zoom, scroll, and form data, to the delegate. Currently works for Fission and on Fenix.
Differential Revision: https://phabricator.services.mozilla.com/D148215
Makoto Kato