| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
| |
There is a report of the 'oh' parameter missing from some of the icon
images, which is used as the checksum. The solution is to simply use
the URL itself as the checksum in the *rare* case the 'oh' parameter
is missing.
|
| | |
|
| |
|
|
|
|
| |
This fixes an improper GError propagation, which not is only incorrect,
but also has no effect. This ends up leading to the unsupported XMA
message being ignored without any notice to the user.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes Facebook will sent a batch of duplicated messages over the
MQTT stream. There are occasions where Facebook will send duplicated
messages which are not sequential, however, it does not occur at the
rete of the sequential duplication. This is likely due to the fact that
the plugin is using an older revision of the Messenger protocol.
For now, we should attempt to ignore sequential duplicates from being
from being display. This fix is not bullet proof, but it is simple, and
should cut down on the duplicated message spam.
The proper fix is likely going to be to update the plugin to use a more
recent Messenger protocol revision.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Often times, the MQTT stream is disconnected by Facebook for whatever
reason. The only thing I can think of is some sort of load balancing on
Facebook's end. It has also been reported that when a user logs out on
the Facebook website, their MQTT connections are killed. Whenever the
connection is killed by Facebook, the user is able to reconnect right
after.
In order to make for a quieter experience, the plugin should attempt
to silently reconnect before notifying the user of an error. This is
done by relying on the sequence identifier and the message queue to
ensure everything remains synchronized for when the connection returns.
|
| |
|
|
|
|
|
|
|
|
|
| |
This ensures a message is sent successfully before attempting to send
another message. As a result, messages are sent in their proper order,
instead of the order in which they arrive. This also introduces a check
for the successful sending of a message, rather than silently failing.
The queued sending also ensures messages are not lost when the state of
visibility is being switched. This also allows the plugin to silently
reconnect when a connection failure occurs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plugin is required to read Thrift data for the presence states of
contacts. The data which is being read has some optional fields, which
are rarely not supplied. This has led to this bug being undiscovered
for quite some time.
Not only was the plugin not properly accounting for optional fields,
but also did not account for field scoping. This is not really an issue
until a Thrift list is being read, which will cause the identifier to
grow with each field read, rather than reset. The field identifier is
only relevant to its local scope, nothing more. More importantly, the
identifier must be reset with each iteration of a list.
|
| |
|
|
| |
This is a regression introduced by 00c0ae8.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When fetching more than 500 contacts, multiple requests must be made in
order avoid request limits. When friends are retrieved and processed,
the plugin must keep a count of the processed contacts to know whether
or not it needs to retrieve more contacts.
Currently, this counter assumes every contact is a friend, which is not
always the case. This counter needs to advance even when a contact is
not a friend.
This fixes the incomplete fetching of the buddy list when a user has
over 500 friends.
This is a regression introduced by 00c0ae8.
|
| | |
|
| |
|
|
| |
This regression was introduced by 00c0ae8.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
By not swapping uid with oid, since the latter is always 0.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
It was assumed there was always a leading "NULL" byte prepended to each
message. This is not the case, the NULL byte is actually a variable
integer, which is the size for a Thrift string. In order to navigate
directly the JSON data, just read the data as a thrift string in order
to obtain the offset of the JSON data.
|
| |
|
|
|
|
| |
Simpler and more verbose version of my other patch which silently
created a new queue - this will show up as a reconnection and should
make it obvious if an infinite loop happens. jgeboski's idea, not mine.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Fixes issues such as losing messages that include a quote character.
Only escapes the minimum needed to work - control characters,
backslashes and quotes. UTF-8 chars are still valid json, so they are
sent as-is.
|
| |
|
|
|
|
|
|
| |
This reverts 68c46dd. While the sending queue attempted to ensure each
message was sent in order, it also lead to a significant delay in the
sending of messages. This is due in part to Facebook taking upwards of
a minute or more to reply to a message being sent. Moreover, the queue
is not really needed unless messages are being spammed.
|
| | |
|
| |
|
|
|
| |
This enables various format string security checks by the compiler in
attempt to avoid run-time failures.
|
| |
|
|
|
|
|
|
|
| |
This removes certain topic subscriptions which are of no importance to
this plugin. This results in the usage of slightly less bandwidth.
This also forcibly unsubscribes from the message notifications topic,
which seems to cause the connection to die out randomly when messages
are sent.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
