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
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This test was testing that files are loaded/executed/etc in the page, but
what we really care about is that the webrequest api works. Other tests
are responsible for stuff like css and js actually work. The patch does
maintain (fixed) the js test, but removes the css test for lack of a good
way to properly wait for css to apply.
MozReview-Commit-ID: B2uByaxNeK2
--HG--
extra : rebase_source : 6779116f9f1a4a7ce24cd32c3648d1027343db93
a35b188d0e44 inadvertently regressed behavior in the case where
the Git status.showUntrackedFiles config option was set and
we want to purge untracked files.
Differential Revision: https://phabricator.services.mozilla.com/D2141
--HG--
extra : moz-landing-system : lando
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
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: 4xFQz3tOLEx
--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
Right now, the firstPartyDomain won't be set when using IP addresses as
first party domains. It is because of that the TLD service won't accept
IP addresses as valid hosts. The patch fixes this problem by detecting
that if the host is a IP address. If it is, we will still set the
firstPartyDoamin with the IP address.
Differential Revision: https://phabricator.services.mozilla.com/D1977
--HG--
extra : moz-landing-system : lando
Such messages happen intermittently on Android, presumably from bfcache being
purged due to memory pressure (which would then cause the back() operation
behave like a fresh load). So on Android, we'll now treat these redundant
messages as a "todo()" failure, to indicate that something went wrong but avoid
turning the testsuite orange.
MozReview-Commit-ID: GkaxB06vL7q
--HG--
extra : rebase_source : 64c0c0a41452d573062774b2300a26aad179b309
