We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
Actually, Gecko uses thread name "main" to find main thread. But Android
has Looper object to get main loop. So we should use it instead.
MozReview-Commit-ID: 9oVqftqLZmh
--HG--
extra : rebase_source : 84593b794f9055739a10a08ca2b4fa737043100c
Bug details:
The problem stemmed from the now called GeckoPreferences.trySwitchToHeader(int id) which could be called with an invalid id, constant with the same value as the id of the last available setting.
(GeckoPreferenceFragment().getHeader() would return valid ids only for preference screens that are launched directly. Otherwise it would return: -1)
By chance the id for the last available setting - vendor was not set and so Android saw it with an invalid header id: -1.
GeckoPreferences.trySwitchToHeader(int id) would just switch to showing the vendor setting because that is what he has been instructed to whenever the user tried to access other settings than the ones which can be launched directly.
Cleaned the code a bit:
- renamed GeckoPreferences.switchToHeader(..) to trySwitchToHeader(..) as it won't always perform that action
- removed the call to activity.showBreadCrumbs(..) as in my tests it didn't have any effect and the documentation says "This will normally be called for you".
Tested on An Android 8 tablet, on an Android 8 phone, on an Android 5.0.1 phone and all works ok.
MozReview-Commit-ID: 2sbfcuRHgZd
--HG--
extra : rebase_source : 51f4629e89846d01224a0cd7dd8b3fba93657f40
Instead of creating a new session for every test case, we can get away
with reusing the same session for the most part. This results in a large
decrease in testing time due to lower overhead.
MozReview-Commit-ID: 3MDAEtBVfxN
--HG--
extra : rebase_source : 9a145d222b75b55cf184b319ba7404ba64f620d6
Made QR string consistent with respect to other url related strings
MozReview-Commit-ID: 432jaONccer
--HG--
extra : rebase_source : 44b50664e9602a11d82a1c1759b3e35e9f25e075
Added localization notes and more verbose strings for non-visual users.
MozReview-Commit-ID: FiOcDJrgRIy
--HG--
extra : rebase_source : 3fcaafc16e7bdbbeab881d16270b036b0a781cf4
Added contentDescription strings for QR Code and Voice Input
MozReview-Commit-ID: 6tpoewhPxev
--HG--
extra : rebase_source : 3ed1f0263f108ad63131f99168ee9879f83fbdb2
Strings needed for this feature were added in a separate bug - 1445798 which were causing Lint errors.
When this feature will land there will be no need for the suppression.
MozReview-Commit-ID: IhtTS8rHLwz
--HG--
extra : rebase_source : 6c09445f7f8c6f6fb565f41e57f666e9cfc26627
Because Mma cannot work if Health Report is disabled by the user (Settings - Privacy)
we will treat toggling Health Report on/off the same as we treat toggling the new preference from Settings - Notifications.
Toggling Health Report on will inform about the need to start LeanPlum (useful if the user did not explicitly stopped LP notifications but only Health Report which in turn disabled LeanPlum also) but there are other checks made afterwards (BrowserAp() is informed about this which calls GeckoPreferences.isMmaAvailable(..)) to decide if LP can and should be enabled.
Toggling any of these preferences will trigger an event caught by BrowserApp which can either
- immediately initialize LeanPlum (if the toggle was off LP is not running) as it would normally do when the app first starts
- stop LeanPlum reporting to servers, flush the per-session available messages
and resets the LP started status so that it can be restarted in the same app session (like if the user toggles the feature again)
MozReview-Commit-ID: 1SmhN0NucWW
***
--HG--
extra : rebase_source : b461677fd8a07d7c0c463e55c33bae1a3a973a1f
With the adding of the new preference that Mma depends on we need to have only one place where all the conditions for considering if Mma is available are checked - GeckoPreferences.isMmaAvailableAndEnabled()
Added only one place from where the availability of the LP experiments should be checked as that currently involves two checks - MmaDelegate.isMmaExperimentEnabled(..)
Also renamed isMmaEnabled() from MmaDelegate() and initSwitchboard from BrowserApp() to better express what those methods do.
MozReview-Commit-ID: BCJqM9b5JbW
***
--HG--
extra : rebase_source : 3c4b1707f69bfa5b39fe12ff45d8961b713f2291
According to current LP documentation there are no SDK APIs to allow users to fully stop LP: events reporting and message displaying there.
After extensive testing and investigations I think I found the least intrusive way to offer that.
We will use internal methods but which are public so I hope they will be supported in the future also. Nevertheless we will need to maintain this in regards to future SDK updates.
MozReview-Commit-ID: Ke3HGAyCqVA
***
--HG--
extra : rebase_source : e6510e12777ee3286742f00ae75d8ca69296989e
The behavior of this new preference is dynamic in that:
- it will be hidden if LeanPlum is not available for the device
- it will be toggled off and disabled if Health Report is disabled by the user
MozReview-Commit-ID: 1x9zZukyygr
***
--HG--
extra : rebase_source : c31ad02cbbb106613914634b5192f856aad185b7
