Files
ThreadNet-Web/apps/web
David BakerandGitHub 5065683658 UI for setting user status (#33856)
* First stage

 1. Make avatar BIGGER!
 2. Move status button out to its own component so we can reuse it

* Working version

but using context menu rather than dropdown menu which almost looks
right but not quite.

* Commit the set status view component

* Change to use dropdown with custom trigger

* Show full set status component in user menu

and styling tweaks

* In user menu, clicking takes you to settings

* Add the view model

* oxfmt

because apparently mine had decided to go away

* Fix type import

* Pass set status viewmodel in story

* Bump compound-web

for customisable dropdown

* Snapshot

* Add explicit aria label

as combobox role things don't just inherit from their inner text

* snapshot again

* Only show user status if feature flag enabled

* Make status btton view not a button

because it doesn't need to be. Also rename accordingly.

* Screenshots

* Disable in settings if feature flag off

* Snapshot

* Snapshot again

* Update screenshots

including room settings one which wasn't really supposed to change
although the avatar now takes up the space it's in - leaving it for
design to check.

* Fix size & positioning of the status button

* Update screenshots

* Screenshots

* Test for SetStatusViewModel

* Update set status view on status change

* Use a link component for the status button

which has built in hover state

* Float the status button in a 28px container

vs making it actually 28px min height

* Separate user menu profile into two sections

With 8px gap between things in the two sections and 12px gap between
sections (ie. in practice, 12px gap between the status control and username).

* Screenshot

* Screenshots

* Pass set status view model in the state

rather than as an extra prop. Fixes it in the story too.

* Pass ownprofilestore into the viewmodel

* Don't use snapshot for testing the view model

Avoids getting all the random stuff from the sub VM in the snapshot
and better to test what we care about anyway.

* don't mention the bad word

* Here too

* Don't show user status for guests

* Update guest story to remove user status
2026-07-06 19:28:34 +00:00
..
2026-03-20 15:17:07 +00:00
2026-03-24 13:33:49 +00:00
2026-07-06 19:28:34 +00:00
2026-07-06 19:28:34 +00:00
2026-07-06 19:28:34 +00:00
2026-05-29 08:26:59 +00:00
2026-06-30 15:21:42 +00:00
2026-07-01 14:51:08 +00:00
2026-06-08 10:32:55 +01:00

Important Security Notes

Separate domains

We do not recommend running Element from the same domain name as your Matrix homeserver. The reason is the risk of XSS (cross-site-scripting) vulnerabilities that could occur if someone caused Element to load and render malicious user generated content from a Matrix API which then had trusted access to Element (or other apps) due to sharing the same domain.

We have put some coarse mitigations into place to try to protect against this situation, but it's still not good practice to do it in the first place. See https://github.com/element-hq/element-web/issues/1977 for more details.

Configuration best practices

Unless you have special requirements, you will want to add the following to your web server configuration when hosting Element Web:

  • The X-Frame-Options: SAMEORIGIN header, to prevent Element Web from being framed and protect from clickjacking.
  • The frame-ancestors 'self' directive to your Content-Security-Policy header, as the modern replacement for X-Frame-Options (though both should be included since not all browsers support it yet, see this).
  • The X-Content-Type-Options: nosniff header, to disable MIME sniffing.
  • The X-XSS-Protection: 1; mode=block; header, for basic XSS protection in legacy browsers.

If you are using nginx, this would look something like the following:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Content-Security-Policy "frame-ancestors 'self'";

For Apache, the configuration looks like:

Header set X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set X-XSS-Protection "1; mode=block"
Header set Content-Security-Policy "frame-ancestors 'self'"

Note: In case you are already setting a Content-Security-Policy header elsewhere, you should modify it to include the frame-ancestors directive instead of adding that last line.

Building From Source

Element is a modular webapp built with modern ES6 and uses a Node.js build system. Ensure you have the latest LTS version of Node.js installed.

Using pnpm instead of npm is recommended. Please see the pnpm install guide if you do not have it already.

  1. Install or update node.js so that your node is at least the current recommended LTS.
  2. Install pnpm if not present already.
  3. Clone the repo: git clone https://github.com/element-hq/element-web.git.
  4. Switch to the element-web directory: cd element-web/apps/web.
  5. Install the prerequisites: pnpm install.
  6. Configure the app by copying config.sample.json to config.json and modifying it. See the configuration docs for details.
  7. pnpm dist to build a tarball to deploy. Untaring this file will give a version-specific directory containing all the files that need to go on your web server.

Note that pnpm dist is not supported on Windows, so Windows users can run pnpm build, which will build all the necessary files into the webapp directory. The version of Element will not appear in Settings without using the dist script. You can then mount the webapp directory on your web server to actually serve up the app, which is entirely static content.

config.json

Element supports a variety of settings to configure default servers, behaviour, themes, etc. See the configuration docs for more details.

Labs Features

Some features of Element may be enabled by flags in the Labs section of the settings. Some of these features are described in labs.md.

Caching requirements

Element requires the following URLs not to be cached, when/if you are serving Element from your own webserver:

/config.*.json
/i18n
/version
/index.html

We also recommend that you force browsers to re-validate any cached copy of Element on page load by configuring your webserver to return Cache-Control: no-cache for /. This ensures the browser will fetch a new version of Element on the next page load after it's been deployed. Note that this is already configured for you in the nginx config of our Dockerfile.

Development

Please read through the following:

  1. Developer guide
  2. Code style
  3. Contribution guide

Extending Element Web with Modules

Element Web supports a module system that allows you to extend or modify functionality at runtime. Modules are loaded dynamically and provide a safe, predictable API for customization.

What are modules?

Modules are extensions that can add or modify Element Web's functionality. They are: