Restoring a tab from the Recent Tabs panel, which goes via the session store's _restoreTabs() function and ultimately via BrowserApp.addTab() and a Tab:Added message back to the Java UI requires the value for isPrivate to be present in the session store data for the respective tab - if it isn't, we end up sending isPrivate as "undefined", which breaks the process of adding the new tab in our UI.
When the session store collects the full tab data for a browser, it always includes the values for isPrivate and desktopMode, therefore we now include those values in the basic session store data we use in initialising a new tab object, too.
MozReview-Commit-ID: 5BZ9PL7xDWA
* urlbar-show-origin-only: Only show origin in URL bar instead of full URL (Bug 1236431)
* urlbar-show-ev-cert-owner: Show name of organization (EV cert) instead of full URL in URL bar (Bug 1249594)
This avoids a problem where a lifecycle method may assume a previous lifecycle
method initialized some values but we returned early (e.g. on a not supported
system) so these values were never initialized and the application may crash.
I tested this patch by forcing HardwareUtils.isSupportedSystem to return either
true or false (but both were in a supported device configuration).
MozReview-Commit-ID: 1WvOId8CLjP
This patch restores our previous <activity-alias> with all intent filters. Changing the alias
will cause that existing home screen shortcuts disappear.
I tested this patch with:
* Upgrading old state (2016-02-06) to current state: Icon disappears (expected)
* Upgrading old state to fixed state (this patch): Icon remains
As this patch changes the activity-alias again, releasing this patch will lead to the home
screen shortcut disappearing once more for all released version with the current state:
* Upgrading current state to fixed state: Icon disappears (expected)
MozReview-Commit-ID: 1crKmkp4G1L
When opening a new tab, there is a small window between tab creation and the DOMTitleChanged event firing where the tab - if it is not created as a delay loaded zombie tab right away - won't have any session store data. However a number of functions (tab zombification and restoring of zombified tabs, undo close tabs) depend on the session store data always being available, so things can fall apart if e.g. a zombification is triggered immediately after opening a new tab.
This also means that a tab which is zombfied immediately after its creation (e.g. when a number of tabs are opened through tab queues on startup) is not included in a session save and will therefore get lost if Firefox is killed.
Therefore, we now always intialise new tabs with some basic session store data.
MozReview-Commit-ID: 9248jJFUaq5
After this patch, I still occasionally see the toolbar positioned part
way down from the top of the screen. However, this state looks slightly
less janky without the animation I removed and I can't consistently
reproduce it anymore. Given the DynamicToolbar.setVisible calls I make,
I'd guess this is likely to be a bug caused by BrowserApp.onTabChanged
(and thus DynamicToolbar.setVisible) not getting called instantly and
so the DynamicToolbar is initialized to a different location on screen.
I'd guess it's a bug in DynamicToolbar as to why it's positioned partially
off-screen.
There is a little bit of code duplication, but that is because the code
to load a url on a new intent is duplicated (i.e. once from GeckoApp.initialize
- the initial load - and once from GeckoApp.onNewIntent). This could
potentially be cleaned up if we moved the app loading code into onResume,
but that may not be possible since we need to wait for Gecko to start
up.
Additionally, this patch adds a lot of hard-to-follow global state, which is
also not good.
Preferred solution (bug 1269041): show the toolbar each time onStart is
called (i.e. FF is unhidden). This is good for the user - they'll be
more aware which page they're on - but it's janky with the current
implementation, where the page content does not scroll when the toolbar
is shown so previously visible content is hidden. Thus, I went with the
other approach. fwiw, Chrome does this behavior, but scrolls the toolbar
offscreen shortly after it is shown.
This solution is blocked on bug 1245523.
MozReview-Commit-ID: 7JjCrIf4KTm
Android's Settings.canDrawOverlays() returns true/false for one of the packages with the same
sharedUserId. There's no guarantee that this is actually the current package.
Instead of relying on Settings.canDrawOverlays() we just try to add and remove an invisible
view through WindowManger. If this succeeds then we obviously can draw overlays and if this
fails then we seem to not have the permission.
Our theming inheritance around Preferences still seems quite messy, however given we'll
need to uplift this I'm planning to tackle this in a separate bug.
We add the LocaleAwareAppCompatActivity in order to avoid affecting other consumers
of LocaleAwareFragementActivity (primarily the SearchActivity). We will investigate
those separately.
MozReview-Commit-ID: KVEZbDdza1s
This patch introduces consistent theming for all supported devices (Android 4+).
Previously we had Jellybean theming on Android 4, and Lollipop theming on 5+.
Note that dialogs will be based on the native device dialogs (i.e. Jellybean on 4,
Lollipop on 5+). This is because we use native Fragments (and not support library
Fragments), which inflate their own (native) Dialogs. Introducing consistent
dialogs would involve replacing the use of native Fragments (and native
PreferenceFragments), and replacing our self-inflated dialogs.
(We have a few self-built dialogs - these could easily be switched to the AppCompat
AlertDialog, but then we'd have a mix of new and old dialogs on Android 4 devices,
since PreferenceFragment constructed dialogs would still be the native Android
dialogs - overall this would be a worse experience.)
It is also usable on 2.3. There, we retain GB theming, however the checkboxes
are replaced with orange checkboxes (as on 4+).
MozReview-Commit-ID: AXbyAfpvfKi
Android's Settings.canDrawOverlays() returns true/false for one of the packages with the same
sharedUserId. There's no guarantee that this is actually the current package.
Instead of relying on Settings.canDrawOverlays() we just try to add and remove an invisible
view through WindowManger. If this succeeds then we obviously can draw overlays and if this
fails then we seem to not have the permission.
MozReview-Commit-ID: 1jdrQ7iV3ek
Removing these checks causes crashes when trying to upgrade a <= 17 db to >= 23:
(A) upgradeDatabaseFrom17to18 calls createReadingListTable, and we create the table using the new (>=23 schema).
This schema has no "read" column.
(B) upgradeDatabaseFrom22to23 migrates the same table. As part of the migration it tries to select the "read"
column, and we crash because that doesn't exist. This was prevented by an early return if didCreateReadingListTable
was set.
It looks like removing the didCreateTablsTable checks is OK because the migration only adds a foreign-key constraint,
and doesn't depend on any columns that didn't exist in the initial version of the migration. However it seems wasteful
to run the migration on a table that is already in the expected state. Moreover not having table-created checks is
not safe in most cases, and having these checks should be the default pattern - especially in case any future migrations
affecting the same table are added.
MozReview-Commit-ID: 4j1PlQc6LLN
Additionally, added WeakReferences to the SEM in its callbacks so we can
GC ASAP if the Activity (and thus the SEM) gets GC'd. This is important
since we hold a reference to Context which can be a rather large object.
Furthermore, I added some related thread annotations where I felt they
were useful.
MozReview-Commit-ID: KaWlw14uOoN
The default search engine attribute may be null in the core ping if we haven't
been able to retrieve the value yet. It's unclear when this might be, but the
possibility is in the javadoc of `SearchEngineManager.getEngine`.
MozReview-Commit-ID: IrJB6GyjyTO
