Element-web: No way to remove avatars from user/room settings

[turt2live]

Previously we had a red X floating on the edge of the avatar in the settings. This caused confusion as to what this does as people thought it was a close button. We should consider not using an X and maybe use the literal word "remove" under the avatar.

[t3chguy]

Or a 🗑

[Thatoo]

Getting back a [new] system to delete avatar is important, at least in direct chat for the two "chatter" to be able to get back each other's profile picture as their direct chat room's picture.

[nadonomy]

Updated our (internal) Zeplin with a proposal: https://zpl.io/a759PvY

Essentially, changing the hover text when a pic is set, and providing the option to remove with a context menu:

(Note that this comp is using our old palette as it's from a legacy source file)

[Thatoo]

Today, I could find a way to delete the room picture of a direct chat thanks to Fluffychat.
After that, the room picture became, for me, the profile picture of my friend, as expected, in Fluffychat and in Riot webapp (on desktop Ubuntu).
However, in Riot Android, the room picture became the first letter of my friend's nickname, not his profile picture and stayed like that even after he decided to change his profile picture...
Is it related to this issue or should I open an other issue?

[t3chguy]

context menu in modal is surprisingly finnicky, all clicks inside the context menu get ignored for some reason :((

[turt2live]

@t3chguy There's a whole comment somewhere saying "GAHHHH LAYERING!" or something along that lines - may have to take a peek at how that works. I think the example was the "Copied!" text for the share dialog.

[t3chguy]

I narrowed it down to the focus trap in BaseDialog, the copied in share dialog I did a long time back and it does no click handling so is unaffected.

Any chance you could explain why we need this focus trap thingy? I seem to be missing the point

[t3chguy]

Chrome's inspector being able to breakpoint all mouse click handlers is infinitely useful, also kinda scary that all my clicks get sent to my chrome extensions, should really investigate which extension was installing a global click handler.

[t3chguy]

So some combination of

• magic from https://github.com/davidtheclark/focus-trap-react/issues/27
• switch to https://github.com/theKashey/react-focus-lock

should help here

[turt2live]

the copied in share dialog I did a long time back and it does no click handling so is unaffected.

Although it does no click handling, the layering of context menus (and thus tooltips) was changed recently. Suspected it to be something strange in the element having a high z-index but the click being under a transparent pane.

[t3chguy]

It isn't that, I tested with an anchor tag and left click didn't work but middle click opened a new tab. I am 100% certain this is focus trap capturing the click before react propagates it, I verified this by stepping through the code.

It's because focus trap checks to see if the click was inside the trapped dom element but context menus and modal are portals so live in their own DOM trees.

[t3chguy]

This should be easier after https://github.com/vector-im/riot-web/issues/10697

[florian2833z]

Any updates??

[t3chguy]

I am soon rewriting context menus for accessibility purposes, this might unblock this but it is not guaranteed

[florian2833z]

May I ask why this was even removed in the first place?

[turt2live]

The design was changed, and was likely just an oversight.

[t3chguy]

Rewriting context menus simplified this due to React Portals