Message window is empty after reconnect

[mdosch]

If a reconnect happens while a chat window (MUC or 1-1) is open the whole window (top bar, bottom bar, participant list, chat win etc.) is empty (only background color) after the reconnect. Then it gets redrawn but the chat win remains empty.

simplescreenrecorder-2021-06-08_11.41.37.mp4

Expected Behavior

Show the messages in chat window after the reconnect.

Current Behavior

See above.

Steps to Reproduce (for bugs)

1. Have a chat window open
2. Force a reconnect (restart network manager or similar)
3. Look at the chat window
4. The message window disappears after the reconnect.

Environment

• Debian Unstable
• i3 / Xorg
• GNOME Terminal 3.38.3 using VTE 0.62.3 +BIDI +GNUTLS +ICU +SYSTEMD
• libncursesw6/testing,unstable,now 6.2+20201114-2 amd64
• libreadline8/unstable,now 8.1-2 amd64

cat ~/.config/profanity/profrc
[connection]
defaccount=martin

account=martin

carbons=true

receipts.request=true
receipts.send=true

reveal.os=true

correction.allow=true

autoping=20
autoping.timeout=10

mam=true

[ui]
theme=solarized-dark
titlebar.position=1
mainwin.position=2
statusbar.position=3
inputwin.position=4

statuses.chat=none
history=true

adv.notify.discoversion=true

statusbar.show.number=true
statusbar.show.name=false
statuses.muc=none
statuses.console=none

beep=true
flash=false
splash=true
wrap=true
resource.title=false
resource.message=false
occupants=true
roster=true
roster.offline=true
roster.resource=false
roster.presence=false
roster.status=false
roster.empty=false
roster.wrap=true
roster.count.zero=false
roster.priority=false
roster.contacts=true
roster.unsubscribed=true
roster.rooms=true
privileges=true
presence=true
intype=true
enc.warn=true
tls.show=true
time.console=%d.%m.%y %H:%M:%S
time.chat=%d.%m.%y %H:%M:%S
time.muc=%d.%m.%y %H:%M:%S
time.config=%d.%m.%y %H:%M:%S
time.private=%d.%m.%y %H:%M:%S
time.xmlconsole=%d.%m.%y %H:%M:%S
time.statusbar=%H:%M:%S
console.muc=mention
console.private=first
console.chat=first
roster.by=group
roster.order=presence
roster.unread=after
roster.rooms.unread=after
roster.count=unread
occupants.size=15
roster.size=25
roster.contact.indent=1
occupants.jid=false
roster.resource.join=true
roster.rooms.server=false
time.lastactivity=%d/%m/%y %H:%M:%S
roster.rooms.order=name
roster.rooms.pos=last
roster.rooms.by=none
roster.private=room
statusbar.self=user
statusbar.chat=user
statusbar.room=room
statusbar.tabs=10
statusbar.tablen=7
roster.rooms.private.char=/
roster.resource.indent=1
roster.presence.indent=-1

wintitle.show=false




color.nick=true


titlebar.muc.title=name

color.occupants.nick=false

slashguard=true

history.muc.color=regular

titlebar.muc.title.name=true

vercheck=false

intype.console=false

[chatstates]
enabled=true

outtype=false

[logging]
chlog=true
grlog=true


rotate=true

maxsize=2147483647

[notifications]
room.text=false
room.mention=true
room=false
message=true

tray=true
tray.read=false

room.trigger.list=@Martin;

[pgp]
pgp.char=%

[omemo]
policy=automatic
log=on
omemo.char=🔒


trustmode=blind

[plugins]


[alias]
w=/win

[executables]

Profanity, version 0.10.0dev.master.8ffb1bdd
Copyright (C) 2012 - 2019 James Booth <boothj5web@gmail.com>.
Copyright (C) 2019 - 2021 Michael Vetter <jubalh@iodoru.org>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libstrophe
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.14.0-unknown)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.9.2)
GTK icons/clipboard: Enabled

[jubalh]

https://lists.notraces.net/pipermail/profanity/2021/000047.html :

Hello there.
I have a bug I want to report.
It is the same bug that someone already reported:
https://github.com/profanity-im/profanity/issues/1556

Operating System: GNU/Arch Linux.
Kernel version: 5.14.10-arch1-1

Profanity, version 0.11.1
Copyright (C) 2012 - 2019 James Booth <boothj5web at gmail.com>.
Copyright (C) 2019 - 2021 Michael Vetter <jubalh at iodoru.org>.
License GPLv3+: GNU GPL version 3 or later
<https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libmesode
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.16.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.9.7)
GTK icons/clipboard: Disabled

[jubalh]

Someone in the MUC suggest that it has to do with:

profanity/src/event/server_events.c

Line 272 in e31e287

sv_ev_room_history(ProfMessage* message)

We filter out messages that we already received. So after reconnect MUC history is not displayed again.

Still doesn't explain why for some people the window is cleared and for others not. Should check this.

[eqn-group]

Someone in the MUC suggest that it has to do with:

profanity/src/event/server_events.c

Line 272 in e31e287

sv_ev_room_history(ProfMessage* message)

We filter out messages that we already received. So after reconnect MUC history is not displayed again.

Still doesn't explain why for some people the window is cleared and for others not. Should check this.

where are you checking, i mentioned the debug log in my issue, you could check.

[jubalh]

@mdosch Can you comment out the wins_reestablished_connection() in sv_ev_login_account_success() and see what happens then for your?

[mdosch]

Doesn't have an impact. On 23.02.2022 03:11, Michael Vetter wrote: ***@***.*** Can you comment out the `wins_reestablished_connection()` in `sv_ev_login_account_success()` and see what happens then for your?

…

-- Reply to this email directly or view it on GitHub: #1556 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[moorchegue]

Same thing here, version 0.11.1.

A couple of twists: sometimes window is empty, sometimes some really old messages are loaded (exactly the same every time it happens), and only the ones that were received, not the ones that were sent. All chatlog files look correct, so it must be a loading issue.

Similar thing happens after terminating, starting profanity again, and opening same chat window. Let me know if there's anything I can do to help to debug this.

[mdosch]

Just an update, that this also happens on another installation where I use a different set up:

• Debian bookworm
• WM: sway
• Terminal emulator: foot

 profanity -v 
Profanity, version 0.13.1
Copyright (C) 2012 - 2019 James Booth <boothj5web@gmail.com>.
Copyright (C) 2019 - 2022 Michael Vetter <jubalh@iodoru.org>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libstrophe
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.18.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.11.2)
GTK icons/clipboard: Enabled
GDK Pixbuf: Enabled

[jubalh]

@moorchegue also using Debian?

[moorchegue]

Nope, I'm on Arch.

[MarcoPolo-PasTonMolo]

I might have captured a trace

Thread 1 "profanity" hit Breakpoint 3, buffer_free (buffer=0x55555639e5a0) at src/ui/buffer.c:82
82          g_slist_free_full(buffer->entries, (GDestroyNotify)_free_entry);
(gdb) bt
#0  buffer_free (buffer=0x55555639e5a0) at src/ui/buffer.c:82
#1  0x00005555555ba1f6 in win_clear (window=window@entry=0x5555561df6a0) at src/ui/window.c:762
#2  0x00005555555b58bb in sv_ev_roster_received () at src/event/server_events.c:163
#3  0x00005555555ae863 in roster_result_handler (stanza=<optimized out>) at src/xmpp/roster.c:304
#4  0x00005555555a00e8 in _iq_handler (conn=<optimized out>, userdata=<optimized out>, stanza=0x5555565dfee0) at src/xmpp/iq.c:236
#5  _iq_handler (conn=<optimized out>, stanza=0x5555565dfee0, userdata=<optimized out>) at src/xmpp/iq.c:182
#6  0x00007ffff6611322 in  () at /usr/lib/libstrophe.so.0
#7  0x00007ffff66181df in  () at /usr/lib/libstrophe.so.0
#8  0x00007ffff542163f in  () at /usr/lib/libexpat.so.1
#9  0x00007ffff542243e in  () at /usr/lib/libexpat.so.1
#10 0x00007ffff54248ea in XML_ParseBuffer () at /usr/lib/libexpat.so.1
#11 0x00007ffff6610efe in xmpp_run_once () at /usr/lib/libstrophe.so.0
#12 0x000055555559b91f in connection_check_events () at src/xmpp/connection.c:160
#13 0x0000555555594114 in prof_run (log_level=0x555555627114 "WARN", account_name=<optimized out>, config_file=0x0, log_file=<optimized out>, theme_name=<optimized out>) at src/profanity.c:132
#14 0x000055555558fb1d in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:186

This might be the issue
6034b83

[jubalh]

@mdosch would be great if you could give feedback here.

[mdosch]

Seems to be ok now. 🎉