Normally we always want GeckoResult callbacks to run in the same thread where
the GeckoResult has been created.
In the case where we don't have a looper, however, we cannot do that. For
delegate calls, we are going to send the call to the UI thread, so we can use
the UI thread to run the callback (which is what the embedder would have to do
in this case, anyway).
Differential Revision: https://phabricator.services.mozilla.com/D134056
It's consistently set to bundle for all Darwin targets, and that's the
only value we really care about. Removing MOZ_FS_LAYOUT reduces the
differences between old-configure and js/src/old-configure one tiny bit.
Differential Revision: https://phabricator.services.mozilla.com/D133150
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This is required to replace the existing MOZ_FORCE_ENABLE_FISSION environment
variables in environments which use that. In the future we'll want to stop
passing any environment variable when not passing a flag to `./mach run`
however that will require changes to the default test behaviour in bug 1744091.
Differential Revision: https://phabricator.services.mozilla.com/D133006
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
Add a function to GPUProcessManager to force the GPU process to crash,
and expose it through gfxInfo. Expose this to geckoview tests via the
test-support webextension.
Add a junit test GpuCrashTest, which triggers a GPU process crash and
ensures the crash reporter was notified.
Additionally, ensure the TestCrashHandler service is stopped in
between tests, as otherwise only the first crash test to run will be
notified of the crash.
Differential Revision: https://phabricator.services.mozilla.com/D132812
Rename ContentCrashHandler.jsm to ChildCrashHandler.jsm as it is now
responsible for all types of child process crashes. Have it observe
"compositor:process-aborted" in addition to
"ipc:content-shutdown". Additionally, rename the
"GeckoView:ContentCrashReport" event it sends to
"GeckoView:ChildCrashReport".
In GPUChild::ActorDestroy, provide an out variable for
GenerateCrashReport to return the dump ID, and stuff this in to a
property bag, along with "abnormal: true", sent to
"compositor:process-aborted" observers.
In ChildCrashHandler, set the "processType" argument sent with the
GeckoView:ChildCrashReport event to BACKGROUND_CHILD for GPU process
crashes, and FOREGROUND_CHILD otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D132810
Currently the geckoview crash reporter has an EXTRA_CRASH_FATAL
argument, which indicates whether a crash is fatal, ie it occured in
the parent process and cannot be recovered from. Crashes in content
processes are by contrast deemed non-fatal, as the application can
recover from them.
With the upcoming GPU process on Android we will start collecting GPU
process crashes. These are certainly not fatal, and in fact should
barely be noticed by users. Applications may want a way to distinguish
between non-fatal but prominent content process crashes, and barely
noticeable GPU process crashes, so that they can avoid showing an
intrusive UI for GPU process crashes.
This deprecates the old EXTRA_CRASH_FATAL argument, and instead adds a
EXTRA_CRASH_PROCESS_TYPE argument to crash intents, whose value is a
String matching a new CRASHED_PROCESS_TYPE_* constant.
These constants are as follows:
* CRASHED_PROCESS_TYPE_MAIN: indicating a fatal main-process crash.
* CRASHED_PROCESS_TYPE_FOREGROUND_CHILD: indicating a recoverable but
obvious crash such as in a content process.
* CRASHED_PROCESS_TYPE_BACKGROUND_CHILD indicating a barely noticable
crash in a background process such as the GPU process
Differential Revision: https://phabricator.services.mozilla.com/D132809
To reduce test failure of inputConnection_sendKeyEvent, I would like to add more workaround.
As long as I run this fix in local 200 times, it is no failure.
Differential Revision: https://phabricator.services.mozilla.com/D132931
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
We already use the adoptopenjdk on some platforms, this allows us to have a
more predictable Java binary on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D130878
Even if landing bug 1697683, this NullPointerException occurs on the
background thread. So I would like to add more null check for this crash.
Differential Revision: https://phabricator.services.mozilla.com/D132329
Declare a GPU process and corresponding Service in the
AndroidManifest. This is of a new class GeckoServiceGpuProcess which
inherits from GeckoServiceChildProcess, and provides a binder
interface ICompositorSurfaceManager which allows the parent process to
set the compositor Surface for a given widget ID, and the compositor
in the GPU process to look up the Surface for a widget ID. The
ICompositorSurfaceManager interface is exposed to the parent process
through a new method getCompositorSurfaceManager() in the
IChildProcess interface.
Add a new connection type for GPU processes to GeckoProcessManager,
along with a function to look up the GPU process connection and fetch
the ICompositorSurfaceManager binder. When the GPU process is launched
we store the returned binder in the GPUProcessHost, and when each
widget's compositor is created we store a reference to the binder in
the UiCompositorControllerChild.
Each nsWindow is given a unique ID, and whenever the Surface changes
due to an Android resume event, it sends the new surface for that ID
to the GPU process (if enabled) by calling
ICompositorSurfaceManager.onSurfaceChanged().
Stop inheriting AndroidCompositorWidget from InProcessCompositorWidget
and instead inherit from CompositorWidget directly. This class holds a
reference to the Surface that will be rendered in to. The
CompositorBridgeParent notifies the CompositorWidget whenever it has
been resumed, allowing it to fetch the new Surface. For the
cross-process CompositorWidgetParent implementation it fetches that
Surface from the CompositorSurfaceManagerService, whereas the
InProcessAndroidCompositorWidget can read it directly from the real
widget.
AndroidCompositorWidget::GetClientSize() can now calculate its size
from the Surface, rather than racily reading the value from the
nsWindow. This means RenderCompositorEGL and RenderCompositorOGLSWGL
can now use GetClientSize() again rather than querying their own size
from the Surface.
With this patch, setting layers.gpu-process.enabled to true will cause
us to launch a GPU process and render from it. We do not yet
gracefully recover from a GPU process crash, nor can we render
anything using SurfaceTextures (eg video or webgl). Those will come in
future patches.
Differential Revision: https://phabricator.services.mozilla.com/D131231
Android O supports "Paste as plain text" in text toolbar. This is already
supported in Blink.
This change contains geckoview-junit test for this feature, but our taskcluster
job runs on Android 7, so this isn't run. (I verified this on my Android 8
emulator image).
Differential Revision: https://phabricator.services.mozilla.com/D131383
Otherwise, the warning is displayed:
```
WARNING: Could not lex literal_block as "json". Highlighting skipped.
```
Depends on D131092
Differential Revision: https://phabricator.services.mozilla.com/D131093
This test is rarely failure when initial text and selection correctly. Because
we don't wait for setting initial data, or it is text is too short to update
text.
So I re-write this tests. And also, this has typo fix for test name.
Differential Revision: https://phabricator.services.mozilla.com/D131048
We use seelectionchange event to wait selection is set correctly, it isn't
rarely fired according to test failure of this test.
So I use other way (using key operation) to set selection.
Differential Revision: https://phabricator.services.mozilla.com/D130821
Make nativeMessaging a privileged permission on Android, to hide the
connectNative/sendNativeMessage APIs from non-builtin add-ons,
and to avoid the permission warning on regular extensions (where the API
is unavailable).
Add unit tests to get coverage on the availability and behavior of the
native messaging APIs on Android, since we did not have any yet.
And fix a small serialization issue in ExtensionParent.jsm
Differential Revision: https://phabricator.services.mozilla.com/D130529
Added a check to see if the media blob URL was valid and could be downloaded.
Added a few general unit tests for ContentDelegateChild.
Differential Revision: https://phabricator.services.mozilla.com/D129859
Notify "passwordmgr-form-submission-detected" when a form with password
is submitted.
The event should be notified regardless of whether the password manager
decides to show the doorhanger or not. To support this, this patch
also refactors _maybeSendFormInteractionMessage function to distinguish
"onFormSubmit" event and "showDoorhanger" event.
Differential Revision: https://phabricator.services.mozilla.com/D127104
There is a potential intermittent where we try to execute javascript in the
page before the page navigates away, causing a hang. To ensure that that is not
possible we also wait for a PageStop event.
Differential Revision: https://phabricator.services.mozilla.com/D130377
With Fission BFCache, when navigating back the two pages might run in different
processes, even though they belong to the same domain.
This means that `pagehide` and `pageshow` might come out of order. For example,
navigating from `a.html` to `b.html` and back, we might get
```
pageshow b.html
pageshow a.html
pagehide b.html
```
notice we get the `pageshow` event for `a.html` _before_ the `pagehide` event
for `b.html`.
Internally in our test framework, we use `pagehide` and `pageshow` to establish
a connection between a page and the Java layer through a WebExtension port.
Before this patch, we assumed tha all `pageshow` events will match a `pagehide`
event in order, and thus disconnect the port early for `a.html` when getting
the event for `b.html` in the above example.
There is also a separate problem where if a port was established for a given
web page and then a navigation was issued, we would hang waiting for a response
from the page that navigated away (and thus, we would not be able to send
messages anymore).
To fix both of these issues, we keep track of all pending messages and discard
them properly when a Port is disconnected, and make sure that the port that's
disconnecting matches the one that's currently associated with the session (to
ensure that we are not disconnecting because of a out-of-order port event).
Differential Revision: https://phabricator.services.mozilla.com/D130376
Notify "passwordmgr-form-submission-detected" when a form with password
is submitted.
The event should be notified regardless of whether the password manager
decides to show the doorhanger or not. To support this, this patch
also refactors _maybeSendFormInteractionMessage function to distinguish
"onFormSubmit" event and "showDoorhanger" event.
Differential Revision: https://phabricator.services.mozilla.com/D127104
This patch adds a new command line argument --aab which allows users to install
GVE as an AAB.
This will also be used in a future patch to install the test runner as AAB.
Differential Revision: https://phabricator.services.mozilla.com/D127323
The fact that the test runner app is defined inside the geckoview test package
has always felt like a hack to me. I've mistakenly thought that
TestRunnerActivity was used in GeckoView's junit tests many times (even though
that's not the case).
From what I can see, there's no way to generate an AAB package for androidTest,
so to be able to run Gecko tests as AAB we finally need to define the
TestRunner as an ordinary package instead.
Differential Revision: https://phabricator.services.mozilla.com/D127320
Before this patch, we would load mozglue using the unqualified
`System.loadLibrary("mozglue")` and then we would try to load all the other
native libraries from the path returned from `nativeLibraryDir`.
Note that since the path is unqualified, we might end up loading a library
that's not inside the APK, potentially a malicious one.
Android App Bundles (or AAB) is a new feature of Android where apps can be
split in multiple APKs (called "splits"). Each APK split contains a functinal
part of the app, e.g. a specific resolution asset folder, all the native
libraries for one CPU architecture etc.
For AAB, `nativeLibraryDir` returns an empty folder as the libraries are
stored, uncompressed, inside one of the APK splits, so GeckoView fails to load
libxul and other libraries when starting up.
The current code also doesn't work for any case where `System.loadLibrary`
fails to load mozglue (we do have code that accounts for that, but I'm not sure
how much of it is funcitonal).
To fix that, we locate the mozglue using code ported from Chromium and use that
to locate all the other native libraries.
Note this still doesn't fix the problem of loading an unqualified mozglue
library, but there's not a lot we can do about that right now (and that's not a
new problem, so we can address it in a separate patch).
Differential Revision: https://phabricator.services.mozilla.com/D122909
Failing to close the File Descriptors causes a shutdown hang, as the main
process is not able to detect when the child process dies because we're leaking
the File Descriptors.
Differential Revision: https://phabricator.services.mozilla.com/D128938
This patch refactors `GeckoProcessManager`. Before this patch, we would pass
all arguments needed to start a process in every method call, together with the
previous error (if present).
This patch groups the arguments in a class `StartInfo` and keeps the failure
information separately in a list of exceptions that can be used to generate a
log in case of failure.
This patch also fixes two problems:
- We were calling `detachFd` right after connecting to a process, which is
incorrect when the binding fails, as we still need a reference to the File
Descriptor to retry the connection. After the patch, we will call detach only
at the end when we either have established a connection or we have given up.
- We were taking ownership of the File Descriptors from Gecko. This is
incorrect because Gecko owns them already and calling `close` accidentally
will crash the app. We now `dup` them instead, using
`ParcelFileDescriptor.from`. This also means that the call to `detachFd` is
now a call to `close`.
Differential Revision: https://phabricator.services.mozilla.com/D128935
This patch adds a builder for InitInfo and allows us to define its members as
final.
This is especially useful for File Descriptors which are all of the same type,
and could be easily swapped in method calls.
Differential Revision: https://phabricator.services.mozilla.com/D128933
This patch adds a new API onLoginFetch() which will be called when Gecko needs
access to all logins saved on the device (as opposed to just logins for a
domain).
Differential Revision: https://phabricator.services.mozilla.com/D129862
Notify "passwordmgr-form-submission-detected" when a form with password
is submitted.
The event should be notified regardless of whether the password manager
decides to show the doorhanger or not. To support this, this patch
also refactors _maybeSendFormInteractionMessage function to distinguish
"onFormSubmit" event and "showDoorhanger" event.
Differential Revision: https://phabricator.services.mozilla.com/D127104
Many users report that GeckoView returns non-coarse value for primary pointer
capabilities. Actually, we assume that primary pointer device is 1st device by
`InputDevice.getDeviceIds`, but some mobile devices seems not to return touch
screen as 1st item according to user reports.
Also, Android's `InputDevice` API doesn't define what is primary pointer
device, so we cannot assume primary pointer device well.
Other implements are,
- Chrome returns coarse if something input device has coarse capability.
- Firefox for Windows seems to return coarse if it is tablet mode.
So we should return coarse as primary pointer capability when having touch
screen, like Chrome.
But there is still another issue.
When I check some devices (including Android VM on Chrome OS), even if no touch
screen, the `InputDevice`'s source may has `SOURCE_TOUCHSCREEN`. Chrome checks
that fine pointer at first, then it checks coarse pointer. But current GV is
coarse pointer at first. Since the `InputDevice`'s source may have both
`SOURCE_MOUSE` and `SOURCE_TOUCHSCREEN` on touchpad/mouse, GV returns different
result. So we shouldn't check `SOURCE_TOUCHSCREEN` at first.
Differential Revision: https://phabricator.services.mozilla.com/D129901
This instantiates the FOG service, which in turn registers an idle
observer, which is required for FOG IPC to be triggered occasionally.
Glean itself will be controlled by the surrounding Android application.
Glean symbols are shipped in this GeckoView build.
Any metrics recorded in Gecko will be passed through to the Android
application, e.g. Fenix.
This also re-exports `rlb_flush_dispatcher` to be called by Glean Core from the Kotlin side.
Currently this does not support sending custom pings inside Gecko.
Testing Glean metrics in an Android build will be enabled in subsequent commits.
Differential Revision: https://phabricator.services.mozilla.com/D126799
We still rely on dynamic loading to find the symbols, but since we get
them from libxul, we don't need to load the library before activating
the process sandbox anymore.
Differential Revision: https://phabricator.services.mozilla.com/D128333
This change adds a new lint `android-format` which enforces formatting of Java
code using google-java-format.
To run the lint simply run:
./mach lint -l android-format
This command also support automatically fixing all errors running by adding
--fix:
./mach lint -l android-format --fix
This change also removes all the formatting-related checkstyle checks which are
now implicitly enforced by the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D127734
On Android we currently apply a 4x multiplier to the size of the
display port. When using the old Layers rendering backend, we would
render the non-multiplied "critical display port" at normal
resolution, and if required we would render the inflated display port
in low resolution. This helped avoid checkerboarding.
With webrender we only render what is currently visible on the
screen, so having an inflated display port is probably less
useful. There are still circumstances when it could help avoid
checkerboarding, for example when the main thread is busy it allows
for more scrolling without a new scene being built. But this benefit
is likely outweighed by the increased display list and scene building
time caused by the larger display port.
As a first step this patch simply sets the layers.low-precision-buffer
pref to false, which will prevent us from increasing the display port
size. This will make the change easy to revert in case it does cause
any issues. If this has the desired effect then we can remove the
relevant code in a follow up patch.
Differential Revision: https://phabricator.services.mozilla.com/D128062
When Autofill service runs with compatibility mode [*1] (such as Bitwarden),
`View.onProvideAutofillStructure` walks through the accessibility nodes.
Walking through it spends a lot of times.
When checking Android's source code, the following walks through it.
- `onProvideAutofillVirtualStructure`
- `autofill`
- `isVisibleToUserForAutofill`
Actually, since we already add autofill's virtual nodes, it is unnecessary to
walk through it.
*1 https://developer.android.com/reference/android/service/autofill/AutofillService#compatibility-mode
Differential Revision: https://phabricator.services.mozilla.com/D127952
Normally, a private browsing session doesn't store any data permamently. This
extends to permissions, which are cleared at the end of the browsing session
(i.e. when the GeckoRuntime is closed or killed).
There are cases, however, where we want to keep the data around. For example
Focus needs to store tracking protection permissions permanently.
For this reason, this patch introduces a new API that allows embedders to set
permanent permissions for private browsing GeckoSession.
This patch also always sends a tracking protection permission for every page
load, this allows embedders to set the tracking protection permission without
using the deprecated API `setPermission`, this was an oversight during the
implementation of the new StorageController API.
Differential Revision: https://phabricator.services.mozilla.com/D126546
This patch adds a new test service class that can be used to more easily write
a test that needs to run multiple runtimes or needs to reset the runtime.
The service also includes an optional Instance class that can be used to
control the service and send and receive messages from the remote runtime.
Differential Revision: https://phabricator.services.mozilla.com/D126542
For a long time two copies of the 'taskgraph' module have existed in parallel.
We've attempted to keep them in sync, but over time they have diverged and the
maintenance burden has increased.
In order to reduce this burden, we'd like to re-join the two code bases. The
canonical repo will be the one that lives outside of mozilla-central, and this
module will depend on it. Since they both have the same module name (taskgraph)
we need to rename the version in mozilla-central to avoid collisions.
Other consumers of 'taskgraph' (like mobile repos) have standardized on
'<project>_taskgraph' as their module names. So replicating that here as well.
Differential Revision: https://phabricator.services.mozilla.com/D127118
This patch introduces a new local.settings field: mozilla-central.mozconfig.
This field can be used to set a custom mozconfig file for the gradle build (and
for Android Studio).
The environment variable MOZCONFIG will take precedence over what is defined in
local.settings to allow Gecko engineers to use multiple mozconfig files.
Co-Authored-By: Nick Alexander <nalexander@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D124830
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
test_ext_tab_runtimeConnect.html can be re-enabled since bug 1534640 got fixed.
test_ext_tabs_reload.html had a race condition.
test_ext_tabs_reload_bypass_cache.html fix similar to bug 1335180.
Differential Revision: https://phabricator.services.mozilla.com/D124090
In the past, add_task was generator-based, and tests were automatically
rewritten to use Promises. Some tests have weird constructs such as the
use of Promise.all+await or still using generators. These have been
fixed.
Some tests request the tabs permission without actually needing it.
This patch does not affect the behavior of the tests.
Differential Revision: https://phabricator.services.mozilla.com/D124089
In mochitests on Android, ExtensionTestUtils.loadExtension defaults to
`useAddonManager: "android-only"` to allow Android tests to correctly
register with the AddonManager without unnecessarily forcing this
registration on desktop.
This patch removes all unnecessary uses of useAddonManager, to make it
obvious when a test really depends on the AddonManager (on desktop),
opposed to only depending on it indirectly as part of the GeckoView
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D124088
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This will be a bug of Android VM on Chrome OS.
When touching trackpad, Android VM on Chrome OS might fire scroll event for
trackpad, then, it fires cancel event immediately.
Actually, since we don't consider this situation, APZ detects that this is
log tap unfortunately.
So we should dispatch ACTION_CANCEL as scroll event.
Differential Revision: https://phabricator.services.mozilla.com/D125643
Agi Sferro
Mike Hommey
Cathy Lu
Norisz Fay
Andreas Farre
Cosmin Sabou
Makoto Kato
Dana Keeler
Nika Layzell
Marian-Vasile Laza
Cristian Tuns
Hiroyuki Ikezoe
Noemi Erli
Chris H-C
Jamie Nicol
Karl Tomlinson
Richa Sharma
owlishDeveloper
Andreea Pavel
Edgar Chen
Butkovits Atila
criss
Christoph Kerschbaumer
cschanaj
Jonathan Almeida [:jonalmeida]
Shane Caraveo
Eemeli Aro
Julian Descottes
Sylvestre Ledru
Emilio Cobos Álvarez
Rob Wu
Olivia Hall
Dimi
Csoregi Natalia
Sebastian Hengst
Jan-Erik Rediger
Gabriel Luong
Narcis Beleuzu
Andi-Bogdan Postelnicu
Timothy Nikkel
Evgenia Kotovich
Alexandru Michis
Michael Comella
Tomislav Jovanovic
Andrew Halberstadt
Mirko Brodesser
Alex Lopez
Katherine Patenio
John Lin