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
--HG--
extra : rebase_source : c1811061ac3448666730426b353941bfe3d4814e
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
--HG--
extra : rebase_source : 2b80c8f2beb7939e1f556e91bca87b60ebe4368e
This caused a StrictMode violation on startup.
MozReview-Commit-ID: Ip2ywUoexOh
--HG--
extra : rebase_source : 12bb7cc010b82a03f80f8c1b9a01e9acbf67c13c
extra : source : faa74a9297c8476f965a5f9268d5b9095458dd2b
String resources are shared with the main app menu, and will therefore be remove
in Bug 1234319 which aims to remove those items.
MozReview-Commit-ID: 1NUBskBC10l
--HG--
extra : rebase_source : 579955aa6f10322a57105947a0b25065dbe92c55
extra : histedit_source : d09a951b2e661d80c8270dc12f0c08cc1eb62930
We'll kill this panel in a few weeks, hence we don't really care about
duplication here.
MozReview-Commit-ID: 5XSS3ROa5P3
--HG--
rename : mobile/android/base/resources/layout/firstrun_sync_fragment.xml => mobile/android/base/resources/layout/readinglistpanel_gone_fragment.xml
extra : rebase_source : ce339a412d248a51c8d9cf5250a7b91b3876f711
extra : histedit_source : 481e705dc0a75d92e166ff0a5a27206189d4a8f0
We will already switch to the currently open tab, so we need to ensure we
show the "switch to tab" indicator.
MozReview-Commit-ID: 9q1kDM2flSi
--HG--
extra : rebase_source : 6fddaf7da9de4ea5944e4b7c1c5ff43738cce218
extra : histedit_source : 4f2e57c2ce178aecd80a04b1e842b0e2b29b0ac2
This means we can see the readercache availability not only inside bookmarks, but also
in most other parts of the awesomescreen, since we use TwoLinePageRow for most items
(history, bookmarks, topsites, search results etc).
MozReview-Commit-ID: 8SxE8VabIK9
--HG--
extra : rebase_source : b06d945cbe31b93e21c3a171f53cc9f6143de8d8
extra : histedit_source : ab8eab075e3fc6123f9694561140e306df5375db
We hash the page URL to produce a filename for each cached reader view page. For the purposes
of the rl-migration we need a Java implementation, however the canonical implementation
lives in the current JS readercache (which might be removed in future...). This test
should help ensure that we don't lose saved items during the migration.
We could extract getReaderCacheFileNameForURL(), however it seems safer to make it
public instead - this makes it obvious that this is a migration-only method that
shouldn't be modified/reused in future.
MozReview-Commit-ID: GNg20nszMh9
--HG--
extra : rebase_source : 33af7e38fa7e74287515bcf5cf2521978d8978a0
extra : histedit_source : 9fe9fcae7595b450491a0fb482ffdc73b5b6f344
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
--HG--
extra : transplant_source : %BC%7Ci%20%82%1E7%29%9E%0E7%87%ED-%0B%E0%84%86R%F9
Carsten "Tomcat" Book
Michael Comella
Chenxia Liu
Wes Kocher
Geoff Brown
Andrzej Hunt
Andrzej Hunt
johndai1984
Junior Hsu
Kartikaya Gupta
Jan Henning
Ryan VanderMeulen
Nick Alexander
Mark Capella
Margaret Leibovic