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
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
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
We introduced the "if ((flags & FLAG_BYPASS_CACHE_WHEN_DOWNLOADING_ICONS) != 0)" check,
and direct Bitmap scaling in Bug 1238656 to avoid getting the cached icon (which results
in downscaling) for apple-touch-icons (or just any icon that we're using for homescreen shortcuts).
However we need to make sure we can actually scale the icon before performing scaling, hence
this check should have been within our pre-existing "if (image_params_are_valid)" clause.
MozReview-Commit-ID: 4RdHmEia5FR
Sadly, this needs to be conditional to not burn builds where
MOZ_ANDROID_GCM is not defined -- such as aurora. As uplift is soon,
this will have to be relanded behind a conditional abstraction (just
like Adjust).
MozReview-Commit-ID: 80gBojadDic
I made all of the checks that:
* We pass
* Weren't already disabled
Into errors. There may be some checks we don't actually want, in which case we
can remove them from this list when we fail them.
MozReview-Commit-ID: 2vilkg9ppYE
Looking at [1], we halt_on_failure for the `postflight_build_mach_command`s and
the flag I flipped causes the lint command to return a non-zero exit code (i.e.
noting failure).
[1]: https://hg.mozilla.org/mozilla-central/rev/b7f1dac8306f#l2.29
MozReview-Commit-ID: 8v4am9zxxCk
As soon as the user clicks on a link to download a file Gecko will start the download - even before prompting the
user. This led to problems when the user hadn't granted the permission to write to the downloads directory yet. The
download would fail even though the user (later) accepted the permission.
With this patch we will start the download to the app's cache directory (only if we do not have the permission) and
prompt the user. As soon as the user has accepted the permission the download will be moved to the public downloads
directory (even while still downloading). If the permission is denied the download will be cancelled.
After the permission has been granted all subsequent downloads will start writing to the downloads directory
directly.
MozReview-Commit-ID: CCqk9h7Sxor
LoginsProvider is an all-Android implementation of PasswordsProvider.
PasswordsProvider is an SQLite database backed by the version of
SQLite that ships with Gecko. It is concurrently accessed from Gecko
and it runs with a special lifecycle that includes a separate
heavy-weight process. Eventually we'll migrate the Gecko-side
passwords interface to use the new Android-side LoginsProvider, but
for now we just want to get the new provider landed and the tests
running.
MozReview-Commit-ID: Bx19D68tMtI
***
Bug 946857 - Fold into part2: review nits.
MozReview-Commit-ID: LmPwIvebfrr
