Commit Graph

20 Commits (1e4ab627df75f86ab4d05e6ae035e6d95260654e)

Author SHA1 Message Date
J. Ryan Stinnett 674f33917f Remove editing feature flag
Part of https://github.com/vector-im/riot-web/issues/10282
2019-07-17 16:56:15 +01:00
Bruno Windels 57dce73cee adjust comment 2019-06-24 16:53:42 +02:00
Bruno Windels 5fa3f70fb4 feature flag for displaying edits as well 2019-06-21 18:32:15 +02:00
J. Ryan Stinnett 96b213e7cb Advance read receipts into trailing events without tiles
This changes read receipt sending logic to allow it advance further into events
without tiles (such as edits or reactions) that may exist after the last
displayed event.

By allowing the read receipt to advance past such events, this also marks as
read any related notifications. For example, edits trigger notifications by
default since they are `m.room.message` events, and with this change, such edit
notifications can finally be marked read.

Part of https://github.com/vector-im/riot-web/issues/9745
2019-06-03 18:25:35 +01:00
Bruno Windels 5805a88ab9 adjust to js-sdk changes of marking original event as replaced 2019-05-15 11:54:26 +01:00
Travis Ralston cb6f415a05 Be more positive with setting labels
Fixes https://github.com/vector-im/riot-web/issues/6435

This is done through an on-the-fly inverter for the settings. All the settings changed are boolean values, so this should be more than safe to just let happen throughout the SettingsStore. Typically a change like this would be done in the individual handlers (similar to how setting names are remapped to different properties or even different storage locations on the fly), however doing that for this many settings would be a huge nightmare and involve changing *all* the layers. By putting a global "invert this" flag on the setting, we can get away with doing the inversion as the last possible step during a read (or write).

To speed up calculations of the default values, we cache all the inverted values into a lookup table similar to how we represent the defaults already. Without this, the DefaultHandler would need to iterate the setting list and invert the values, slowing things down over time. We invert the value up front so we can keep the generic inversion logic without checking the level ahead of time. It is fully intended that a default value represents the new setting name, not the legacy name.

This commit also includes a debugger for settings because it was hard to visualize what the SettingsStore was doing during development. Some added information is included as it may be helpful for when someone has a problem with their settings and we need to debug it. Typically the debugger would be run in conjunction with `mxSendRageshake`: `mxSettingsStore.debugSetting('showJoinLeaves') && mxSendRageshake('Debugging showJoinLeaves setting')`.
2019-01-24 20:57:40 -07:00
Travis Ralston ebdba32393
Add a comment about the SettingsStore being slow 2018-12-08 12:06:37 -07:00
Travis Ralston f2468f562d Speed up room unread checks by not hitting the SettingsStore so often
This was noticed as a problem after `Unread.doesRoomHaveUnreadMessages` started being called a lot more frequently. Down the call stack, `shouldHideEvent` is called which used to call into the `SettingsStore` frequently, causing performance issues in many cases. The `SettingsStore` tries to be as fast as possible, however there's still code paths that make it less than desirable to use as the first condition in an AND condition. By not hitting the `SettingsStore` so often, we can shorten those code paths.

As for how much this improves things, I ran some profiling before and after this change. This was done on my massive 1200+ room account. Before it was possible to see nearly 2 seconds spent generating room lists where 20-130ms per room was spent figuring out if the room has unread messages. Afterwards, the room list was generating within ~330ms and each unread check taking 0-2ms. There's still room for improvement on generating the room list, however the significant gains here seem worth it.
2018-12-07 20:15:21 -07:00
Michael Telatynski bd4b40309d
fix based on PR review
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2018-02-28 00:49:14 +00:00
Michael Telatynski 773fef7f1d
fix shouldHideEvent saying an event is a leave/join when a profile change
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2018-02-22 16:14:56 +00:00
Travis Ralston 63bebe9dfd Split out avatar and display name hiding
Signed-off-by: Travis Ralston <travpc@gmail.com>
2017-11-13 12:58:10 -07:00
Travis Ralston ae10a11ac4 Convert synced settings to granular settings
Signed-off-by: Travis Ralston <travpc@gmail.com>
2017-10-29 01:43:52 -06:00
Michael Telatynski 5450d6b9ca
remove redundant check and add comment
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2017-08-10 15:22:53 +01:00
Michael Telatynski 625ca96d86
add comment about why state key must be not undefined
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2017-08-10 14:01:24 +01:00
Michael Telatynski a6064c53d3
export shouldHideEvent fn named
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2017-08-10 14:00:26 +01:00
Michael Telatynski 1603360c13
s/Membership/Member/
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2017-08-10 13:58:19 +01:00
Michael Telatynski ffdffb643d
allow hiding of avatar/display name changes 2017-08-04 17:22:01 +01:00
Michael Telatynski 3b8c408482
update comment to make explain behaviour better 2017-07-26 13:37:33 +01:00
Michael Telatynski 762e6780d7
fix this hiding unbans as found by Luke's review 2017-07-26 11:51:41 +01:00
Michael Telatynski 8167c004a8
re-add core logic
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
2017-07-21 19:38:01 +01:00