This patch converts Bluedroid status codes in Gecko to the
backend-neutral data type |BluetoothStatus|. All error handlers
have been adapted. The Bluedroid type |bt_status_t| only remains
in |BluetoothInterface|.
With this patch |BluetoothHandsfreeInterface| is responsible for converting all
Bluetooth data types to Bluedroid types. All callers have been adapted.
This patch removes unsued code from |BluetoothServiceBluedroid|, related
functions, and cleans up the file. It
* removes callbacks,
* removes callback helper tasks,
* removes helper functions, and
* cleans up global variables.
Bluedroid callbacks were usually called on a separate thread that
was specific to this task. So Gecko's Bluetooth Core contained a
number of runnables for executing callback operations on the main
thread.
Since all notifications always run on the main thread, the extra
runnables are not required any longer. This patch integrates them
into the notification methods where possible.
This patch adds the Gecko-side of the Core notifications. The current
implementation of the notification methods has been copied from the
repsective Bluedroid callback methods, with only minor changes to adapt
them to Gecko data types.
A notification is a callback from the Bluetooth backend to inform
Gecko about a event. Bluedroid uses function pointers for this, but
in Gecko we use method calls instead.
Gecko implements notification handlers for the Bluetooth backend. The
backend converts incomming events to Gecko types and forwards them to
the registered notification handler.
This patch adds some runnable classes for running class methods on
the main thread. This is the base of the upcomming notification
mechanism for Bluetooth.
The assertion in nsTimeStamp::operator >= occasionally fails due to a null RHS
timestamp when called from AnimationPlayer::GetCurrentTimeDuration, which, in
turn, is called from AnimationPlayer::SetSource.
The issue appears to be that we're not correctly initializing
AnimationPlayer.mPlayState. This value can be running (0) or paused (1) but we
only ever compare against the paused state (i.e. every other value is
effectively treated as running). If we don't initialize this we can end
up in the paused state but with mPauseStart not set to a valid (non-null)
TimeStamp. This creates an inconsistent state since we assume that when we're
paused mPauseStart is non-null, hence the assertion fails.
This gets tickled because, since bug 1040543, we call
AnimationPlayer::SetSource from nsAnimationManager::BuildAnimations *before* we
set mPlayState and mPauseStart.
This patch initializes mPlayState to the running state so we don't accidentally
end up in an inconsistent state.
It also removes some (now unnecessary) initialization of mPlayState and
mPauseStart from nsTransitionManager::ConsiderStartingTransition.
In future we could also consider reworking nsAnimationManager::BuildAnimations
so that we call SetSource on the new animation player *after* setting up its
play state. That may be more correct and would further avoid this problem but
may not be necessary since all that code is likely to change in the near future.
This commit fixes two bugs. When sending two notifications with the same
tag, the NotificationDB this.byTag member was not properly updated. This
resulted in multiple notifications with the same tag being saved.
NotificationStorage's cache may hide this during the running session,
but on B2G the resend of notifications at reboot would expose the issue.
The second bug fixed is the test that makes sure we properly overwrite
notifications with the same tag in the database: the way we handled fake
notification object made them sharing the same ID. This, NotificationDB
would not even consider the tags and this lead to hiding the bug.
