Fixes https://github.com/vector-im/riot-web/issues/7158
Because the onClick was on a fullpage div, the browser was firing it regardless of how far the mouse moved. The onClick event itself doesn't give us any sort of travel distance, or a start point we can use to determine if they clicked a scrollbar or something. This means we have to rely on good ol' fashioned mouse down and up events to see if the user moved their mouse during their click.
If the user's click starts in a valid container, we record the coordinates. This is so we can easily identify when the user clicks inside something like the settings container itself. When the user releases their mouse, we determine how far they moved their mouse - if the distance is within some threshold (~5 pixels in this case) then we can count it as a click. Because we've already filtered on the component they started their click in, we can safely rely on the presence of coordinates as a flag that they are in the right container, combined with the fact that they can't stray too far before their click not counting anyways.
Just do it by fixing the somewhat hacky logic to not break if the
target elements also have additional classes, like they do if the
toolbar is showing (I think it turns out this bug is only that it
doesn't work with the toolbar showing...)
Fixes https://github.com/vector-im/riot-web/issues/5658
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
Also:
- Make CookieBar ES6 class
- Alter phrasing on CookieBar
- Conditionaly display longer "...(See our ++cookie and privacy
policies++)." if policy link is configured.
This allows for filtering of the RoomList by group. When a group is selected, the room list will show:
- Rooms in the group
- Direct messages with members in the group
A button at the bottom of the TagPanel allows for creating new groups, which will appear in the panel following creation.
This code only kicks in if the user was ignored after an event was sent. The homeserver should prevent other events from coming in.
Signed-off-by: Travis Ralston <travpc@gmail.com>
With the fallback of existing behaviour, which is UserView (no middle panel and no avatar, display name).
To improve, MemberInfo should probably track the current roomId and userId and then update the view asynchronously by re-fetching the member object when either roomId or userId change.
Also, it should be hitting the profile API to get the user's avatar if a room hasn't been specified.
