So far we've simply assumed that the first MPEG Layer 3 frame sync we find is automatically valid. However if the audio data has been improperly cut, parsing might start somewhere in mid-stream, so the first frame sync we hit upon might be a false positive. This naturally leads to problems if we try to check later frame syncs for consistency (same MPEG version, sample rate, etc.) with that first frame sync.
Therefore, this patch changes demuxer initialisation to only accept a frame sync if it is followed by a number of further frame syncs consistent with the initial frame.
MozReview-Commit-ID: jVNGodIDEY
While processing restyles and starting transitions, we may trigger
a call to EffectCompositor::UpdateCascadeResults which may, in turn, call
EffectCompositor::RequestRestyle with RestyleType::Layer, which ultimately
results in a call to RestyleManager::IncrementAnimationGeneration().
Typically, nsTransitionManager::StyleContextChanged compares the animation
generation on its collection with that of the restyle manager and uses this
to ignore the restyle that it generates. However, given the sequence of events
above, that check may no longer help since the restyle manager's animation
generation will be out of step. As a result,
nsTransitionManager::StyleContextChanged will fail to ignore a subsequent
and redundant restyle. With certain combinations of content, this can mean that
restyles are posted in such a manner than an infinite cycle of restyles ensues.
This patch causes RestyleManager to ignore calls to IncrementAnimationGeneration
when it is already processing restyles such that the animation generation is
only ever updated once per restyle. This makes the check for a matching
animation generation in nsTransitionManager::StyleContextChanged work as
expected, preventing us from generating needless transitions which can produce
this endless loop.
MozReview-Commit-ID: 9HYDrknKPAI
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
I think it is possible for the TimerCallbackHolder to fire off a
Notify() while the geolocation object and the nsGeolocationRequest are
only holding each other alive, so they would be freed by the cycle
collector the next time it runs, but we haven't run the cycle
collector yet. If that happens, then Geolocation::RemoveRequest()
would break the cycle, causing stuff to unravel and bad things to
happen. To fix this, we just hold the request alive in
TimerCallbackHolder::Notify(), which will also ensure that the
geolocation object is alive, hopefully preventing crashes.
This will make the Notify() behavior similar to what it was before bug
1238427, when the nsITimer object would hold a strong reference to the
request when the Notify() was being run.
