The new "tooltip.css" file allows styling the default tooltip, which is created as native anonymous content.
MozReview-Commit-ID: ADWsFTNPfhw
--HG--
rename : toolkit/themes/linux/global/popup.css => toolkit/themes/linux/global/tooltip.css
rename : toolkit/themes/osx/global/popup.css => toolkit/themes/osx/global/tooltip.css
rename : toolkit/themes/windows/global/popup.css => toolkit/themes/windows/global/tooltip.css
extra : rebase_source : bd79b86fb44ac0dc77d0d21fdc003105da6f43eb
extra : intermediate-source : a06a200098013d5dbc42c2431f845ca1dd8b0b76
extra : source : 4d511f7fc5b5c16fdfea91242dea6086cd57c8c3
The problem stemmed from having the DatePicker inside a ScrollView which
was receiving the swipe events.
To avoid this I've created the new FocusableDatePicker which has the ability
to prevent it's parent from receiving touch events.
MozReview-Commit-ID: 6VntjE5A0ec
--HG--
extra : rebase_source : 1c8d93e033c6cd37524b11b9ac70cc604af41a25
Fix an issue in GeckoEditable where spans can be mistakenly deleted when
deleting text. The new code re-copies all spans to make sure similar
issues don't happen in the future.
MozReview-Commit-ID: G1fWsJkeTka
--HG--
extra : rebase_source : 4ed3d17c3793a8a61182e660fb47694ba3c67f00
Currently, we expect editing operations in
GeckoEditableSupport::OnImeReplaceText to cause synchronous text change
notifications. However, under e10s, text change notifications can be
asynchornous. The new code keeps track of active OnImeReplaceText calls,
and look for async text changes before replying to the calls.
MozReview-Commit-ID: INM3JLmQebK
--HG--
extra : rebase_source : ff5b728ef437fcd78e4e7eced9c9a537d4698dce
Specialized the code added in Bug 1412517 so that it will apply only for
date/time inputs. The rest will have the previous behaviour.
MozReview-Commit-ID: JCAruK4x3r1
--HG--
extra : rebase_source : e2c0fa13f4c3edcf0c1e2b1a3654144f4057a650
Also made broadcasts involving Stumbler explicit.
MozReview-Commit-ID: 7CK2Cr2JqX0
--HG--
extra : amend_source : 4a7de557ad76f6cb2a0dcad5419ec2b37ca89e05
Added reading permission as a safety measure for any future android updates.
MozReview-Commit-ID: Be6V8hn9KF8
***
--HG--
extra : amend_source : 501deb367f68b0592a1d91015c640782700c62f3
Modified NotificationClient to use new start/stop intents for NotificationService for
Android O. We are keeping a reference to the notification the service was first
started with in order to comply with the mandatory startForeground call for Oreo.
MozReview-Commit-ID: 4CzM4pvANJt
--HG--
extra : amend_source : 3bb93cae58b214c680a3ea67fe60d3680767b558
Moved the logic ouf of MediaControlService to a new singleton GeckoMediaControlAgent,
which delegates all media-related actions.Currently, MediaControlService is used
for the foreground notification and to retrieve actions from the notification
pending intents. Removed redundant test cases.
MozReview-Commit-ID: KukAmpnn33S
--HG--
rename : mobile/android/app/src/test/java/org/mozilla/gecko/media/TestMediaControlService.java => mobile/android/app/src/test/java/org/mozilla/gecko/media/TestGeckoMediaControlAgent.java
extra : amend_source : 251b7821f4ddefcf852480de72ca1004cbd261bf
Refactored existing LeanplumPushInstanceIDService to support Oreo background
execution limits in Leanplum after upgrade.
MozReview-Commit-ID: JjUlrOv34KR
***
--HG--
extra : amend_source : df46ff00a671a02dc1c6fda3d0402d9216d7e84f
Made all the notifications within the app to use notification channel for devices with API26 and higher.
MozReview-Commit-ID: CVmpitNsS66
--HG--
extra : amend_source : 6628a1e06975e23b7b38a43650df12c9835cb3ee
Listening for `ACTION_MY_PACKAGE_REPLACED` [1] is the easiest way to get notified
when the app has been updated.
This broadcast, while not explicitly exempt from Oreo's Background Execution
Limits [2] is considered explicit because it is sent only to the package being
replaced and so it is compatible with the new limitations.
The previous intent action was chosen because at that time this action was not
supported by all platforms Fennec ran on [3], but this is not the case anymore.
[1] https://developer.android.com/reference/android/content/Intent.html#ACTION_MY_PACKAGE_REPLACED
[2] https://developer.android.com/guide/components/broadcast-exceptions
[3] 5c06063be6
MozReview-Commit-ID: Ak0dd2koJ9U
--HG--
extra : rebase_source : 58f32f574b13e5d7e9256f578821445eae1e3b57
extra : histedit_source : 204d858fe7408276714b2d228b612baddf76804d
This Receiver was used for implicit broadcasts and registered statically.
Refactored MmaDelegate() to register it dynamically in the init() method,
called in activity's onCreate and unregister it in activity's onDestroy.
This way we will still get notified immediately if the user installs any of
the apps we are interested in, even though he might not return to Fennec
immediately after. This will help to better asses the impact of suggestions to
install recommended packages.
For the cases in which the user installs the packages without us suggesting to
or if he kills our app before completing the new install, we will trigger a
check for the install status of the packages in MmaDelegate().init().
Also cleaned the code a little.
MozReview-Commit-ID: I00mLS2snzj
--HG--
extra : rebase_source : 9d767744dc3f4f2a44ab6de67c20f68a137a3beb
extra : histedit_source : e33a46fe4ece77b08eb8c9d161513e669fc14631
The only change needed was to make sure the broadcast for
NotificationHelper.HELPER_BROADCAST_ACTION is sent explicitly to
our receiver.
The other 2 broadcasts that this receiver listens for are already explicit.
MozReview-Commit-ID: C3A88ijqIsd
--HG--
extra : rebase_source : bd6beb4a6b5656b59ee61d0122a133042d77e380
extra : histedit_source : 63103038680580f5e30082e245fb0be5168529eb
Listening for `ACTION_MY_PACKAGE_REPLACED` [1] is the easiest way to get
notified when the app has been updated.
This broadcast, while not explicitly exempt from Oreo's Background Execution
Limits [2] is considered explicit because it is sent only to the package being
replaced and so it is compatible with the new limitations.
The previous intent action was chosen because at that time this action was not
supported by all platforms Fennec ran on [3], but this is not the case anymore.
The other broadcast - `ACTION_NOTIFICATION_CANCELLED` that this receiver
listens to is send explicitly.
[1] https://developer.android.com/reference/android/content/Intent.html#ACTION_MY_PACKAGE_REPLACED
[2] https://developer.android.com/guide/components/broadcast-exceptions
[3] 5c06063be6
MozReview-Commit-ID: DLUdw906i3P
--HG--
extra : rebase_source : a8544ae169344896aba4c7b922b68af4ad4bc94c
extra : histedit_source : c41c60cedea452ba8662fa836faa2aa8f9b5627e
Whenever the GCM token expires it need to be refreshed.
For this, after targeting Android 8.0 (API level 26) or higher
Google recommends using a JobIntentService
https://developers.google.com/cloud-messaging/android/client
MozReview-Commit-ID: 1vz092TQfbz
--HG--
extra : amend_source : afecc9454dd64c1b0a83bc469d7cf201909ee2ae
This simple Service needed to be migrated to JobIntentService because it could
be started from background and we don't want it as a foreground service
(with a notification).
(For example: when the app is updated org.mozilla.gecko.PackageReplacedReceiver
would try and start this service. If in background, the app would crash)
Had to break the initial Service into separate JobIntentServices because in the
event that there are concurrent calls (even with different Intent actions)
JobScheduler would assume they are for the same already running service.
INTENT_ACTION_UPDATE_ADDONS was removed as it was being unused.
MozReview-Commit-ID: 2GiWFZdAVvp
--HG--
extra : amend_source : 7236a78707b781ee24eafe1e69662c10bd6a0ea6
Use the fact that a JobIntentService is still a Service to keep most of the
previous implementation and method of starting CrashReportingService.
On 26+ devices it will be called with "start-foreground-service".
This ensures it can be started even from background and the crash reporting
process would work as before but ActivityManager will post an ANR error to
logcat after 5 seconds because we aren't calling Service.startForeground()
(which would mean a user visible notification).
Will use different Job Ids depending on if the app is Firefox Release or
Firefox Beta.
The Job Id will be passed to GeckoThread when first initializing and then be
made available to CrashHandler and nsExceptionHandler.cpp to be sent in the
Intent that starts the CrashReporterService.
MozReview-Commit-ID: GATl6Waa9St
--HG--
extra : amend_source : 70bc130b9411df336181e825ebb3e19bdc5a778c
Broke the big IntentService into four small JobIntentServices because
the same JobIntentService class cannot be used with multiple JobIds
(b6838fd2d2/compat/src/main/java/android/support/v4/app/JobIntentService.java (L121))
Also:
- will make the code easier to be migrated to WorkManager in the future
- more in line with SRP. It was initially doing too much.
All the functionality of the big UpdateService class has been incorporated in
Updater.java, UpdatesPrefs.java and UpdatesServiceHelper.java
with the main logic to drive the important actions inside the new Services.
UpdaterService is used as parent of the newly created service to help avoid
duplicated code.
Created an inner BroadcastReceiver to act upon notification actions while
the service which posted it is running as it's state needed to be modified.
Created a BroadcastReceiver to act on actions from notifications which remained
posted after the service that posted them finished. This receiver will just
start another UpdaterService.
Otherwise the services are to be started from the UpdateServiceHelper class.
MozReview-Commit-ID: 2OyBZ4YYvgh
--HG--
extra : rebase_source : 17b98a1209409c09227490ca66d75d8d37717a6e
Broke the big IntentService into four small JobIntentServices because
the same JobIntentService class cannot be used with multiple JobIds
(b6838fd2d2/compat/src/main/java/android/support/v4/app/JobIntentService.java (L121))
Also:
- will make the code easier to be migrated to WorkManager in the future
- more in line with SRP. It was initially doing too much.
Cleaned the code a little, removed the superfluous creation of new Threads for
DownloadContentCatalog().persistChanges() / .startLoadFromDisk()
as those methods are always called from the background threads
of the new JobIntentServices.
The new DlcHelper helps reducing duplicated code.
MozReview-Commit-ID: G3fsWYOGEbR
--HG--
extra : rebase_source : 5bdc3e64a44b7a3f77743b2b2f8f5d528a7b51c3
Upgraded to version 3.0.2 from official repository while keeping the internal changes.
This upgrade encapsulates some major changes as well as bug fixes.
MozReview-Commit-ID: DMOEIKnw0nJ
--HG--
extra : amend_source : b25a47601b1be6d23c389bc97a3dea033559c0a9
Updated google play services version as part of work of the Oreo migration and removed unused libraries from gradle.
MozReview-Commit-ID: BKCWs938k3q
--HG--
extra : rebase_source : 2e9ad83904276607f27974206bd3ad0ba2879279
This patch also:
Resolves missing resources and api changes
- LeanplumActionBarActivity was removed because Support Library 26 deprecated
ActionBarActivity. Class was already not in use.
- CustomTabsService added two new methods which we need to override.
Tested to make sure that previous functionality was maintained but with the
addition of the two new methods maybe that feature could be improved.
- For checking layout direction we'll use our own new method from ViewUtil
which mimics what the now restricted method from the support library would do.
- Upgraded to use AppCompatResources#getDrawable(..) in place
of the now restricted AppCompatDrawableManager.get().getDrawable(..).
Resolves obscure leaks and crashes after the upgrade
- LoaderManager.destroyLoader(..) was added before the existing call to
LoaderManager.restartLoader(..) to prevent potential Cursor leaks
- Disable website suggestions depending on the address bar inputs when running
in automation to avoid Robocop tests failing (they were entering serially maybe
100 characters in <5 ms which created around that many new Threads,
operation that could cause the Executor to throw a RejectedExecutionException)
At the moment this functionality is not covered by tests anyway and it was the
only fix I could find that would not involve changing the whole implemenation
for address bar suggestions, implementation which in the real world works ok.
MozReview-Commit-ID: 2fX1SBHiSh0
--HG--
extra : amend_source : edb6c5853cdcea5ad50a7cf680f2214fdc176cb2
The problem stemmed from having the DatePicker inside a ScrollView which
was receiving the swipe events.
To avoid this I've created the new FocusableDatePicker which has the ability
to prevent it's parent from receiving touch events.
MozReview-Commit-ID: 6VntjE5A0ec
--HG--
extra : rebase_source : a0f9589bf000ba10e5429347fe1dc7516e8eef3f
