There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
Invert screen pixels in `nsWindow`.
Update `RequestScreenPixels` in `nsWindow` to accept a `GeckoResult` as an argument and save as a `GlobalRef`.
Update `RecvScreenPixels` in `nsWindow` in order to invert the image before sending over JNI rather than requiring callers to invert the image themselves.
Complete the `GeckoResult` if there is one in `RecvScreenPixels` instead of making a callback to the compositor.
Remove `RecvScreenPixels` from `GeckoSession` and `GeckoSession.Compositor`.
Move `RecvScreenPixels` and `getPixels` to `GeckoDisplay`
Rename `getPixels` to `capturePixels`
Return Bitmap from `RecvScreenPixels`.
Return `GeckoResult` from `capturePixels`.
Add doc comments to new methods and classes.
Update FennecNativeDriver to use `GeckoView` and `GeckoResult`.
Update API docs and Changelog
Add tests
Differential Revision: https://phabricator.services.mozilla.com/D18944
--HG--
extra : moz-landing-system : lando
Although about.css, aboutMemory.css and aboutSupport.css are mobile-specific
style, these CSS files are used in toolkit, not mobile/android.
Since GeckoView doesn't has chrome.jar, these files are missing. So we should
move these CSS files to toolkit since we have mobile theme in toolkit.
Differential Revision: https://phabricator.services.mozilla.com/D20792
--HG--
rename : mobile/android/themes/core/about.css => toolkit/themes/mobile/global/about.css
rename : mobile/android/themes/core/aboutMemory.css => toolkit/themes/mobile/global/aboutMemory.css
rename : mobile/android/themes/core/aboutSupport.css => toolkit/themes/mobile/global/aboutSupport.css
extra : moz-landing-system : lando
The extension is only ever used for local files, so don't bother retrieving it
otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D21049
--HG--
extra : moz-landing-system : lando
While it's not clear how many apps might still have a generic HTTP-only intent-
filter at this stage, we only collect that information once per session, so to
be on the safe side we still check both schemes separately and merge the data.
Differential Revision: https://phabricator.services.mozilla.com/D20860
--HG--
extra : moz-landing-system : lando
Use the more concise way of defining functions and more arrow functions.
Also use a class to define "App" objects.
Differential Revision: https://phabricator.services.mozilla.com/D20859
--HG--
extra : moz-landing-system : lando
"Prior to Android 8.0 (API level 26), if an app requested a permission at
runtime and the permission was granted, the system would also incorrectly
grant the app the rest of the permissions that belonged to the same permission
group, and that were registered in the manifest.
For apps targeting Android 8.0, this behavior has been corrected. The app is
granted only the permissions it has explicitly requested. However, once the
user grants a permission to the app, all subsequent requests for permissions
in that permission group are automatically granted."
https://developer.android.com/about/versions/oreo/android-8.0-changes#rmp
Our FilePicker can delegate other applications to record media files
(photo/audio/video) which are then to be sent to websites. They must be saved
locally before the upload, scenario that wasn't possible anymore on Oreo+
because of the change in how Android handles runtime permissions.
As a way to get around this one could grant the "Storage" permission from
System Settings which would grant the app both READ and WRITE access.
But for actually being prepared to handle all situations our FilePicker must
ask for the WRITE_EXTERNAL_STORAGE permission at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D20821
--HG--
extra : moz-landing-system : lando
This is needed to make the handler to avoid race conditions where some code
tries to access a resource://android URI before the handler has been
registered.
Depends on D18739
Differential Revision: https://phabricator.services.mozilla.com/D18740
--HG--
extra : moz-landing-system : lando
Before this change, HasSubstitution would return false for "gre" or "app" which
is incorrect, since these handlers exist.
Differential Revision: https://phabricator.services.mozilla.com/D18739
--HG--
extra : moz-landing-system : lando
The bulk of this is copy/pasted from a standard android-api-16 debug
build. The only changes are a few extra environment variables in the
taskcluster config, the subconfig file, and the mozconfig, as well as
the --enable-mozsearch-plugin flag in the mozconfig.
Depends on D20766
Differential Revision: https://phabricator.services.mozilla.com/D20767
--HG--
extra : moz-landing-system : lando
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
This simply lets you request 'count' random bytes. A SHA-256 digest is
included for verifying the integrity of the response.
Differential Revision: https://phabricator.services.mozilla.com/D19503
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
Even though using text.replace() is supposed to keep the existing spans intact,
in practice the composition spans still get lost, even when the replacement text
is identical (because there was in fact no capitalisation difference between
user-entered text and autocomplete result).
One approach to fix this would be to manually save the composition spans and
subsequently restore them afterwards, like we already do this a few lines
further down below, in the other major code path through onAutocomplete().
However while trying to generalise that approach, the most natural approach for
the caller to specify which spans it wanted to save was to pass a Predicate
lambda to the state saving function, which for some reason led to strange
"Didn't find class" errors.
So instead, we just restart input for affected IMEs (i.e. Sony's keyboard) to
get them back into sync with the new contents of the EditText.
To avoid unnecessarily calling restartInput(), though, we only do this if the
user-entered text (which at this stage is known to correspond to the auto-
complete result when compared case-*insensitively*) actually differs from the
autocomplete result.
Differential Revision: https://phabricator.services.mozilla.com/D20487
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
This simply lets you request 'count' random bytes. A SHA-256 digest is
included for verifying the integrity of the response.
Differential Revision: https://phabricator.services.mozilla.com/D19503
--HG--
extra : moz-landing-system : lando
Patch from bug 1519418 introduced a regression by removing line separators from
the uid parameter contained within deeplinks. However, not all deeplinks are
mandatory to contain the uid parameter. Added a null check before replacing the
line separators.
Differential Revision: https://phabricator.services.mozilla.com/D20367
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
Looks like accessibility-test-framework was added to maven central so we can
remove this.
Differential Revision: https://phabricator.services.mozilla.com/D20365
--HG--
extra : moz-landing-system : lando
