| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Check for pointer to be NULL before dereferencing it.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1342
|
|
|
|
| |
Instead of connection_get_fulljid() and then creating a Jid from it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With d1d0ad8d1a8e28690aa8723566dd64c1ccdcf9d6 we set a timestamp to now
for all messages upon receival. Even if the original message didn't
contain any timestamp. So we can use the timestamp of retrieval for
logging and displaying and don't get them at each of those location
where they might differ.
This means that timestamp will never be NULL.
I don't see why we would want to check for the chat state only if
timestamp isn't there.
Probably because in XEP-0085 there is not timestamp defined.
So if it thats stanza it's not there and we can parse quicker, but there
is nothing forbidden it to be there.
Related to https://github.com/profanity-im/profanity/issues/1339
|
| |
|
| |
|
|
|
|
|
| |
Is usefult in many cases if we want cleaner code.
Hope this edit didn't break anything though ;-)
|
| |
|
|
|
|
| |
Let's not crash :-)
|
|
|
|
|
|
|
|
| |
MAM messages don't have a type nor a from.
If we detect a message without type let's log it and exit without
continuing to try to parse it.
Otherwise we go into _handle_chat() and crash on the no from.
|
|
|
|
| |
The mucuser boolean is not now needed anymore.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Timestamps are only set if a message is delayed.
If none is set let's set it upon recaival so we don't have to set it
when it gets displayed.
This means we will also have it for logs etc in the ProfMessage.
|
|
|
|
|
|
|
|
| |
win_println_incoming_muc_msg() always used the current time. Now let's
use whatever is sent int he message struct (from the delay stanza or
the current time that we set now once the message is received).
No playing with the time upon display anymore.
|
|
|
|
| |
Fix init. mistake introduced in e9c5c1979d836ed75c37d48651710b4fd125cfb2
|
|
|
|
| |
We need to unref the timestamp before setting a new one.
|
|
|
|
| |
Fix https://github.com/profanity-im/profanity/issues/1261
|
|
|
|
|
|
|
| |
If we are connected with another client and send a message, then correct
it. We now display it correctly in Profanity.
Id wasn't saved for carbon copied messages too so far.
|
|
|
|
|
|
| |
Including OMEMO encrypted ones.
Also rename `win_println_me_message()` to `win_print_outgoing_muc_msg()
as I think it's a more descriptive name.
|
|
|
|
|
| |
Rename from _private_chat_handler() to _handle_muc_private_message() to
be more consistent with other handler names.
|
|
|
|
|
| |
People could change messages of other people if the nick isn't
registered.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
So far the correction is sent. But the UI in Profanity itself is not
updated.
Also autocompletion for `/correct` with the last sent message is
missing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we saved the timestamp which also had the `from`.
But we need this only to find out whether it's MUC history.
For displaying we should use the oldest delay timestamp.
Also in
https://github.com/profanity-im/profanity/commit/61f66966ddfe8ebd8bae26dd7ff92d777004edda#diff-4926fd4577a336bd3eb240f8104a5c5bL837
a error was introduced.
Before we saved the timestamp in all cases. And only if timestamp AND
from was given we went into MUC history case.
Normal timestamp saving was not done anymore only if it also had a from
attribute.
Regards https://github.com/profanity-im/profanity/issues/1254
|
|
|
|
|
|
|
|
| |
This reverts commit ef00b10c90aef8b75415fae558789d21bb975d75.
According to reply by user in
https://github.com/profanity-im/profanity/issues/1254#issuecomment-578389784
it didn't help.
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we got the first delay with a from that comes from the server.
This way we know it's MUC history.
Now we take the first time stamp we actually find. Which is likely the
one being added first. And should contain the correct time to display.
It would be nicer to actually compare the dates though.
Regards https://github.com/profanity-im/profanity/issues/1254
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/profanity-im/profanity/issues/1190 had another issue:
Sometimes servers send multiple </delay> and we just checked the first
one we got and only used it if the 'from' attribute was fitting.
However it could be that we actually wanted the second </delay> element
and there the 'from' would have been right.
So we need to loop through them until we get the one with the fitting
'from'.
Fix https://github.com/profanity-im/profanity/issues/1190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that in _handle_groupchat() we look for
STANZA_NS_STABLE_ID which will result in origin-id or stanza-id.
It seems like prosody servers send origin-id first, so this worked in
all my tests. But actually we cannot be sure of the order.
So far we stopped after the first element was found.
I only found xmpp_stanza_get_child_by_ns() and
xmpp_stanza_get_child_by_name() in libstrophe. But we need a combination
of both.
So I created stanza_get_child_by_name_and_ns() for Profanity. I need to
remember to upstream this to libstrophe later (if they really don't have
such a function).
Fix https://github.com/profanity-im/profanity/issues/1223
|
|
|
|
|
|
|
|
|
|
| |
Profanity sends the same value for both. Other clients might not.
Safe both since we could need them later.
Once we implement Last Message Correction we will need the regular id.
If we override it with origin-id and another client chooses to not use
the same value for id and origin-id then we can't interpret the id sent
with the LMC request correctly.
|
|
|
|
|
|
|
|
|
|
|
| |
Also we initialize mucuser properly.
Now in case of a carbon of a MUC PM we sv_ev_incoming_carbon() which
calls _sv_ev_incoming_plain() and then we log it via chat_log_msg_in()
in there.
But we also get the sv_ev_incoming_private_message() and call
chat_log_msg_in() in there too. So the incoming message get's logged
twice.
|
| |
|
|
|
|
|
| |
Let's use UUID to have a more random string then just 10 alphanumeric
values.
|
| |
|
|
|
|
|
| |
Hash twice.
Use HMAC SHA256 from glib.
|
| |
|
|
|
|
|
| |
We sent `prof_prefix_uuid` as id. Where the prefix was also optional.
We don't need this at all.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we get a private message from a user in a MUC profanity shows this
like:
`profanity@roomsASDF.dismail.de/Martin: Hi`
This was so far logged at:
`~/.local/share/profanity/chatlogs/my-account-at-server/profanity_at_rooms.dismail.de/2019_09_04.log` as:
```
10:48:13 - profanity@rooms.dismail.de: Hi
```
So the nickname was not saved anywhere. This is due to us not knowing
whether we got a regular message from user@server.org/resource or a MUC
PM from room@server.org/user.
We now check for `<x xmlns='http://jabber.org/protocol/muc#user' />` and
add the resourcepart to the logging if we get it.
The file will be created at
`~/.local/share/profanity/chatlogs/my-account-at-server/profanity_at_rooms.dismail.de_nick` and look like:
```
23:59:43 - nick: Hi
```
Fix https://github.com/profanity-im/profanity/issues/1184
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some versions of prosody send the domainpart.
See https://issues.prosody.im/1416
Workaround to handle those cases.
Thanks to Holger Weiss for helping with this!
Fix https://github.com/profanity-im/profanity/issues/1190
|
|
|
|
|
| |
message->plain should always contain something. In the case of the
carbons we forgot to set if rom the body in case it's empy.
|
|
|
|
|
|
|
|
| |
Double-check that a <delay/> tag on a groupchat message was actually
added by the MUC service (rather than the sending client) before
assuming it was received from the MUC history.
Fixes #1173.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
In case that plain is NULL we need to copy over from body.
Fix https://github.com/profanity-im/profanity/issues/1144
|