A more complete solution would rework our fullscreen support to ensure the
flags are consistently used (e.g. reader mode just uses low_profile even though
ActivityUtils.setFullScreen does both low profile and fullscreen).
--HG--
extra : rebase_source : ecffff89ea2c6b6c4145626398e458623f6c773b
This patch does several things, all in one commit because of a schema update:
* Uses _id instead of guid when referring to reading list items, allowing the guid column to be null.
* Reworks schema upgrading.
* Completely revises the reading list schema itself.
* Fixes the tests.
* Cleans up how we do deletion: if an item hasn't yet been synced, it's simply deleted immediately. We can do this because the server allocates GUIDs.
* Adds columns to manage sync-related metadata.
This does not always work in the case that one of the last few tabs (to the
right) are selected and the device is rotated from landscape to portrait.
Filed bug 1134408 to track this.
--HG--
extra : rebase_source : 60d64fbea4e8e32e14f1e8120a32d8c6db76b30f
extra : source : e755879c138c1a3ca96ba9da9f9244cb5bfd755f
The Android ARchive contains the compiled Gecko libraries that Firefox
for Android interfaces to. It does not contain the Gecko resources
(the omnijar, omni.ja) nor the compiled Java code (classes.dex).
This also uploads metadata and sha1 hashes for future consumption by
Maven and/or Ivy dependency managers. In some brave future world,
we'll work out exactly what that looks like; for now, this solves a
storage problem (each .aar file is ~20MB) and it's possible to point
Gradle directly at the uploaded Ivy metadata and artifacts.
--HG--
extra : rebase_source : 0c12b44f587d4a027ca5258bae8fcbb6f6028c24
Sometimes it's convenient to want to do an UPDATE query like:
UPDATE foo
SET bar = bar | 5
or similar -- that is, refer to existing values in the SET expression.
This patch allows that, accepting an array of ContentValues and an array of
operations as input. A single UPDATE will be constructed from the entire input.
This does not always work in the case that one of the last few tabs (to the
right) are selected and the device is rotated from landscape to portrait.
Filed bug 1134408 to track this.
--HG--
extra : rebase_source : f9071610c50fc344d55e54876252c7e2cdca09bd
BitmapFactory seemingly can't handle resource aliases:
http://stackoverflow.com/a/14553767
Note that this bug affected all phone devices, not just 2.3.
Also removed some unused imports while I was at it.
--HG--
extra : rebase_source : e8385a3d132176913922a182f6562618629d3d3c
We couldn't do this before because the button declaration was shared by old and
new tablet - this is no longer a problem now that old tablet is no longer in
use.
--HG--
extra : rebase_source : 4b60fe6ca371e783c8cc648568b8af7ec8791396
extra : source : fb066050757e614338dd185e6f99cfdbdbf818ec
As a cleanup, this required the move of favicon -> favicon_globe and the
creation of new resources toolbar_favicon_default, which is aliased to
favicon_globe on phones.
--HG--
rename : mobile/android/base/resources/drawable-hdpi/favicon.png => mobile/android/base/resources/drawable-hdpi/favicon_globe.png
rename : mobile/android/base/resources/drawable-large-hdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-hdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-large-mdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-mdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-large-xhdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-xhdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-large-xxhdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-xxhdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-mdpi/favicon.png => mobile/android/base/resources/drawable-mdpi/favicon_globe.png
rename : mobile/android/base/resources/drawable-xhdpi/favicon.png => mobile/android/base/resources/drawable-xhdpi/favicon_globe.png
extra : rebase_source : 8e43b8c4a04ccc8be7489385de5bd8d3f60058eb
extra : source : efa9411df1c4c1ea74fcdde7b5c3fc8a88725d79
As a cleanup, this required the move of favicon -> favicon_globe and the
creation of new resources toolbar_favicon_default, which is aliased to
favicon_globe on phones.
--HG--
rename : mobile/android/base/resources/drawable-hdpi/favicon.png => mobile/android/base/resources/drawable-hdpi/favicon_globe.png
rename : mobile/android/base/resources/drawable-large-hdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-hdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-large-mdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-mdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-large-xhdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-xhdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-large-xxhdpi-v11/new_tablet_default_favicon.png => mobile/android/base/resources/drawable-large-xxhdpi-v11/toolbar_favicon_default.png
rename : mobile/android/base/resources/drawable-mdpi/favicon.png => mobile/android/base/resources/drawable-mdpi/favicon_globe.png
rename : mobile/android/base/resources/drawable-xhdpi/favicon.png => mobile/android/base/resources/drawable-xhdpi/favicon_globe.png
extra : rebase_source : ca4b33706dcc41499f42f029aeb7afd2eac3ab2e
We couldn't do this before because the button declaration was shared by old and
new tablet - this is no longer a problem now that old tablet is no longer in
use.
--HG--
extra : rebase_source : 1e798b1d2c66af5e34d8ddbc14db06d94665f5e7
Scrolling was intentionally disabled - I'm not sure why that was the case so
this could end up backfiring.
--HG--
extra : rebase_source : 8c36347bb2f3ce6c90722d002bf21d541c8d9282
Ideally, we'd want to create a new instance of the share overlay on each call
but Android L changes the behavior and forces reuse (bug 1137928). Ugh.
--HG--
extra : rebase_source : e71ee7924c0cefd9bcce92e46d5dfb7c50fab1a7
Note that the ActionProvider's cache is not aware of when devices are added or
removed (i.e. a sync occurs) so there can be inconsistent states.
Also, we rely on the ClientsDatabaseAccessor to get the client count, but this
database is not purged when an Account is removed from the device and can
contain stale information.
--HG--
extra : rebase_source : b4f28552f9083b440f3753211f8627cb0e3f1827
The alternative is to remove "Add to Firefox" entirely via the
ActivityChooserModel and add a "Send tab" Activity. Fairly comparable solutions
but this one requires less work - there is no need to refactor the existing
ShareDialog and the classes it depends on.
--HG--
extra : rebase_source : 3665bded4589341fcc4ee6674aa4379cca997b83
Defines a viewport factor around the highlighted word
May need more testing (See bug 1015395)
--HG--
extra : rebase_source : 81f45a18f8ca8c9a3787522805933a1f801efc00
These patches are intended to work around theorized issues with the
Android caching of per-Account user data. They include diagnostic
logging to help understand the state of data on disk, small changes to
the read/write sequence, and a dramatic reduction of getUserData
calls (by maintaining an in-memory cache).
========
dcd54869d1
Author: Nick Alexander <nalexander@mozilla.com>
Bug 964854 - Part 2: Maintain write-through memory cache of Firefox Account bundles.
This should avoid reads from the Android Account user data store, which
we theorize is buggy. It trades those reads for the complexity of
maintaining and invalidating an in-memory cache, which has the potential
to avoid races and cache corruption.
There is no reliable way to determine if an Account has been
removed (and subsequently re-added), so we clear the cache entirely when
any Firefox Account is added. We do this at the authenticator level,
which should be more inclusive than doing it at the AndroidFxAccount
level.
I put the cache itself in AndroidFxAccount, since that is where we have
been storing things associated to the Android Account object; but it
could just as well go in the authenticator.
========
8d65b5dba9
Author: Nick Alexander <nalexander@mozilla.com>
Date: Tue Feb 10 10:42:27 2015 -0800
Bug 964854 - Part 1: Avoid back-to-back setUserData calls.
This is merely a stab in the dark, but if we are in fact seeing caching
errors, perhaps we're tickling them by writing twice when we could write
once.
========
42caec6ee1
Author: Nick Alexander <nalexander@mozilla.com>
Date: Tue Feb 10 10:40:16 2015 -0800
Bug 964854 - Part 0: Change logging.
For the details of why layout_width="0dp" is correct, see:
www.chess-ix.com/blog/the-use-of-layout_weight-with-android-layouts/
--HG--
extra : rebase_source : b023733363db30e988f23d1edcfceb1e0400111e
I have tested and see no issues with hiding the checkbox when the
service is build-time disabled.
========
d2890e5747
Author: Nick Alexander <nalexander@mozilla.com>
Date: Mon Feb 9 15:47:59 2015 -0800
Bug 1123116 - Include Reading List checkbox in status activity.
We're careful to only show the checkbox when the service is compiled in.
This is a reasonable-sized refactoring underneath a small feature-patch.
The refactor reworks what information we maintain (and pickle) about
"enabled" services. We've moved from a boolean "Sync enabled" flag to a
map of Android authorities (which map to services like Firefox Sync and
reading list) and boolean flags indicating whether each authority is
"automatically synced". The checkboxes in the status activity
correspond directly to whether the authority (service) is automatically
synced.
The set of authorities we care about is determined by the DEFAULT_* map.
Said map is interrogated and written to the pickle file at Sync time.
When the pickle file is un-pickled, only the set of known authorities is
acted upon. What that means is that both writing and reading a pickle
file with different sets of authorities should work across upgrades: if
a known authority is missing, the default value will be used; if an
unknown authority is present, it will be ignored. This lets us alter
the set of known authorities via the build flag.
I have tested and Android maintains the "sync automatically" state for
an authority even when the authority is not present in the list of sync
checkboxes.
All in all, I'm not concerned about toggling the build flag multiple
times in the future. (If we backed out the updated pickling code, we
would need to handle pickle downgrades, but we already needed to handle
that.)
========
fc8936549a
Author: Nick Alexander <nalexander@mozilla.com>
Date: Wed Feb 11 10:37:34 2015 -0800
Bug 1123107 - Part 3: Include Reading List checkbox during account creation.
We are careful to show the checkbox only when the reading list service
is enabled.
========
c90ea353cc
Author: Nick Alexander <nalexander@mozilla.com>
Date: Wed Feb 11 10:31:15 2015 -0800
Bug 1123107 - Part 2: Thread authorities to sync automatically through sign up/sign in flow.
========
e0c4d20744
Author: Nick Alexander <nalexander@mozilla.com>
Date: Mon Feb 9 12:35:15 2015 -0800
Bug 1123107 - Part 1: Manage map of automatically synced authorities.
========
7f7e308190
Author: Nick Alexander <nalexander@mozilla.com>
Date: Mon Feb 9 11:54:54 2015 -0800
Bug 1123107 - Part 0: Remove "account needs to be enabled" warning in status activity.
As we move Sync to a model where a status checkbox sets whether a single
ContentProvider is synced, it no longer makes sense to message when the
"account" is not automatically syncing.
This is the approach we already take everywhere else we make a jar🫙 URI.
I've unified those places into GeckoJarReader, cleaned up imports, fixed a
typo, and wrote a trivial test for this case.
I made a few utility methods static to facilitate testing and future refactoring.
Centralizing reading list access logic will make Bug 1130461 much easier. This bug is the first part of that.
We follow the same pattern as for URLMetadata, TabsAccessor, and Searches; BrowserDB hands over a single class that's specialized to handle the Reading List.
This is the approach we already take everywhere else we make a jar🫙 URI.
I've unified those places into GeckoJarReader, cleaned up imports, fixed a
typo, and wrote a trivial test for this case.
I made a few utility methods static to facilitate testing and future refactoring.
Moves nsSidebar.js to toolkit and makes it just pass messages to chrome for each
API call. MainProcessSingleton listens for those messages and passes the call
along to the search service.
Combines the validation code into the same function and takes the opportunity to
support relative URLs too.
Adds a bunch of tests for these web APIs.
Also fixes:
Bug 518929: Implement window.external APIs in core code
Bug 530847: Remove Fennec's nsISidebar implementation once that code is moved into the core
Bug 517720: Adding a search engine using relative URIs is not supported
--HG--
rename : browser/components/sidebar/nsSidebar.js => toolkit/components/search/nsSidebar.js
extra : rebase_source : 3e9caa49383e78e73e5f111ff09fb063f2cfa7c0
