| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It was too permissive on characters before the identifier and also
allowed the domain name to start on dash, which should not occur.
Closes #512.
|
|
Fixes #510.
|
|
This fixes the `q->readMarker() != historyEdge()` assertion failure
occuring in recalculateUnreadCount() when new events from sync arrive
to a room with no read marker and all history loaded.
|
|
Closes #489.
|
|
Read receipts are entangled with counting unread messages, and saving
them also helps in not sending receipts for too old events. Other users'
read receipts are still treated as truly ephemeral.
|
|
|
|
This is a more conservative but less idiomatic.readable fix for entirely
missing notification_count/highlight_count. In reality, Synapse seems
to always send them; but that is not required by The Spec.
|
|
Users with slashes in their ids do it at their own peril of course but
to encode the id in the URL is a good thing in any case. Too bad it's
pretty invisible and has to be dealt with case by case, instead of GTAD
magically sticking QUrl::toPercentEncoding() where appropriate in
the generated code.
|
|
For now this is to update saved unread counts.
|
|
There is no harm in updating it locally, as read receipts are only
supposed to move forwards; if an update from another client of the same
user arrives the next millisecond, it will only be incorporated if it
points to an even newer event (exactly as would be expected). In any
case, read receipts are more for others than for yourself.
|
|
Another regression after the read receipts/markers rework,
most prominently seen when a room has "0+" unread messages and the first
historical batch gets loaded.
|
|
Move Room::sync/historyEdge() implementation to Room::Private, so that
internal logic could use the same readable shortcuts without q->
prefixes, instead of timeline.crend() and timeline.cend() that are much
less readable.
|
|
Read marker promotion worked before the rework - and it works again
with this commit. Read receipts are promoted from anywhere, the fully
read marker is only promoted if it's adjacent to the batch just added.
|
|
Pre-e12d7ba2, addHistoricalMessageEvents() triggered recounting and
emitting unreadMessagesChanged() even if the number remained the same.
This logic has been lost when refactoring the code; now it's back there
again.
|
|
|
|
|
|
This is a further extension of #481 fix that takes the whole current
state event content, rather than just the avatar URL.
|
|
Just to align with the similar changes coming in 0.7
|
|
That is unlikely to impact performance, since reserve() is usually
called only once per given JSON object (`{ "join": { ... } }`).
|
|
(cherry picked from commit 7b65051e959968fe538f40c975d85757cfcc7df7)
|
|
|
|
|
|
|
|
|
|
This turns the design changes laid out in #464 comments to code:
- readMarker() now returns the fully read marker, unlike
readMarker(User*) that returns a read receipt, even when called for
the local user.
- Private::setLastReadEvent() -> setLastReadReceipt(), incorporating
the "promotion" logic from promoteReadReceipt().
- The above makes promoteReadReceipt() unneeded; the remaining piece
of logic that recalculates the number of unread messages is put to
its own method - Private::recalculateUnreadCount().
- Private::updateUnreadCount() is only slightly refreshed, continues
to use the fully read marker position (as it used to).
- Now that read receipts and fully read markers are managed separately,
Private::setLastReadReceipt() has got its counterpart,
Private::setFullyReadMarker(); both only update their respective
markers locally (emitting signals as needed), without interaction
with the homeserver.
- Private::markMessagesAsRead() now delegates updating the fully read
marker to setFullyReadMarker() and on top of that sends the new
fully read marker to the homeserver.
- Private::serverReadMarker -> fullyReadUntilEventId (to be really clear
what it stores).
- The hand-written PostReadMarkersJob is replaced with the generated
SetReadMarkerJob that does the same thing (and can update the read
receipt on top, though the current code doesn't use that).
|
|
|
|
All actual updates to the API go to 0.7.
|
|
|
|
Closes #481. Note: the library doesn't even have the API in User
to set per-room avatars; one still can achieve that by calling
Room::setState<RoomMemberEvent>(...) though (and it's likely to be _the_
recommended way to deal with per-room user profiles in 0.7, with User
being entirely deprecated).
|
|
Only API-preserving changes are included in this branch (0.7 will have
all changes).
|
|
This is an adjustment to the earlier fix of #471: if a join is
immediately followed by a leave (e.g. from another client/bot - you
can't do it programmatically from libQuotient) the sync may bring the
room already in the Leave state; therefore `joinRoom` should not
impose the state but rather ask `provideRoom` to create a `Join` room -
just as it's designed when passed an empty `joinState`.
|
|
An alternative implementation of #463 (and thanks to Carl for spotting
the original problem).
|
|
A few months ago 3c85f049 introduced validation of user ids but the rest
of the library code wasn't updated to the fact that Connection::user()
may quite legitimately (if not routinely) return nullptr, leading to
crashes particularaly when malformed ids come from the wire. This commit
adds necessary checks before using the value returned from user().
Closes #456.
|
|
|
|
As per the latest iteration of MSC2312, room/, user/ and event/ are
only supported for parsing and replication but not for emitting from
Matrix identifiers.
|
|
The new formatted_body was not included into new content on edit
due to badly constructed json.
(cherry picked from commit df6b2d31ec8f2f5890826719e960f450a4968f22)
|
|
With this patch it looks like:
"m.relates_to": {
"m.in_reply_to": {
"event_id": "$another:event.com"
}
}
instead of:
"m.relates_to": {
"event_id": "$another:event.com",
"rel_type": "m.in_reply_to"
},
So it fits the specification by now.
https://matrix.org/docs/spec/client_server/r0.6.1#rich-replies
(cherry picked from commit b850edadde2299b122a5cd17da85e943430e43b7)
|
|
This avoids a corner case when a login flows job finishes (or worse,
goes for a retry) while the homeserver is (being) resolved, yielding
the Connection object in an inconsistent state to the client.
|
|
See #437 for the discussion.
(cherry picked from commit 6101971af86fdecd084759aa039b9d20a9d662a7)
|
|
So just reset the base URL and return, with no error signals.
|
|
Fixes #437.
|
|
|
|
...because finished() includes abandoning and should only be relevant
when lifecycle issues are involved.
|
|
(cherry picked from commit 0f974c0f96f29035ee766e8913504fed4a4903a5)
|
|
1. resolveServer() now emits homeserverChanged() even when there's no
.well-known file found.
2. checkAndConnect() entirely removed from the header file.
3. Sunny-day scenario for assumeIdentity() is now asynchronous,
triggering a call to /whoami to double-check the user.
(based on commit 6c9ff40dbd91cc4966f0ecf9ed817efc2495a2fb to master)
|
|
(cherry picked from commit 56c1db077b5da653c230432abc6c746318a77bed)
|
|
...to show the sunny-day case.
(cherry picked from commit 5d15e3b23649a54abdb3812c10f4a7d2ce07d7dd)
|
|
Usually QNetworkAccessManager expects the user to delete the replies, but when the QNetworkAccessManager itself is deleted it deletes all pending replies (https://code.woboq.org/qt5/qtbase/src/network/access/qnetworkaccessmanager.cpp.html#529).
This can lead to use-after-free crashes when d->reply is accessed. By putting the reply into a QPointer the exiting if(d->reply) checks can work properly.
(cherry picked from commit 9d854e778d8d6ef8e03e1ea74fe958675b24fd45)
|
|
Notably, recommend using loginFlowsChanged() rather than
homeserverChanged() to detect when a Connection object is ready for
a login sequence. Related: #427.
(cherry picked from commit 8981c5451ac378f16d5b57d7460d053e2cbc666e)
|
