| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
| |
Shot in the dark to fix checkpoint issues, but had to be done anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #89 (No matches for $.represented_profile.id)
Previously, in 4efa397, hugePictureUrl was made optional. Now someone
complains about represented_profile being missing, replaced with a null.
To be honest I'm worried about what kind of bug might be breaking things
so subtly on the server side, but well, it's not my job.
This will result in some friends with missing represented_profile not
being included in the contact list, because we're missing rather
essential information. But better than not being able to log in.
|
| |
|
|
|
|
|
|
|
| |
I'm still not sure about the origin of these errors (I suspect it's a
race condition between servers), but it's going to be fixed properly in
the future when the sync protocol is updated and doing HTTP requests to
get the attachment URL is no longer required (newer orca versions only
do HTTP requests to get the url of file attachments, everything else is
included in the MQTT stream)
|
| |
|
|
|
|
|
|
| |
Facebook seems to randomly send null in this field sometimes. It's not
very important so it can be made optional.
This includes moving the checksum code (which was previously duplicated)
to a separate function so that there's a single null check.
|
| |
|
|
|
|
|
|
|
|
|
| |
Mostly fixes bug #76
This is crappy and error prone, just like the rest of the duplicate
message handling code. It works, but it's going to get some echoes now
and then, particularly in quick moving groupchats.
I'm pretty sure this is a bug in the server, but the official clients
have much more elaborate deduplication built-in, so they won't notice.
|
| |
|
|
|
|
| |
This fixes contact list fetching for accounts with more than 500
friends, which only got the first page of results. The previous method,
using graph_api_write_id, stopped working at some point.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
