Display rooms & threads as unread (bold) if threads have unread messages.

[clokep]

Re-apply the changes from 9de5654 (#9723) which were reverted in 9668a24 (#9745); also incorporates #9738 and #9739.

This fixes 3 related bits of notifications due to room activity:

• The room (in the room list) should appear as bold on new events in any thread in the room.
• The thread (in the threads list) should appear bold on new activity in that thread.
• The thread icon should get a badge if any threads have new activity.

The logic for all of these is essentially separate (instead of bubbling up from threads -> thread list -> room or something like that), so there are 3 separate changes made.

Fixes element-hq/element-web#23907

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Display rooms & threads as unread (bold) if threads have unread messages. (#9763). Fixes Messages in threads not marking room as unread element-hq/element-web#23907.

[clokep]

(Mostly choosing a random place to start a thread.)

We need to figure out how to handle threads that exist before this change or users will see many rooms marked as unread as threads that exited before MSC3771 will likely not have a read receipt and will appear as unread.

[clokep]

@gsouquet I think you were going to write a bit about our options here? From what I remember of our conversation we want to mark any "existing" threads as read up to their current point when this rolls out (so we don't mark all "old" threads as unread). Potential options:

1. Send a read receipt in each thread to the server and receive them down sync. (This likely wouldn't work since we would essentially DoS the server & we don't load all threads on load anyway.)
2. Mark any threads before a certain time as read. This isn't desirable since different people will start using the new code at different times.

I'm not sure we came up with others (besides something about changing the entire storage of events to be closer to what mobile does).

[germain-gg]

We have discussed this during a web meeting last week.
One alternative approach that has not been listed above is to figure out for each room when the first threaded read receipt has been sent and to discard all the threads that haven't received an update since that point in time from the computation made in this pull request

Sounds like the most sensible thing to do, we might need to force an initial sync, to make sure we have access to that data

[clokep]

when the first threaded read receipt has been sent and to discard all the threads that haven't received an update since that point in time from the computation made in this pull request

How do we compare "when" this way? Using the ts of the receipt and the origin_server_ts of the events?

[clokep]

This work is now essentially in matrix-org/matrix-js-sdk#3020 matrix-org/matrix-js-sdk#3031, although we might need more tweaks here.

[clokep]

These are mostly copied from useUnreadNotifications:

matrix-react-sdk/src/hooks/useUnreadNotifications.ts

Lines 40 to 53 in ad4feef

	useEventEmitter(
	room,
	RoomEvent.UnreadNotifications,
	(unreadNotifications: NotificationCount, evtThreadId?: string) => {
	// Discarding all events not related to the thread if one has been setup
	if (threadId && threadId !== evtThreadId) return;
	updateNotificationState();
	},
	);
	useEventEmitter(room, RoomEvent.Receipt, () => updateNotificationState());
	useEventEmitter(room, RoomEvent.Timeline, () => updateNotificationState());
	useEventEmitter(room, RoomEvent.Redaction, () => updateNotificationState());
	useEventEmitter(room, RoomEvent.LocalEchoUpdated, () => updateNotificationState());
	useEventEmitter(room, RoomEvent.MyMembership, () => updateNotificationState());

[germain-gg]

Code looks good to me!
There's some type error where you're using React.ReactElement but React testing library yields HTMLElement rather than a React Element.

It also seem that some recent changes have made some tests regress.

[germain-gg]

And that now looks good to me 👍

We should re-run the CI once matrix-org/matrix-js-sdk#3031 has landed, and we'll be ready to merge it.