| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
xmpp_stanza_add_child() takes own reference to the child stanza.
Therefore we have to release our reference or the child is lost
and not freed otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The memory leak happens when a presence is received for a MUC room. The
JID is not present in the roster, so updating its status is ignored. We
have to free resource in this case, because it has no owner and is lost
otherwise.
==25736== 47 (32 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 1,625 of 3,399
==25736== at 0x4A330FF: malloc (vg_replace_malloc.c:309)
==25736== by 0x13A962: resource_new (resource.c:47)
==25736== by 0x145501: _available_handler (presence.c:665)
==25736== by 0x145501: _presence_handler (presence.c:399)
==25736== by 0x145501: _presence_handler (presence.c:358)
==25736== by 0x80D5F34: handler_fire_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80D2B49: _handle_stream_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80E15CE: _end_element (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x843EE9B: doContent (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x843F94B: contentProcessor (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x8441E77: XML_ParseBuffer (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x80D586B: xmpp_run_once (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x13E07E: connection_check_events (connection.c:119)
==25736== by 0x13869C: prof_run (profanity.c:129)
Fixes #1279.
|
|
|
|
|
|
|
|
|
|
|
| |
Change:
`/avatar me@somewhere.org` -> `/avatar get me@somewhere.org`
New:
`/avatar cmd feh`
`/avatar open me@somewhere.org`
Implement https://github.com/profanity-im/profanity/issues/1281
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Fix memleak.
|
|
|
|
| |
We need to unref the temp datetimes again.
|
|
|
|
| |
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.
|
|
|
|
| |
and print settings if only `/correction` is run.
|
| |
|
|
|
|
| |
"retrieve1" should have been only for testing.
|
|
|
|
| |
Fix #1068
|
| |
|
|
|
|
| |
Introduced in bf2e09feee1697c570fcfb9e1e44a8ec991bd196.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Have two helper functions one for XEP-0203 and one for XEP-0091.
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Default is on. `revail.os=false` in the `connection` section of the
config can disable it.
A command to configure this will follow.
|
|
|
|
|
| |
So far we only sent client name and version. Let's also send the OS
name.
|
|
|
|
|
|
|
|
|
|
| |
Cannot be configured for now.
Can be set via `adv.notify.discoversion` in the `notification` section.
Will notify about version requests via XEP-0092 and XEP-0232.
Client version can still be seen via caps (capabilities).
See `stanza_attach_caps()`.
|
|
|
|
| |
We will need this if we want to display the Name instead of the JID.
|
| |
|
| |
|
|
|
|
| |
Fixes #1239
|
| |
|
|\
| |
| | |
OMEMO message keys allow prekey="1" alongside prekey="true"
|
| |
| |
| |
| |
| |
| |
| |
| | |
prekey is defined as `<xs:attribute name="prekey" type="xs:boolean"/>`
which allows both `true` and `1` as truthy values.
Not checking for `1` breaks omemo encryption when interacting with
clients which set prekey="1", example: psi+ 1.4.983
Regards https://github.com/profanity-im/profanity/issues/1247
|
|/ |
|
|
|
|
| |
And use better function names.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1241
|
|
|
|
|
|
| |
We use malloc() and free().
Fix https://github.com/profanity-im/profanity/issues/1241
|
| |
|
| |
|
| |
|