The session store relies on a few event listeners to track the history and life cycle of a tab. Under memory pressure, background tabs are zombified in order to reduce our memory usage. This involves destroying the original tab object and then recreating it as a delay loaded tab.
As the session store is never told about this, it will keep the event listeners for the old tab objects - which have now been destroyed - alive and won't receive any future events for the new tab objects. This means that once a zombification has been triggered, the session history for those tabs will become effectively frozen, so after the next zombification or a session restore, the tab will reload the wrong page.
Therefore this patch introduces two new events which are sent during the tab zombification process and allow the session store to detach its event listeners from the old tab object before it is going to be destroyed and subsequently reattach its listeners to the new tab object.
MozReview-Commit-ID: 6xZtsCNZbQY
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 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
