Bug 832990 solved the issue of us losing the menu item cache if BrowserApp was
destroyed, however the issue remains that we'll miss any Menu:... messages that
are sent while BrowserApp doesn't exist, e.g. if Gecko is initially loaded
through a GeckoView-based activity.
Therefore we now move the menu item cache and the listener for those messages
into a separate class, whose lifetime better matches that of Gecko.
Apart from any necessary changes, we move the existing code as is. The only
additional change is that we make addAddonMenuItemToMenu() static, because we
can.
MozReview-Commit-ID: BJleonLnjmo
--HG--
extra : rebase_source : e36d954488cc44d250948edcbb8a1964e24ddab7
As a final step, these can be merged as well. The same reasoning as in the
previous patch applies with regards to additional functionality that isn't
(yet) used by webextensions.
MozReview-Commit-ID: Ezx2mQY0s85
--HG--
extra : rebase_source : 955462126312241ca860e8184507bd7ed4955450
The original add-on functions have some additional capabilities regarding e.g.
checkboxes, disabling the menu, etc. that right now aren't required for
Webextensions (yet?), but in that case they will simply not be used - in any
case BrowserActions.jsm controls what functionality is actually exposed to
add-ons.
MozReview-Commit-ID: DPT8gV2gb6q
--HG--
extra : rebase_source : 09a0a52c374c1c423002e9dcb5edc0c7e2730bbd
Now that the UI code for handling both the old NativeWindow API and Web-
extensions is more or less the same and both are using the same MenuItemInfo
class, there's no longer any real need to keep items added through the two APIs
in separate lists - in fact doing so makes it harder to preserve the ordering
of menu items if the activity and its menu are destroyed and need to be re-
created later on from the stored lists of MenuItemInfos.
MozReview-Commit-ID: KlJdvO9WhhY
--HG--
extra : rebase_source : 2d28262f72acaa0e0e6966f8309ef9569d3f6314
Now that both Webextensions and the NativeWindow API manage their onClick call-
back handling by UUID, we can start using the same EventDispatcher message for
both.
MozReview-Commit-ID: J3RRXrwPdTI
--HG--
extra : rebase_source : 7f136d70944641391e57a76efdec6546fe74cfd0
Since the NativeWindow API now only uses UUIDs as well when dealing with its
consumers, we can leave generation of the menu to the Android UI code of
Firefox.
MozReview-Commit-ID: 1qDLDnePfFE
--HG--
extra : rebase_source : d1320f92ebd4be0237d3da554a3f8182a0e72d4e
At the moment, the code for handling of JS-created main menu items is more or
less duplicated between the old NativeWindow API and Webextensions, with the
only real difference being that the former communicates directly via menu item
IDs, while the latter uses UUIDs for messaging between Gecko and the UI.
By switching the NativeWindow API to using UUIDs as well, we will be able to
start unifying this code again.
As for backward compatibility
- the return value of NativeWindow.menu.add is valid for the current session
only, so no migration is necessary
- the return value of NativeWindow.menu add was already effectively only an
opaque value which only had real meaning for subsequent calls to menu.add,
menu.update and menu.remove, so it shouldn't really matter whether we return
a plain numeric ID or an UUID in string form
- old-style add-ons are now unsupported for better or for worse and our one in-
tree caller won't have any problems with this change
MozReview-Commit-ID: HdRNhrx1pu7
--HG--
extra : rebase_source : 33ce855ac2f2f65fe20cb5047de3b8cbbcd094d9
We no longer use that value anywhere, so we can just stop keeping track of it.
MozReview-Commit-ID: D1IgX1t8SKI
--HG--
extra : rebase_source : 51288c866bdd078aed629590ad39b2f8d524d044
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
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
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 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
Created LeanPlumVariables to allow LeanPlum overwriting the values used for
populating the OnBoarding screens. By simply adding the @Variable annotation
to it's fields, on the first run of the app, they will appear in "LeanPlum
dashboard - Variables" and will allow overwriting for future runs.
The OnBoarding process will now try to use LeanPlum values if possible.
Because connecting to LeanPlum and downloading the Variables might take
a few seconds we use a delay of up to 3 seconds until starting to show
the Onboarding screens.
The default values will still be used if:
- if the LP experiment is not available
- if no internet connection
- if more than 3 seconds have passed and LP didn't finish it's download
Added two new events that could be tracked to Leanplum
MmaDelegate.ONBOARDING_DEFAULT_VALUES and MmaDelegate.ONBOARDING_REMOTE_VALUES
to inform if showing the Onboarding with server values was possible or not.
Because of the 3 seconds delay until showing the Onboarding panels leaking the
could be possible. Used WeakReferences for both the Activity in
OnboardingHelper and the OnboardingHelper in MmaLeanplumImp to avoid it.
MozReview-Commit-ID: H30e9Ng7jrM
--HG--
extra : rebase_source : e403b8010005aa82f8b6440586c533ce99952f9f
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
Fix all Java warnings in the Android codebase except deprecation and
serial warnings, and warnings in third-party code.
There is one required change to exoplayer2 code under thirdparty,
because that code is included directly in the geckoview project, instead
of the thirdparty project. I think I'll just make a pull-request to
upstream the change, instead of separating exoplayer2 into a
gv-thirdparty project.
--HG--
extra : amend_source : 29419a24db9b956a7f3ee573a63f7a055ed90636
Fix all Java warnings in the Android codebase except deprecation and
serial warnings, and warnings in third-party code.
There is one required change to exoplayer2 code under thirdparty,
because that code is included directly in the geckoview project, instead
of the thirdparty project. I think I'll just make a pull-request to
upstream the change, instead of separating exoplayer2 into a
gv-thirdparty project.
Use SharedPreference to ensure we won't loose previous state if Fennec is killed, set as default, restarted.
The default browser status will only be set once, when the app is resumed, as it cannot change while the app is in foreground.
We will track "E_Changed_Default_To_Fennec" only if Fennec wasn't previously the default browser.
The method to track the event is safe to be called even before the mma init process is finished as LeanPlum postpones the track operation until it has actually been started.
Refactored MmaDelegate to not use a WeakReference for application context anymore as that should exist for the entire time the app is open, and only in that timeframe the MmaDelegate methods that use that context can be called.
MozReview-Commit-ID: JMJJclWj9fq
--HG--
extra : rebase_source : a6b3c6b097dfacb348a4fd0bbf054dd0c14b2d4a
The app already sends "E_Launch_Browser" for when it is first launched.
MozReview-Commit-ID: 9BU6b3D58vY
--HG--
extra : rebase_source : eee5acb5e5142f378d4d80d663de29da88bb03c5
We cannot open completely new windows on mobile, but we sort of mimic desktop
by having Ctrl + N/Ctrl + Shift + P always open a new normal/private tab,
whereas for Ctrl + T the kind of tab opened will now depend on the currently
selected tab.
MozReview-Commit-ID: KmPCcnn79OH
--HG--
extra : rebase_source : 9a120de03816d2d140e5cb877b3996326491747b
Somehow I must have overlooked that during review, but if I'm touching something
in the neighbourhood I might just as well clean this up.
MozReview-Commit-ID: 95gnzSebGyf
--HG--
extra : rebase_source : 3f68ad9ecbdfea74dfc0ae6f4d65e3a90fe08081
When editing the URL bar, we're committing the input and starting a page load in
response to a key-down event for the Enter key.
We end up hiding the ToolbarEditLayout from within the key event handler, which
means that by the time we get the corresponding key-up event, input focus has
moved on and the key event ends up being dispatched to the GeckoView and
consequently to Gecko.
This means that loading an URL from the URL bar by pressing Enter will reset
millisSinceLastUserInput, which defeats our logic to distinguish URLs loaded via
the Android UI from those loaded by clicking on links within the content.
MozReview-Commit-ID: 3Wbnk3bnqVS
--HG--
extra : rebase_source : 65cb045a6e1e7380085f3ef502f7491a64421564
Function queryExists added to StringUtils to check
if a given URL allows for arguments.
Tests for said function added to TestStringUtils.
Function loadUrlOrKeywordSearch in BrowserApp.java updated to also pass
the entire entered string along regardless of whether or not the first
words are keyword bookmarks iff there is additional text after the
keyword bookmark, and the keyword bookmark does not accept any input arguments
MozReview-Commit-ID: 2eyi5Botd3F
--HG--
extra : rebase_source : a08dd11a1595051a2dc727cc361cebecc14fa8c8
Display a message on startup when the APK is corrupt. Right now the
"wrong SDK" message is displayed. I think we can potentially reuse that
message for Beta, but we need a different message for Nightly.
MozReview-Commit-ID: 9NEw252Ytkc
Longer term, the MenuItemInfo handling needs to be moved out of BrowserApp in
order to solve bug 1414084 [1], but the easier short term solution is to just
save the cached menu data via the savedInstanceState. This means that
MenuItemInfo and friends have to be made parcelable.
[1] Because of GeckoView, add-ons may load (and attempt to add menu items) while
BrowserApp isn't even alive.
MozReview-Commit-ID: HzPe7ZKbJOj
--HG--
extra : rebase_source : a38d3119c863ca48fdbd068b634c76681a3bfd34
It was only used in the 55 Nightly and never meant to stay around.
MozReview-Commit-ID: JDJr9WC4V5M
--HG--
extra : rebase_source : af52eb24c4d599651a4cbde7b00049272448c9e6
The Page menu is disabled when no tab is open, so not doing a null-check on the
currently selected tab in the menu click handler is safe.
MozReview-Commit-ID: CYKHJ5N1q8I
--HG--
extra : rebase_source : 3ec7b1a9708a905785850feb44b48723c24f1363
Early during startup there might not be a selected tab yet, so we can't use its
data to decide which home panel to show again.
Fortunately showHomePager can be called with a null panelId, in which case it
will eventually simply fall back to using the default home panel from our
settings.
MozReview-Commit-ID: GbmozJeYZVb
--HG--
extra : rebase_source : 0ed294b6820faa1934105c2719460dd7bef1a852
Similar to maybeSwitchToTab in bug 1426613, a search might be launched while we
don't have a selected tab yet. Therefore we determine private mode state via the
browser toolbar instead.
MozReview-Commit-ID: 4idUR8v7MCx
--HG--
extra : rebase_source : 7104ffbb752b6c0d499b85c47910168391291797
The currently selected tab might not actually exist immediately after startup,
in which case the browser toolbar is a safer bet for determining whether we're
in private mode or not.
I think the current worst case is when we're
- not restoring a previous session, and
- need to open some tab queue tabs, and
- also need to open some other tab in response to our launch intent
in which case we won't have a selected tab in Java until after Gecko is up and
running. This in turn can take a while, especially when a fresh copy of
libxul.so needs to be extracted after an update/installation/cleared cache/...,
which potentially gives the user ample time to click on a search result/Top
Sites entry/... that then triggers this crash.
MozReview-Commit-ID: FlJZw2aL8OM
--HG--
extra : rebase_source : 41f6bb1e83d4f47c1ba04f8ce919753a14dfd9c6
The technique for setting our icon is just a straight reimplementation
of bug 1210242.
Because of the way the new tab might be opened from within a
processActionViewIntent Runnable, we can't enter editing mode by simply
listening for an ACTION_ASSIST intent from within BrowserApp, as we need to
enter editing mode *after* the correct tab has already been opened and selected
and BrowserApp doesn't get any hint on when that Runnable might have run.
Instead, we introduce a new tab event, so we can trigger editing mode at the
right time via the tab itself.
MozReview-Commit-ID: 8Bvv5TXyhhI
--HG--
extra : rebase_source : 92f6131098e1c2a8e810431aa82e68e7e422cfd1
