Chat highlight behaves odd

[licaon-kter]

HEAD (b44e1c8) self-build, Firefox Stable

Highlight does not change to correct contact

But, if I open a group it highlights that group or disappears when I switch away to a chat. Selecti the group again....highlighted...select 1:1 chat... nothing highlighted.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[RoyTheJet]

Hey, would love to take a crack at this if that is all right?

[jcbrand]

Hey @RoyTheJet, that would be great thanks. Have you been able to reproduce the issue? If you're unsure how to start or need help, let me know.

[RoyTheJet]

Hey, @jcbrand I have not been able to reproduce the issue. Any help would be greatly appreciated thanks.

[jcbrand]

@licaon-kter Can you still reproduce this bug?

[kicken]

I encounter this issue still. Seems to happen fairly reliably then closing out with a 1:1 chat open. When logging in again it re-opens the chat and highlights that entry which then remains highlighted. Problem does not seem to happen when a MUC or no chat was open when last closed out.

[licaon-kter]

@jcbrand Yup, same for 858a605

Login, see an 1:1 being opened, click on another 1:1, see picture above

[RoyTheJet]

Ok, I've reproduced this bug. I also have noticed, that if you have 1:1 chats in different groups collapsing the group with the wrong highlight will shift the highlight to the correct chat. Also, if you have chats in the same group collapsing, then reopening the group, will shift the highlight to the correct chat. I did this with the console open, it shows that the class attribute "open" does not shift to the correct "li" when being clicked.

[licaon-kter]

Interesting, it is true that as the picture shows, that (wrongly) highlighted 1:1 is in a different group (one named as empty or space but that's like a different issue :) )

[m1sraapurva]

Hi All!
As I was trying to write a plugin for modifying the behavior of roster items, I found something peculiar that I believe has to do with this issue:
please refer to converse.js/src/plugins/rosterview/contactview.js
method: initialize () { this.listenTo(this.model, "change", () => this.requestUpdate()); this.listenTo(this.model, "highlight", () => this.requestUpdate()); this.listenTo(this.model, 'vcard:add', () => this.requestUpdate()); this.listenTo(this.model, 'vcard:change', () => this.requestUpdate()); // console.log('this:', this); }
when I added some prints to see "this" object and inspect what it was configured to listen to, I discovered that
whenever the contacts are loaded from the cache, (i.e. a login without clearing cache and data), the RosterContact
elements are listening to events on different models than their own.

As can be seen in the screenshot, the model of is different from what it is _listeningTo.
So it seems a possible cause of unrelated roster items being highlighted on click as for contact A. contact B's model is being listened for the "highlight" event.
Thank you.

[jcbrand]

Thanks a lot for the info @m1sraapurva, I think you might have found the issue.

This is because of how lit-html works when rendering a list of items. It re-renders DOM nodes in-place, even when the order of the list has changed.. We don't want this for the roster, instead we want DOM nodes to be moved around to reflect the new ordering, otherwise a DOM node that had one model receives a different one upon re-render (just like you noticed).

The solution is to use the repeat directive.

https://lit.dev/docs/templates/lists/#when-to-use-map-or-repeat

[licaon-kter]

I've built e63ba20 and it's still odd:

Do I need to nuke my stored session browser data?

[jcbrand]

No, I'll check again.