Most IMEs handle arrow key, then set caret position by IME. But GBoard doesn't
handle it. GBoard will dispatch key event to application for arrow left/right
even if having IME composition.
Since Gecko doesn't dispatch key press during IME composition due to DOM UI
events spec, we have to emulate arrow key's behaviour.
And, `GeckoEditable` has a hack that composition text is committed when
dispatching key event. This hack is unnecessary after landing
bug 1613804 that `InputConnection.finishComposingText` is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D76658
`|mach lint -f treeherder|` expects lints to not fail ever, if a lint fails it's
just ignored. This means that when our javadoc errors out and fails the build
all lints are ignored.
To avoid that we add `failOnError = false` to the javadoc job so that we can
finish the build and actually report the errors.
This patch also adds gradle output `|mach lint|` to make it easier to
diagnose errors in the lint.
Differential Revision: https://phabricator.services.mozilla.com/D77373
The sender doesn't await a result, and the recipient does not send a
result. To get rid of logspam when the finalizer is invoked, simply
replace `sendRequestForResult` with `sendRequest`.
Differential Revision: https://phabricator.services.mozilla.com/D77235
This crash hits when a `RemoteException` is thrown during `onServiceConnected`.
We `unbind`, which destroys all our bookkeeping data. During this destruction,
we also attempt to retrieve the pid, which fails because we lost our binding
before we had a chance to retrieve it.
This patch adds a new exception to be thrown in this case, which we explicitly
catch in `removeContentConnection`.
Differential Revision: https://phabricator.services.mozilla.com/D77135
In Bug 1622749 a user preference for where to open new documents (from a
service worker notification) was temporarily overriden in order to quickly fix
a crash that was happening in mozilla::dom::ClientOpenWindow. The crash was
ocurring when the pref "browser.link.open_newwindow" was set to 2, meaning new
documents are opened in a new window, instead of a new tab. The reason the
browser crashed is because the path for opening a new document is different
depending on the current user setting, and in NEWWINDOW case we did not get a
browsing context returned when calling mozilla::dom::OpenWindow which resulted
in a failed assertion.
The solution is to pass in a callback to mozilla::dom::OpenWindow as part of
nsOpenWindowInfo object, and invoke that callback with a corresponding
BrowsingContext in nsFrameLoader when that browsing context is ready.
After we call mozilla::dom::OpenWindow, we wait on a promise, that will be
resolved when the callback is invoked, before executing the rest of the code
that depends on the browsing context for a newly opened document being
available.
Differential Revision: https://phabricator.services.mozilla.com/D72745
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I'm keeping this patch as simple as possible so that we can uplift to beta.
I'll sort out the rest of this in follow-up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D76333
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
`GeckoProcessManager.buildLogMsg` requires a successful bind to construct its
message, but its only remaining callsite is only invoked when a bind fails,
so it blows up.
This patch eliminates `buildLogMsg` and just changes the callsite to use
a string literal.
Differential Revision: https://phabricator.services.mozilla.com/D76086
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
* We modify connection management such that we now use more specific connection
types for {content, non-content, socket process} connections.
* We attach a native counterpart to the `GeckoProcessManager.ConnectionManager`
instance that listens for app foreground, app background, and when the
socket process is enabled, network state events.
* On app background, all non-content processes are assigned BACKGROUND priority.
Even though backgrounding the app will cause Android to drop all child
processes' priority regardless of our priority settings, we still do this as
to indicate to Android that these processes are relatively less important
than our parent process.
* When the socket process is enabled, we drop its priority when we detect that
we have no network connectivity. Note that the network management code does
the Right Thing if network connectivity changes while our app was in the
background: we receive the network state change event once we return to
foreground, therefore we do not need to do any special handling ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D74478
I'm wondering whether Gecko's response to noticing that the child process was
killed is causing some notifications on the launcher thread to arrive out of
order from others. Removing the kill since we can just let Android handle
process termination.
Differential Revision: https://phabricator.services.mozilla.com/D75416
Since this is so common, let's reserve the `AssertionError` for debug builds.
In non-debug builds we will throw a `ServiceAllocator.BindException` which
will be caught and used for completing the bind promise.
GeckoProcessManager will retry unbinding and restarting the process, which
hopefully will mitigate the problem.
We also make some improvements to exception handling hygeine.
Differential Revision: https://phabricator.services.mozilla.com/D75415
Currently `unbind()` is more or less synchronous, but since those semantics may
change in the future, for the sake of cleanliness we should ensure that our
reaction is linked to `unbindResult`.
Differential Revision: https://phabricator.services.mozilla.com/D75414
In bug 1470348 we started to detach all SurfaceTextures from the
current GL context in CompositorOGL::Pause(). This was required for
VR, so that when the VR presentation was entered the SurfaceTextures
could be attached to the VR context instead.
When RenderCompositorEGL was implemented for webrender, we copied the
call to detach from CompositorOGL. However, due to extra complexity in
webrender's threading model, this is causing assertion failures.
VR no longer relies upon the SurfaceTextures being detached when the
compositor is paused, as it now uses its own SurfaceTexture
set. Therefore we can remove the detach call from both
CompositorOGL::Pause and RenderCompositorEGL::Pause.
Differential Revision: https://phabricator.services.mozilla.com/D74832
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
This patch will do :
- rename the old pref `media.autoplay.enabled.user-gestures-needed` to the new pref `media.autoplay.blocking_policy`
- modify the value of the pref to `int` in order to introduce new policy
- implement new policy in `AutoplayPoliocy`
The advantage of doing so :
- rename the pref to explicitly indicate that it's related the block policy we use
- use the transient user gesture activation as a new policy to replace the old one using the user input, which doesn't work on the async handler
More details :
The old `click-to-play` policy we use is using the user input to determine if the play invocation is called by users or by scripts. But `UserActivation::IsHandlingUserInput()` is buggy which would fail when you call `video.play()` inside an async event handler. So we would like to replace it with the new transient user activation, which would treat the action as an user input if the action is performed within a certain period of time after a user interacts (eg. click) with the page.
[1] https://html.spec.whatwg.org/multipage/interaction.html#transient-activation
Differential Revision: https://phabricator.services.mozilla.com/D73971
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/GeneratedJNI
```
which are then exported to `mozilla/java`
Differential Revision: https://phabricator.services.mozilla.com/D74720
This establishes a "high-water" mark that will make new files not be
"unified", and will allow to burn down the list of files require
unification.
Depends on D58573
Differential Revision: https://phabricator.services.mozilla.com/D58574
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/jni/GeneratedJNI{Natives, Wrappers}
```
which are then exported to `mozilla/jni/natives` and `mozilla/jni/wrappers`
Differential Revision: https://phabricator.services.mozilla.com/D74720
This establishes a "high-water" mark that will make new files not be
"unified", and will allow to burn down the list of files require
unification.
Depends on D58573
Differential Revision: https://phabricator.services.mozilla.com/D58574
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572
1. `GeckoProcessManager.ConnectionManager.onStartComplete` is called later than
it ideally should be; it would be better to do this as soon as binding is
complete, rather than as soon as `start` is complete. To accomplish this:
* We rename `onStartComplete` to `onBindComplete` and call it as soon as we
have successfully bound.
* We call `IChildProcess.getPid` as soon as we're bound and immediately clean
up if that fails.
* This implies that `getPid` should always have a pid and should not need to
call into `IChildProcess` during the remaining lifetime of the connection.
This allows us to eliminate exception throwing from `getPid`, and thus we may
also remove `getPidFallible`.
* This also means that we no longer need to explicitly call `getPid` in
`GeckoProcessManager.preload`.
2. We also use `XPCOMEventTarget.runOnLauncherThread` so that we do not need to
bounce through the launcher thread's event queue unnecessarily.
3. I noticed that we do not unbind the connection if the start fails but we
are not retrying. We should be unbinding regardless of whether we are going
to retry.
Differential Revision: https://phabricator.services.mozilla.com/D74500
When content length is over 2GB, `WebResponseInfo.contentLength` is negative
value. Use Long.valueOf instead of Integer.valueOf to pass this value.
Differential Revision: https://phabricator.services.mozilla.com/D74586
WebExtensionPolicy.getByID(id) will return a stub when called earlier during
startup. Once the startup process is complete, this object is sawpped with the
real extension policy.
Before this patch, we used to hold onto the stub object, which makes it so that
we read incorrect values even though we are waiting for the policy to be ready.
To fix this we just read the result value of the readyPromise promise.
Differential Revision: https://phabricator.services.mozilla.com/D74459
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
