`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
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
To support this API, we do the following:
Additions to `GeckoSessionTestRule`:
* We add an overload to `webExtensionApiCall` that accepts a `GeckoSession`
argument. Instead of sending the message to the extension's background script,
this overload instead sends the message to the port for the session's
content script.
* We add `GeckoSessionTestRule.getSessionPid()` which uses the new
`webExtensionApiCall` overload. Moving other existing APIs over to use the
new overload is out of scope for this bug and should be done in follow-ups.
Additions to the `test-support` extension:
* We modify the content script to receive an API call message from the native
port. It then forwards the request up to the background script. By doing it
this way, the background script will receive the message along with the
WebExtension `Tab` object belonging to the sender;
* The background script's message handler merges the tab into the arguments
to the API as a `tab` property;
* The background script then calls the API and the result is returned to
the harness using the native port, just like the normal implementation;
* We add a `GetPidForTab` API for resolving top-level PIDs from a webext tab id.
Differential Revision: https://phabricator.services.mozilla.com/D73723
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
When exporting the addon object, the extension policy sometimes is not ready
yet (very common when `list()` is called at startup), so we need to wait until
it's ready or the values in it will not be correct.
Differential Revision: https://phabricator.services.mozilla.com/D73770
These support the new implementation of the addon blocklist (bug 1620621),
which is a more space-efficient way to represent the blocklist.
A comparison of file size was given in D73159. In short, 913KB for the
old JSON-based blocklist (addons.json), 64KB for the new one.
In practice, addons.json is 273KB compressed.
The new blocklist (addons-mlbf.bin) does not compress that well since it
is already an efficiently packed binary format.
Differential Revision: https://phabricator.services.mozilla.com/D73438
Actually we emulate key event (down, press and up) from replace transaction of
`Editable`. When dispatching key press, we always update current caret position.
Most situations is the following.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive merged text/selection change result by 1. and 2.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
correct position now.
5. Dispatch keypress with correct position.
When this issue occurs, the following situation occurs.
1. Dispatch keypress
2. Dispatch another keypress
3. Receive text/selection change result of 1.
4. Sync shadow (Java's Editable) text with 3.'s result. It means selection is
old position now.
5. Dispatch another keypress with old position.
6. Receive text/selection change result of 2.
7. Receive text/selection change result of 5.
So when dispatching key press, we shouldn't always update selection if unnecessary.
Because selection range is already often set before dispatching key press.
Differential Revision: https://phabricator.services.mozilla.com/D71179
We need to move these tests to their own class so that we can add a `@Before`
function to set up the expected start conditions.
We also need to allocate the second session in such a way that it is
hosted by the same content process as `mainSession`.
The previous scheme of waiting on each `GeckoResult` independently caused
deadlocks if the results are resolved in a different order, so I replaced those
two waits with a `GeckoView.allOf` result that will Just Work (TM).
Note that this scheme works both in single-e10s and multi-e10s
configurations.
Differential Revision: https://phabricator.services.mozilla.com/D67067
Turn on some tests for InputConnection's behaviors. `inputConnection_setSelection` and `inputConnection_bug1133802` are still disabled due to Gecko issue and no good events.
Although I repeat 30 times to run this after this, no error now.
Differential Revision: https://phabricator.services.mozilla.com/D71151
Actually, we use `Thread.sleep` to get next sampling duration. But as long as
old comment, this sampling min duration is 10ms. But when I test
`Executors.newSingleThreadScheduledExecutor` on old device (10 year's old
Galaxy Nexus) instead of Thread.sleep, it can use 2ms sampling duration.
So we should use ScheduledExecutorService instead.
Differential Revision: https://phabricator.services.mozilla.com/D70401
`DeleteSelection*()` are members of `TextEditor`, but they are also used by
`HTMLEditor`. Therefore, they and pref cache members for them should be
in `EditorBase` too.
Depends on D71911
Differential Revision: https://phabricator.services.mozilla.com/D72290
We don't currently restart the extension process and this causes extensions to
randomly stop working when Android kills the extension process.
We can re-enable it once Bug 1355239 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D71790
This patch removes the allowLinkedWebInFileUriProcess pref, but one
code-path is kept because when DocumentChannel is disabled a HTTP POST load
from a file:// page would loose the postData, so that case keeps the FILE
remote type.
Differential Revision: https://phabricator.services.mozilla.com/D69923
Emily Toop
Aaron Klotz
Dan Glastonbury
John Lin
Dylan Roeh
David Teller
Eugen Sawin
Makoto Kato
Gabriel Luong
Jamie Nicol
alwu
Dorel Luca
Agi Sferro
Nick Alexander
Razvan Maries
Mike Conley
Bogdan Tara
owlishDeveloper
Nikita Kozhemiakin
Atique Ahmed Ziad
Simon Giesecke
Csoregi Natalia
Mihai Alexandru Michis
Ian Moody
Rob Wu
jayati
Shane Caraveo
Masayuki Nakano
Ricky Stewart
Paul Bone
Kartikaya Gupta