Note, the effect of this change varies as follows:
(A) New users:
(B) Existing users who have never opened Settings->Advanced:
- Tabs will restore by default
(D) Existing users who have explicitly set the preference to disabled:
(D) Existing users who visited Settings->Advanced, without explicitly opening this preference:
- Tabs will not restore by default
(The preference already has a value set, hence the default has no effect)
MozReview-Commit-ID: DjMeEcYhusj
This is no longer needed - TransitionAwareCursorLoaderCallbacks was the only
consumer - it was removed as it caused race conditions. The ideal future solution
is probably to use recyclerviews to avoid jank, rather than trying to wait for
transitions to happen.
It's also extremely difficult to use this correctly - the
TransitionAwareCursorLoaderCallbacks simply held the cursor that would usually
be swapped in onLoadFinished until transitions have finished (which is incorrect,
since cursors need to be swapped in before onLoadFinished returns). It's hard to imagine
any alternative solutions, short of avoiding loading cursors in the first place (which
isn't too useful, since cursor loading happens in the background, at which point the UI
status is irrelevant), or hacking the CursorLoader to not return from its worker thread
until UI transitions are done (which would require a new thread-safe implementation of
TransitionsTracker), or maybe even hacking Android Framework's AsyncTaskLoader to not run Loader.deliverResult
while transitions are running (which seems awfully brittle and hacky).
MozReview-Commit-ID: 3JWDcznYL4Y
--HG--
extra : rebase_source : 1b4f52d84b21e4d93ebfb2d5c8d633c6ad12cf8e
extra : histedit_source : 2625e74aa08efa085733d3d34c6a2fa8550cf9f9
TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader
cursors _must_ not be used after onLoadFinished has been called. However
we sometimes queue the cursor swapping (which is implemented by subclasses
in onLoadFinishedAfterTransitions) until after transitions have finished.
CursorLoader.deliverResult() closes the old cursor immediately after calling
onLoadFinished (with the new cursor). At this stage the adapter is
still holding onto the old (but now closed cursor), and will crash if it tries
to read this cursor (which can happen if the adapter is still iterating over the
cursor).
Instead we should ensure that we swap the cursors during onLoadFinished - the simplest
way to do this is by eliminating TransitionAwareCursorLoader and using onLoadFinished
the way the Android framework expects.
It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added,
home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about
its transitions. However HomePagerTabStrip no longer exists, hence there's no need
for us to care about these transitions anymore. (The crash seems to happen because we
try to hide the doorhanger every time we receive LOCATION_CHANGE, and each of these starts
a hide transition - even if no doorhanger is shown - hence we often have a transition
in progress every time we show topsites.)
MozReview-Commit-ID: HsytLpHOrp2
--HG--
extra : rebase_source : 0411e017e19bb4393368b175418a41b0129a622b
extra : histedit_source : 19e68ed7f68180122b7514849b5dad4e246784cb
The way set_config is set currently makes it difficult to introspect
moz.configure files to know what configuration items are being set,
because they're hidden in the control flow of functions.
This makes some of the moz.configure more convoluted, but this is why
there are templates, and we can improve the recurring cases afterwards.
AppCompat capitalizes all text in `Button`s so we have to override
that behavior to maintain the same UI. Ideally, we do this through
`android:buttonStyle` but the place I found the issue doesn't inherit
from that style so we can't and we change the style directly.
There may be issues with other `Button`s, but this is the only one I found.
MozReview-Commit-ID: JQoIlPa9oZD
--HG--
extra : rebase_source : debbb2076a5b339d25dc38c46ccf5e3ce07a0613
extra : source : f774157cf5f423be9a096ed5072b4440d68f4bd1
The pref handler class in GeckoPreferences doesn't need a reference back
to GeckoPreferences, so it's better to make it a static class rather
than a (non-static) anonymous inner class, in order to avoid leaking
the GeckoPreferences instance inadvertently.
To avoid confusion, the patch also renames the class to "PrefCallbacks",
because GeckoPreferences already has an unrelated interface named
"PrefHandler".
HomeConfig.java saved a list of events to be sent later in a batch. This
patch makes it save a pair of strings instead, and the strings are later
used to make calls to GeckoAppShell.
The patch also makes two small optimizations. It makes the queue an
ArrayList instead of a LinkedList to save memory. It also makes copying
the queue a swap instead of a true copy.
On a CLOSED TREE -- Android and automation only.
MozReview-Commit-ID: AU8bt4CDC1V
--HG--
extra : amend_source : ff83d4b0513102abf095949a79bf7f7616bbfa14
extra : histedit_source : 576ce07d4f7d2ea9d1ae1997736cfe59d751be6d
The initial --with-gradle support disabled building the Android test
directories; everything was built from
mobile/android/app/build.gradle. That doesn't declare support files
that need to be packaged for Robocop tests. This patch stops building
instrumentation test APKs, which aren't used in automation under any
circumstance and which aren't packaged when building with Gradle; and
avoids building the Robocop APK by tweaking the Makefile. That gets
support files in place while not using moz.build in place of Gradle.
I would have declared the support files elsewhere, but there are path
requirements that I couldn't make work, so in robocop/ they stay.
MozReview-Commit-ID: KCpXvqzYBsY
--HG--
extra : rebase_source : b99be8fada7787ee473f68265824cca2250c70a1
extra : histedit_source : fa19d3ede51e14707f400ab8527d44f5bf550f85
This also adds a GRADLE_FLAGS environment variable for use in
automation.
Manually tested.
MozReview-Commit-ID: 8nDkqz2VnJn
--HG--
extra : rebase_source : 32626a7dc0c0a6a440e300d92c31670f14319325
extra : amend_source : fe134e25f079851b4c648b53a7a485ee20c15c18
Bug 1242213 removed the entire <activity-alias>. Sadly, users who
added the Firefox icon to their dock (for example, Samsung's Touchwiz
dock) will see the icon disappear when they upgrade, because the
intent filter disappears. (That is, the icon is connected to .App and
action MAIN, not to the package and action MAIN.)
This patch restores the .App <activity-alias> for action MAIN. It
doesn't add the launcher and other categories, which could lead to
multiple launcher icons. New users that add the Firefox icon to their
dock will use .BrowserApp, but sadly we'll need to maintain this alias
essentially forever to support existing dock icons.
MozReview-Commit-ID: 1o9XS5MEs1s
--HG--
extra : rebase_source : 8f4e1321da475bf2dcfca88c5807bf26c940b1c5
extra : amend_source : 3429ff0eaec0edb02e5e47678252bf5a2de74d3f
This permission was added in API 16, and is only enforced in API 19+.
(It's benign to add it to APKs installed on API 15.)
We want to declare it explicitly so that the bouncer APK and the main
APK have the same permission set. There appears to be some fanciness
with Gradle's implied permission system where the bouncer APK does not
request READ implicitly where-as the main APK does request READ
implicitly. This just makes things explicit (and uniform).
MozReview-Commit-ID: LBblAPa0duV
--HG--
extra : rebase_source : 616fa58ccd9063088abb14240265a20ac4e48da7
extra : histedit_source : abf6211896e99cc7b53f9c36714d056f0d44d63f
Pinned sites should be deleted directly, however I'm not confident enough
in my knowledge of sync to be certain that we won't end up with deleted
pinned sites in our table.
(We use normal bookmark deletion for removing pinned sites.)
MozReview-Commit-ID: SSLDkSXWlI
This fixes an edge case that is most likely to happen to new users if they pin a site followed
by removing one or more suggested sites. This results in the topsites table containing
less sites than needed, leading to some pinned sites being displayed in a higher
than expected position. This also broke unpinning since our code assumes
that a topsites physical position corresponds to its DB position (which prior
to this patch was not the case).
MozReview-Commit-ID: JgTUa55eXnz
This variable was renamed to be positive instead of negative but the value/usage wasn't adapted.
MozReview-Commit-ID: H1DeZMmvTXC
--HG--
extra : amend_source : a83d5ae3f1c7525031c17cdb4fa0f4950f6aa7c2
