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
