Skip to content

/ profanity

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Profanity shows old messages as new when connecting to some MUC #1254

Closed
misaflo opened this issue Jan 16, 2020 · 12 comments
Closed

Profanity shows old messages as new when connecting to some MUC #1254

misaflo opened this issue Jan 16, 2020 · 12 comments
Assignees
@jubalh
Labels
bug server
Milestone
0.8.0

Comments

@misaflo
Copy link
Contributor

@misaflo misaflo commented Jan 16, 2020

Expected Behavior

Old messages are not shown as new but are in the right place of the timeline.

Current Behavior

In some MUC (on server running Openfire 4.5.0), after connect old messages are shown as just received with the current date and time (not in Profanity MUC).

Context

Here some log (profanity --log=DEBUG):

15/01/2020 21:29:11: xmpp: DBG: RECV: <message id="410757451959" to="me@domain.fr/profanity.8G1h" type="groupchat" from="muc@conference.domain.fr/other"><body>allez bonne soirée.</body><stanza-id id="71106678-f2e1-4054-89f7-17394a61b7af" by="muc@conference.domain.fr" xmlns="urn:xmpp:sid:0"/><delay xmlns="urn:xmpp:delay" stamp="2020-01-15T18:21:58.455Z" from="other@domain.fr/resource/></message>

There is: stamp="2020-01-15T18:21:58.455Z" (witch is the right hour, 18:21:58).
But in profanity I see the hour of the connection to the MUC (21:29:11).

This bug concern dev version (and does not occur in the stable release 0.7.1).

Environment

profanity --version    
Profanity, version 0.7.1dev.makepkg.44204635
Copyright (C) 2012 - 2019 James Booth <boothj5web@gmail.com>.
Copyright (C) 2019 - 2020 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: libmesode
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.13.1)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.8.1)
GTK icons: Enabled

Tested on Arch Linux and Debian Buster.
@jubalh jubalh self-assigned this Jan 17, 2020
@jubalh jubalh added the bug label Jan 17, 2020
@jubalh jubalh added this to the 0.8.0 milestone Jan 17, 2020
jubalh added a commit that referenced this issue Jan 24, 2020
@jubalh
Save first delay tag as timestamp
Loading status checks…
ef00b10 
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 #1254
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 24, 2020

@misaflo can you please test with latest master?
@misaflo

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@misaflo misaflo commented Jan 25, 2020

Yes, no change: the datetime is still wrong (datetime of the connection).
jubalh added a commit that referenced this issue Jan 28, 2020
@jubalh
Revert "Save first delay tag as timestamp"
Loading status checks…
388bae0 
This reverts commit ef00b10.

According to reply by user in
#1254 (comment)
it didn't help.
jubalh added a commit that referenced this issue Jan 30, 2020
@jubalh
muc: save oldest timestamp
8a94882 
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
61f6696#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 #1254
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

@misaflo can you test with latest master again?
@misaflo

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@misaflo misaflo commented Jan 30, 2020

No change :-(
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

Can you please describe again what is happening and how you test this?
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

Do you mean that messages that were sent while you were offline (to a MUC) are later displayed as regular messages and not as MUC history?

Or are you saying the date/time of all MUC messages is wrong?
Or the date/time of MUC history messages is wrong?

Also does this only happen to you on that openfire server?
@misaflo

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

@misaflo misaflo commented Jan 30, 2020 •
edited

I joining some MUC when connecting to my account.
On profanity MUC no problem. But on others (running up-to-date openfire), when I'm connecting I see all old messages as just received (the hour is wrong), even them that I have alreay read the day before.

For test this, I just /quit profanity, and lanch it again (all messages are see as juste received, with current hour).
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020 •
edited

from="muc@conference.domain.fr/other looks like MUC PM.
Ah no it's just the nick :)

13:27:03 - jubalh: Misaflo: so two things happen: 1. the date is wrong. 2. it's printed as just received message and not MUC history. is that right?
13:27:14 - Misaflo: yes
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

https://xmpp.org/extensions/xep-0045.html#enter-history sais "The 'from' attribute MUST be set to the JID of the room itself."

allez bonne soirée.<delay xmlns="urn:xmpp:delay" stamp="2020-01-15T18:21:58.455Z" from="other@domain.fr/resource/>

has from="other@domain.fr/resource/.

Maybe an openfire problem?
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

I created a bug for openfire: https://discourse.igniterealtime.org/t/maybe-muc-history-bug/87165
@jubalh jubalh added the server label Jan 30, 2020
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

Through this issue we fixed some problems anyways :)

  1. We only added delay timestamps to messages if it was MUC history. Not regular delays. This was introduced in 61f6696#diff-4926fd4577a336bd3eb240f8104a5c5bL837 and fixed in 8a94882.

  2. We sort the delay tags now and use the oldest.
@jubalh

This comment has been minimized.

Sign in to view
Copy link
Member

@jubalh jubalh commented Jan 30, 2020

I'll close this issue because I think it's an Openfire bug. Further discussion hopefully happens on the above mentioned bug in the openfire tracker.
@jubalh jubalh closed this Jan 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jubalh jubalh

Labels
bug server
Projects
None yet
Milestone
  0.8.0
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@misaflo @jubalh
You can’t perform that action at this time.