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
We'll delay entering editing mode until we are sure the process for adding a
new "about:home" tab completed.
This allows avoiding certain race conditions with the previous state or with
the tab counter animation.
Differential Revision: https://phabricator.services.mozilla.com/D22701
--HG--
extra : moz-landing-system : lando
Added a flag on the search widget intent in order to skip the tab queue prompt.
Depends on D22314
Differential Revision: https://phabricator.services.mozilla.com/D22681
--HG--
extra : moz-landing-system : lando
Polished UI by adding a custom drawable with rounded corners.
Made layouts responsive by setting relative widths.
Handled edge case for 1x1 cell.
Removed unused resources.
Depends on D21685
Differential Revision: https://phabricator.services.mozilla.com/D22314
--HG--
rename : mobile/android/services/src/main/res/layout/widget_search_5_col_layout.xml => mobile/android/services/src/main/res/layout/widget_search_default_col_layout.xml
extra : moz-landing-system : lando
Implemented search widget's intent handling in BrowserApp class.
Depends on D20149
Differential Revision: https://phabricator.services.mozilla.com/D20151
--HG--
extra : moz-landing-system : lando
Added Search widget provider class, declared the provider in the manifest and created mock layout for it.
Differential Revision: https://phabricator.services.mozilla.com/D20149
--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
Previously, WebpageItemRow's layout would be updated everytime a new Tab for
it's url would be ADDED/CLOSED/LOCATION_CHANGED to force a recheck of the need
to show the "Switch to tab hint".
To prevent multiple layout refreshes for every such event we will check the
current display status of the "Switch to tab hint" against the newly computed
value after an ADDED/CLOSED/LOCATION_CHANGED event was received.
Eagerly changing the value for 'switchToTabHintShown' along with informing
about the need for layout refresh to prevent any race conditions between
receiving more events and actualy refreshing the layout.
(In my tests I saw ADDED/LOCATION_CHANGE refreshing the same layout needlessly)
Differential Revision: https://phabricator.services.mozilla.com/D24013
--HG--
extra : moz-landing-system : lando
Patch D16319 attempted to clean the MMA code and allow for easier debugging
of LP deeplinks on dev builds. However it introduced a regression because the
MMA preferences were being accessed by the initializing activity. By making
getDeviceId public and static, calling it from another activity would result
in a null value returned. I have refactored the code to use shared preferences
and remove the dependency on other activities.
Differential Revision: https://phabricator.services.mozilla.com/D21984
--HG--
extra : moz-landing-system : lando
In Bug 1514043 we renamed the geckomediaplugin to gmplugin, but missed renaming
it on Android. This prevents the plugin from loading, which breaks OpenH264 in
WebRTC.
Differential Revision: https://phabricator.services.mozilla.com/D22502
--HG--
extra : moz-landing-system : lando
There are at least two known side effects of initializing it after
loading libxul:
- We can't set LLVM_PROFILE_FILE for the instrumentation part of PGO to
make the compiler-rt static initializer pick it.
- We can't set MOZ_DEBUG_LINKER to enable the linker debug log (which
used to work when environment variables were set earlier).
Differential Revision: https://phabricator.services.mozilla.com/D21646
--HG--
extra : moz-landing-system : lando
There are at least two known side effects of initializing it after
loading libxul:
- We can't set LLVM_PROFILE_FILE for the instrumentation part of PGO to
make the compiler-rt static initializer pick it.
- We can't set MOZ_DEBUG_LINKER to enable the linker debug log (which
used to work when environment variables were set earlier).
Differential Revision: https://phabricator.services.mozilla.com/D21646
--HG--
extra : moz-landing-system : lando
There are at least two known side effects of initializing it after
loading libxul:
- We can't set LLVM_PROFILE_FILE for the instrumentation part of PGO to
make the compiler-rt static initializer pick it.
- We can't set MOZ_DEBUG_LINKER to enable the linker debug log (which
used to work when environment variables were set earlier).
Differential Revision: https://phabricator.services.mozilla.com/D21646
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
Before this patch, Firefox for Android (and GeckoView) would make an extra
(unnecessary) XHR to gather the information it needed to add a certificate error
override. However, the docShell already has the required information (via
failedChannel.securityInfo), so this patch makes it so.
Differential Revision: https://phabricator.services.mozilla.com/D21791
--HG--
extra : moz-landing-system : lando
"browser.firstrun.*" seems to have been unused since the end of XUL-based
Fennec, whereas the code referencing the "browser.snippets.*" prefs was removed
in bug 1482836.
Differential Revision: https://phabricator.services.mozilla.com/D20862
--HG--
extra : moz-landing-system : lando
There are crash reports for large heap allocations for Bitmaps from the
NotificationClient#add method.
As more of a speculative fix this patch introduces bitmap size constraints for
the largeIcon of the notification this method posts. Previously the app would
happily load any image from the passed in image URL even though the maximum
size the largeIcon can be is 256x256 pixels.
Differential Revision: https://phabricator.services.mozilla.com/D21666
--HG--
extra : moz-landing-system : lando
The animation is cute, but one test is effectively treating the image data as a
text file, and displaying the whole file as text leads to *very* long loading
times on the ARM emulator when word-wrapping is turned on, especially when using
a debug build.
Differential Revision: https://phabricator.services.mozilla.com/D23367
--HG--
extra : rebase_source : 796bd5eea8cfa2c5f23aaa0ed663114b2c0573e8
extra : amend_source : e28fb8981acba33a8b3ea6ae14eddae0c7292164
extra : source : 69dfaab9947c0c4b5e5b965abe9b26d0f054ef88
When removing composing text, we call
`InputMethodManager.updateSelection(start, end, -1, -1)`.
But ATOK (Japanese input method by Justsystem) series do nothing. So, shadow
text and current text becomes mismatched.
As workaround, we need call `restartInput` to remove composing text if using
ATOK series.
According to ATOK team, ATOK has several packages name since they release
several customize version.
- `com.justsystems.atokmobile.*` (ATOK, ATOK subscription and etc)
- `com.atok.mobile.*` (OEM version)
Differential Revision: https://phabricator.services.mozilla.com/D20632
--HG--
extra : amend_source : 3380064eef826666d11c34c303bf1a493750c28e
extra : histedit_source : 6038cbccc76cc7295abc5f961745070335e8dcdf
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/D21833
--HG--
extra : moz-landing-system : lando
There are at least two known side effects of initializing it after
loading libxul:
- We can't set LLVM_PROFILE_FILE for the instrumentation part of PGO to
make the compiler-rt static initializer pick it.
- We can't set MOZ_DEBUG_LINKER to enable the linker debug log (which
used to work when environment variables were set earlier).
Differential Revision: https://phabricator.services.mozilla.com/D21646
--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/D21397
--HG--
extra : moz-landing-system : lando
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
