Skip to content
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

Some events non-obviously cause notification count changes #1001

Open
turt2live opened this issue May 17, 2022 · 9 comments
Open

Some events non-obviously cause notification count changes #1001

turt2live opened this issue May 17, 2022 · 9 comments
Labels
A-E2EE A-Message-Editing A-Notifications A-Polls O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect X-Spec-Changes Z-FTUE-Notifications

Comments

@turt2live
Copy link
Member

turt2live commented May 17, 2022

To name a couple:

For reactions and such we fixed this with MSC2153 (a push rule).

This issue exists to track the client-side concern, though the fix is concretely with the spec.

Related: #1088 (possible short-term solution?)

@turt2live turt2live added T-Defect S-Major Severely degrades major functionality or product features, with no satisfactory workaround A-Notifications A-Message-Editing Z-FTUE-Notifications X-Spec-Changes O-Occasional Affects or can be seen by some users regularly or most users rarely A-Polls labels May 17, 2022
@turt2live turt2live added S-Minor Impairs non-critical functionality or suitable workarounds exist and removed S-Major Severely degrades major functionality or product features, with no satisfactory workaround labels May 17, 2022
@SimonBrandner
Copy link

SimonBrandner commented May 17, 2022

This is sometimes caused by the fact the server can't see the event type due to the event being encrypted (e.g. call hangups)

@turt2live
Copy link
Member Author

That just means we're processing push rules either too correctly, or incorrectly. Our behaviour should be exactly the same as in unencrypted rooms.

@SimonBrandner
Copy link

That just means we're processing push rules either too correctly, or incorrectly. Our behaviour should be exactly the same as in unencrypted rooms.

We show notif counts based on what the server sends down during sync both in E2EE and non-E2EE rooms which is not ideal :/

@turt2live
Copy link
Member Author

That might be an entirely different case then, annoyingly.

one day we'll fix notifications.

@HarHarLinks
Copy link

  • other call events like switching (my own!) screen sharing state also gives a notification

@SimonBrandner
Copy link

  • my own!

The other side is responding to your SDP offer with an answer - the two ends need to agree on the media being sent

@HarHarLinks
Copy link

Thank you for the technical explanation. I'm sure you understand that from an end user perspective it feels like I am the one sending something when I change one of my settings.
Regardless, this should not happen.

@SimonBrandner
Copy link

Thank you for the technical explanation. I'm sure you understand that from an end user perspective it feels like I am the one sending something when I change one of my settings. Regardless, this should not happen.

Yes, of course, this is a super annoying (was just trying to add some context as to how this happens)

@whitequark
Copy link

whitequark commented Feb 15, 2023

This has been an issue since 2018 and it's absolutely intolerable in 1:1 voice calls when the other party frequently mutes and unmutes. Are there any concrete plans to fix this?

@t3chguy t3chguy transferred this issue from element-hq/element-web Feb 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-Message-Editing A-Notifications A-Polls O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect X-Spec-Changes Z-FTUE-Notifications
Projects
None yet
Development

No branches or pull requests

4 participants