| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
There are multiple paths which lead to rosterwin_roster(). The function
doesn't free list returned by wins_get_private_chats().
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\
| |
| | |
Fixed memory leak in ProfMucWin
|
| |
| |
| |
| |
| | |
Profanity remembers last message and its id for the message correction
feature. We must free them in window destructor.
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
Don't return too early. We still need to check for regular omemo
autocompletion (omemo_ac).
|
|
|
|
| |
This was forgotten in f13168005512fe4219741d9daf83681dd9ed3d63.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some users might want there nick to always stay white (etc) for easier
recognition.
Now we can do `/color own off` to not generate the color based on
xep-0392. The `me=` color (etc) from the theme will then be used.
Once we run this command `theme_load()` is called again.
And the theme looks totally wrong.
We encountered this at other times already and I think it's nothing
wrong with this new code here now but that there seems to be a missing
closing attr for the color when drawing.
Should be investigated seperately.
Fix https://github.com/profanity-im/profanity/issues/1288
|
|
|
|
|
|
| |
`profanity -t bios` loads the bios theme now.
Fix https://github.com/profanity-im/profanity/issues/1286
|
| |
|
|
|
|
|
|
| |
`/titlebar use name|jid` -> `/titlebar show|hide name|jid`
Fix https://github.com/profanity-im/profanity/issues/1284
|
| |
|
|
|
|
|
| |
New command `/slashguard` tries to protect against typing ` /quit` by
not allowing a slash in the first 4 characters.
|
|
|
|
|
|
|
| |
Most clients have them enabled by default already for a smoother modern XMPP experience.
Enable by default: allowing message corrections, sending of read
receipts, enabling carbons, typing/chat states.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
If users input strange stuff and we can't create a jid from it even the
setting is set to 'user' we still should fallback to the regular
identifer.
For example with `/msg @name%matrix.domain.org@matrix.org hi`.
|
|
|
|
| |
We check the from now.
|
| |
|
| |
|
|
|
|
| |
Not all cases covered yet.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Regards d18ec23d0a38bd538d48f7e827fec0fceb9f230d
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I suspect this was just a copy paste error.
`_win_create_simple_layout()` is called in other creation functions like
`win_create_config()` or `win_create_private()`.
I suspect when `win_create_muc()` was created it was just copied. But in
this function we actually set the layout ourself later.
So calling the function isn't needed.
Regards https://github.com/profanity-im/profanity/issues/1279
|
| |
|
|
|
|
| |
Fix init. mistake introduced in e9c5c1979d836ed75c37d48651710b4fd125cfb2
|
|
|
|
| |
Fix memleak.
|
|
|
|
| |
No need to continue to loop through the rest.
|
|
|
|
|
|
|
| |
g_slist_delete_link() is not enough we also need to call _free_entry()
on the entry.
This fixes a memleak in win_insert_last_read_position_marker()
|
|
|
|
| |
We need to unref the temp datetimes again.
|
|
|
|
| |
We need to unref the timestamp before setting a new one.
|
|
|
|
| |
Could be that args[1] is not set.
|
|
|
|
| |
Fixes potential memory leak too.
|
|
|
|
| |
Some instructions were missing whitespace or punctuation.
|
| |
|
|
|
|
| |
Make clear that result should never be freed.
|