This is needed to open an SCO channel and do proper (low-latency) bluetooth
communication when doing a call using WebRTC, or simply recording local audio in
a web application.
I think this is more of a GeckoView thing, but I'm a bit fuzzy on the
distinction, maybe it's the wrong manifest. I tested using Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D21734
--HG--
extra : moz-landing-system : lando
In particular, this enables Marionette in local Fennec builds, which
were the only place it wasn't enabled by default. (Automation builds
all enabled Marionette.) That default is getting in the way of the
Performance Team (and others!) testing GeckoView-based products
easily.
Differential Revision: https://phabricator.services.mozilla.com/D26815
--HG--
extra : moz-landing-system : lando
..And ignore trying to show it again in future app starts.
This patch resolves a regression and restore the previous behavior.
Differential Revision: https://phabricator.services.mozilla.com/D26897
--HG--
extra : moz-landing-system : lando
apilint 0.1.9 fixes a bug that was causing us to miss some annotation lints.
This commit fixes all of them before we can upgrade.
Depends On D26028
Differential Revision: https://phabricator.services.mozilla.com/D26029
--HG--
extra : moz-landing-system : lando
This was fallout from Bug 1509572, which moved the "invalidation
smarts" to Gradle. Unfortunately, those smarts are not smart enough:
there are many situations where the annotations might change (a new
method) but where they don't actually change (a new method that isn't
annotated with @JNITarget).
Since we don't want to spend the time to make the "invalidation
smarts" truly smart, we need to bring back this little bit of Bug
1509572.
While we're here, we ensure that there is only one JNI wrapper
generation task for GeckoView and Fennec, regardless of variant.
Right now, those are named like:
- geckoview:generateJNIWrappersForGeneratedWithGeckoBinariesDebug
- app:generateJNIWrappersForFennecWithoutGeckoBinariesDebug
See https://bugzilla.mozilla.org/show_bug.cgi?id=1509539#c1 for some
discussion of these JNI wrapper generation tasks.
Differential Revision: https://phabricator.services.mozilla.com/D26427
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
mJavaDecoder is invalid after the decoder is shut down and should never
be used.
Differential Revision: https://phabricator.services.mozilla.com/D26438
--HG--
extra : moz-landing-system : lando
`EditorInfo.IME_ACTION_PREVIOUS` is used when clicking `Previous` key on FireTV's software keyboard. This key on System's WebView closes software keyboard and doesn't generate any keyboard event such as `ENTER`. So we should close it like System's WebView.
Differential Revision: https://phabricator.services.mozilla.com/D25913
--HG--
extra : moz-landing-system : lando
HandleOutput() runs on Android binder thread pool and could be preempted
by RemoteDateDecoder task queue. That means ProcessOutput() could be scheduled
after ProcessShutdown() or ProcessFlush(). When that happens, aBuffer is no
long valid and should never be processed, and aSample can be
recycled immediately.
Also assert preconditions of buffers received from Java callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D26189
--HG--
extra : moz-landing-system : lando
When remote codec executes flush(), it throws away existing buffers:
- memorized buffers are no longer valid and need to be forgotten
- samples returned before flush() will have null buffers and should
be released back to remote codec immediately.
Differential Revision: https://phabricator.services.mozilla.com/D26188
--HG--
extra : moz-landing-system : lando
Summary:
Since event time isn't set when translating ENTER key to TAB key, comparing
event time hits an assertion. So event time should be set.
Reviewers: esawin
Reviewed By: esawin
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D12883
--HG--
extra : rebase_source : 0d00bb0364b77b48645143ceb7eb20cad8663d48
extra : histedit_source : 44be4949d5d196458fa3b5ae3eb056340cf8575d
After bug 676268 is landed, Gecko/Android supports `text/html` mime type on
clipboard. But copy command is sometimes failed after select all is executed.
`nsISelectionContoller.selectAll` is different of `cmd_selectAll`.
Since `cmd_selectAll` that is used on Firefox desktop doesn't select root
element, copy command always works well. So we should use it like desktop
browser on Fennec.
Also, GV already uses cmd_selectAll on action bar, so this is Fennec only.
Differential Revision: https://phabricator.services.mozilla.com/D25924
--HG--
extra : moz-landing-system : lando
The configuration file format is YAML and looks like:
```
prefs:
foo.bar.boolean: true
foo.bar.string: "string"
foo.bar.int: 500
env:
MOZ_LOG: nsHttp:5
args: [--marionette]
```
By default, if the consuming App is debuggable, GeckoView will read
configuration from `/data/local/tmp/$PACKAGE-geckoview-config.yaml` at
startup.
For consumers (including browsers) that want to allow the underlying
GeckoView to be remote controlled in some way, the
`GeckoRuntimeSettings.Builder.configFilePath()` method allows to avoid
the default behaviour depending on the `android:debuggable` flag. For
example, release versions of Firefox for Android will want to allow
this configuration when appropriate App-level settings are toggled.
The additional configuration is appended after any existing configuration
methods, e.g., after anything specified using Intent argument extras
or existing `GeckoRuntimeSettings.Builder` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25885
--HG--
extra : moz-landing-system : lando
The configuration file format is YAML and looks like:
```
prefs:
foo.bar.boolean: true
foo.bar.string: "string"
foo.bar.int: 500
env:
MOZ_LOG: nsHttp:5
args: [--marionette]
```
By default, if the consuming App is debuggable, GeckoView will read
configuration from `/data/local/tmp/$PACKAGE-geckoview-config.yaml` at
startup.
For consumers (including browsers) that want to allow the underlying
GeckoView to be remote controlled in some way, the
`GeckoRuntimeSettings.Builder.configFilePath()` method allows to avoid
the default behaviour depending on the `android:debuggable` flag. For
example, release versions of Firefox for Android will want to allow
this configuration when appropriate App-level settings are toggled.
The additional configuration is appended after any existing configuration
methods, e.g., after anything specified using Intent argument extras
or existing `GeckoRuntimeSettings.Builder` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25885
--HG--
extra : moz-landing-system : lando
Set `MOZ_DEBUG_WAIT_FOR_JAVA_DEBUGGER=1` in the environment to make the
main (Gecko) process wait for a Java debugger to connect. This is a
superset of Android Studio's built-in debugging support so it won't be
particularly useful, but perhaps some folks want to use a different
jdwp debugger.
Set `MOZ_DEBUG_CHILD_WAIT_FOR_JAVA_DEBUGGER=suffix` in the environment
to make child processes wait for a Java debugger to connect. This is
not easy in Android Studio.
The value ":tab" will make any child process with a process name with
suffix ":tab" wait. N.b., the empty string "" is a suffix of all
process names and thus `MOZ_DEBUG_CHILD_WAIT_FOR_JAVA_DEBUGGER=` makes
all child processes wait.
Differential Revision: https://phabricator.services.mozilla.com/D25299
--HG--
extra : moz-landing-system : lando
Previously |mach android checkstyle| would only parse one file output form
checkstyle (the app one).
This change makes it so it parses all files, also it reduces noise by
suppressing most output when the test passes.
Differential Revision: https://phabricator.services.mozilla.com/D24737
--HG--
extra : moz-landing-system : lando
There are domains that we give extra permissions.
Those should be hosted and operated by Firefox.
input.mozilla.org isn't and it also doesnt use extra permissions anymore.
Differential Revision: https://phabricator.services.mozilla.com/D13948
--HG--
extra : rebase_source : be9879b6f89ee6979975e697e052220fc839785e
extra : amend_source : 8a45cbbeadcda306313034ac22d6f43612780e3a
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D25406
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D24397
--HG--
extra : moz-landing-system : lando
Skip mochitest-chrome test failing frequently on android/pgo. This directory of tests
only runs on Android 4.3, so the manifest annotation is simple.
Discussed in bug; see comment 17.
Differential Revision: https://phabricator.services.mozilla.com/D25274
--HG--
extra : moz-landing-system : lando
To prevent new buffer object from being created per frame, either
Sample.CREATOR has to keep track of all buffers from every remote codec,
or the client must memorize seen buffers and avoid asking for them again
and again. The former saves client code from modifications but complicates
the implementation of Sample, a data structure class, while the latter
requires changes to client code but avoid overcomplicating Sample.CREATOR
implementation.
The 2nd approach is taken:
- move SampleBuffer out of Sample, and update clients accordingly
- add a new IPC method for clients to get the buffers only when needed
Differential Revision: https://phabricator.services.mozilla.com/D24590
--HG--
extra : moz-landing-system : lando
Bug 1493317 enables AccessibleCaret in unit tests. No need to manually
flip the pref.
Differential Revision: https://phabricator.services.mozilla.com/D24963
--HG--
extra : moz-landing-system : lando
Also ensure that LightweightThemeManager.updateOneTheme() returns
even if the update request fails.
Differential Revision: https://phabricator.services.mozilla.com/D24981
--HG--
extra : moz-landing-system : lando
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put preferences into
those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
We really want GeckoView's single remote debugigng setting to
determine whether the engine can be remote controlled, but we're not
quite there yet. The devtools use an abstract UNIX socket for this
purpose, but Marionette uses a TCP socket that defaults to port 2828,
and that means we see cross-App clashes for that port.
Functionally this means that enabling Marionette reverts to the "old
method": either pass the "--marionette" command line argument or set
the `MOZ_MARIONETTE=1` environment variable to enable. Callers remain
responsible for ensuring that the Marionette port is available.
Differential Revision: https://phabricator.services.mozilla.com/D25138
--HG--
extra : moz-landing-system : lando
- Use Bengali (bn-BD) as base
- Keep amazon-in on Desktop (from bn-IN)
- Remove rediff (from bn-IN)
Differential Revision: https://phabricator.services.mozilla.com/D23480
--HG--
extra : moz-landing-system : lando
Although I change to use editor by previous fix of bug 676268, it is not
good for non-editable content. cmd_copy can support editable and non-editable.
GV already uses cmd_copy for this.
Differential Revision: https://phabricator.services.mozilla.com/D24642
--HG--
extra : moz-landing-system : lando
When TalkBack receives a focus event, it redirects the accessibility focus (the green cursor) to the focused element. This is an important driver for the screen reader experience.
Since the focus mode of the GeckoView is "focusable in touch", the focused state of the view is very arbitrary when using TalkBack since the user never directly touches the view. The only way for the view to regain focus is if a control or link in the content is interacted with.
TalkBack user, who is explicitly interacting with the webview/geckoview would expect it to have focus, and to have the accessibility focus redirected in the page in the case of script-driven focus events.
Differential Revision: https://phabricator.services.mozilla.com/D23747
--HG--
extra : moz-landing-system : lando
Summary:
Actually, Fennec accesses clipboard directly when using action bar. To allow
`text/html` mime type, we should use editor API instead.
Also, Fennec doesn't fire clipboard event for copy and cut since it doesn't
use editor API (or `cmd_*` command). So we will be fixed by using editor API.
GeckoView uses `cmd_*` command, so this doesn't occur on GV.
Reviewers: #geckoview-reviewers, snorp
Reviewed By: #geckoview-reviewers, snorp
Bug #: 676268
Differential Revision: https://phabricator.services.mozilla.com/D22886
--HG--
extra : rebase_source : 57bdc8c3868124b96baf3866b54bac91d3742131
Summary: Actually, we only support `text/unicode` mime type on Android clipboard backend. But Android API 16+ supports `text/html`, so we should support this type since Chrome/Blink already supports it.
Reviewers: #geckoview-reviewers, snorp
Reviewed By: #geckoview-reviewers, snorp
Bug #: 676268
Differential Revision: https://phabricator.services.mozilla.com/D22659
--HG--
extra : rebase_source : 17ef0aa06b83b812bb9bccfab93a72e0b37f9652
Actually, Fennec accesses clipboard directly when using action bar. To allow
`text/html` mime type, we should use editor API instead.
Also, Fennec doesn't fire clipboard event for copy and cut since it doesn't
use editor API (or `cmd_*` command). So we will be fixed by using editor API.
GeckoView uses `cmd_*` command, so this doesn't occur on GV.
Differential Revision: https://phabricator.services.mozilla.com/D22886
--HG--
extra : moz-landing-system : lando
Actually, we only support `text/unicode` mime type on Android clipboard backend. But Android API 16+ supports `text/html`, so we should support this type since Chrome/Blink already supports it.
Differential Revision: https://phabricator.services.mozilla.com/D22659
--HG--
extra : moz-landing-system : lando
And use correct AccessibleCaret preference to disable it individually in tests.
Differential Revision: https://phabricator.services.mozilla.com/D10299
--HG--
extra : moz-landing-system : lando
Refactored the TabQueueService to be a foreground service from Android O
onwards. The service now uses a foreground notification that briefly informs
the user that a new tab is being added to the queue.
Depends on D23528
Differential Revision: https://phabricator.services.mozilla.com/D23529
--HG--
extra : moz-landing-system : lando
This also upgrades apilint to 0.1.8 to enforce that all interfaces have default
impls.
Differential Revision: https://phabricator.services.mozilla.com/D23324
--HG--
extra : moz-landing-system : lando
This was a leftover from an initial implementation which needed to track
certain events related to the user adding the search widget.
Otherwise it is not needed as we don't actually expose any widget settings to
be configured by the user before adding it.
Turns out this Activity would actually mess with our PendingIntents which would
not fire for when tapping search widget's elements.
Differential Revision: https://phabricator.services.mozilla.com/D23543
--HG--
extra : moz-landing-system : lando
We want to publish a multi-architecture AAR for GeckoView which includes
a single omni.ja, but we archicture-specific changes in greprefs.js that
prevent this from working. This patch causes us to try to read an
architecture-specific greprefs.js first, which will be provided by the
packaging process for the fat AAR.
Differential Revision: https://phabricator.services.mozilla.com/D22526
--HG--
extra : moz-landing-system : lando
This delivers a parsed and validated Web App Manifest to the
application, if present, during the page load process.
Differential Revision: https://phabricator.services.mozilla.com/D22612
--HG--
extra : moz-landing-system : lando
This delivers a parsed and validated Web App Manifest to the
application, if present, during the page load process.
Differential Revision: https://phabricator.services.mozilla.com/D22612
--HG--
extra : moz-landing-system : lando
We need to ensure that nothing from the previous app state would prevent a
smooth flow for the search widget UX.
As such, in the event that they were left open, we will close the options menu
and the tabs tray before entering in tab editing mode for search.
Differential Revision: https://phabricator.services.mozilla.com/D23477
--HG--
extra : moz-landing-system : lando
Added a telemetry probe (unique source value) to allow data science to measure percentage of searches initiated from the widget.
Differential Revision: https://phabricator.services.mozilla.com/D22956
--HG--
extra : moz-landing-system : lando
The only place we'd need the compat libraries would be for host
binaries, and those shouldn't be a problem given that our system images
are new enough.
Differential Revision: https://phabricator.services.mozilla.com/D22873
--HG--
extra : moz-landing-system : lando
SSTabScrollCaptured can sometimes be fired for other reasons, causing us to
query the visual scroll position before it has been updated.
Not explicitly waiting for SSTabScrollCaptured is also safe in this case
because we're only querying the session store's view of the scroll position
*after* closing the tab, which will flush any pending scroll position updates
in the session store.
Differential Revision: https://phabricator.services.mozilla.com/D19875
--HG--
extra : moz-landing-system : lando
Disabling inputConnection on debug saves about 15 minutes of time, which helps
us avoid the timeouts seen in this bug. It continues running on opt, where it
runs much faster.
Differential Revision: https://phabricator.services.mozilla.com/D23254
--HG--
extra : moz-landing-system : lando
If the app was started from the search widget we need to always load about:home
and not the homepage which the user may have set to be another address.
Differential Revision: https://phabricator.services.mozilla.com/D22948
--HG--
extra : moz-landing-system : lando
Removed search widget update interval in order to prevent bad layout re-configuration.
Differential Revision: https://phabricator.services.mozilla.com/D22947
--HG--
extra : moz-landing-system : lando
Previous code was using our own sugary feature26Plus check which Lint doesn't
properly follow.
As such even if the code was properly guarded and behaved correctly Lint would
show errors about improper usage of methods which require higher api levels.
Doing the api check in place ensures it will get picked up by Lint's
ApiDetector and so it will not report about such errors here.
Differential Revision: https://phabricator.services.mozilla.com/D22889
--HG--
extra : moz-landing-system : lando
