Background colours for messages would be a useful addition to the matrix web interface because some bridged systems support this functionality, namely IRC. This can be problematic when an IRC message is sent across which has white text and a black background. The text could become difficult to read when against the potentially light background of a matrix client.

A suggestion is to modify the HTML sanitation of <font> tags so that

    <font color="white" data-matrix-bg-color="black">Hopefully visible text</font>

is transformed into

    <font color="white" style="background-color:black;">Hopefully visible text</font>

whilst checking for CSS injection of the provided bg-color.

Given that CSS injection needs to be checked for anyway, perhaps a better solution would be to accept the style attribute and only allow color and background-color attributes to be allowed. http-sanitize sadly doesn't support this functionality, but it could be written separately.

Sanitization within matrix-react-sdk:
https://github.com/matrix-org/matrix-react-sdk/blob/24223ae2b69debb33fa22fcda5aeba6fa93c93eb/src/HtmlUtils.js

(See matrix-org/matrix-appservice-irc#62)

I want to use chat application in one of my project and I found out this SDK. I setup SDK and follow the steps which is given in Readme.md file. After fire the commnad yarn start in terminal this command was executed babel src -w -s -d lib --verbose --extensions ".ts,.js" the src file converts into lib file and "then the watcher is ready" prints. So how can I see the login page or any view page I can see?

Please guide me over here.

https://github.com/vector-im/element-web/issues/new/choose

Hi guys, got a bug for you in /src/Notifier.js that actually comes from the electron Riot-web client: the desktop notifications initially work until it's checked OFF. Then it can't be re-enabled and throws the error:

Notifier.js:132 Uncaught TypeError: Cannot read property 'done' of undefined

Afterwards if you check this option, it will uncheck again whenever one of the radio buttons is selected and the page gets updated.

Description

I have a fork of matrix-react-sdk that I use as a subtree in my project.
When trying to build my fork, it fails when running the command :
yarn build:types

output :

error TS2688: Cannot find type definition file for 'testing-library__jest-dom'.
  The file is in the program because:
    Entry point for implicit type library 'testing-library__jest-dom'


Found 1 error.

I didn't touch any configuration files or added any dependencies in the project.

Currently this is solved with the workaround that the user does not even get the option to start a new call if there is a running one.

But in the future it would be nice if starting a new call would first disconnect the old call and then connect the new one.

All the requirements are in place:

• The new call needs to wait until it can become sticky -> since there is always only one widget that can be sticky, we would kill the running widget by making the new one sticky. This is solved by a stickyPromise that needs to resolve before we can connect the new call.

It seems the issue is, that if a call is hung up the roomview will dispatch an action with view_call = false this action will kill the newly started call...
The logic is correct: only dispatch with view_call = false if there is no active call. But due to a potential race there seems to be no active call even though there should be. Maybe checking CallStore.instance.getCall could reveal if there is another call and one should not dispatch view_call = false

In a 1:1 private conversation with another person, when receiving a call, the avatar icon is stretch :

As it is:

As it should be:

The issue is due to the flex box of the parent element > mx_IncomingLegacyCallToast

I am having an issue to run the element react font-end app on my local environment when I try to run this command is the matrix-react-sdk with yarn like yarn start It will start building the app instead of opening on localhost, I don't want to run the entire app I just want to run only front-end app, React-app only, can you tell me how can I archive this?

some certification bodies requires disabling clipboardEvents. I will update this later on with any doc i can share.

This can impact govt and financial institution adoption of element-web (and other clients using this SDK) as it breaks pasting to the div-as-input component here.

Not to mention usability/18n as several niche browsers/extensions/ime input do not work well with that pattern.

you can simulate cases where that feature is not available on firefox, about:config, dom.event.clipboardevents.enabled=false. copy and cut (with preventDefault at the end of the methods) works fine. Only paste is impacted currently.

step 1: send a voice message into room.

step 2: to other view and back to room view.

repeat step 2. We got may worker in memory

like:

Hi all. Is there any normal documentation for this project, API description?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• Update dependency @testing-library/jest-dom to v6.4.5
• Update all non-major dependencies (eslint-plugin-jest, mcr.microsoft.com/playwright, posthog-js)
• Update dependency @matrix-org/matrix-wysiwyg to v2.37.1
• Update dependency @sentry/browser to v7.113.0
• Update stylelint (stylelint, stylelint-scss)
• 🔐 Create all pending approval PRs at once 🔐

Pending Status Checks

These updates await pending status checks. To force their creation now, click the checkbox below.

• Update definitelyTyped (@types/lodash, @types/node)
• Update dependency axe-core to v4.9.1
• Update dependency @playwright/test to v1.44.0

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update testing-library monorepo (major) (@testing-library/dom, @testing-library/react)
• Lock file maintenance

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update Sibz/github-status-action digest to faaa4d9
• Update dependency @casualbot/jest-sonar-reporter to v2.3.1
• Update dependency eslint to v9
• Update dependency is-ip to v5
• Update dependency maplibre-gl to v4
• Update dependency matrix-events-sdk to v2
• Update dependency node-fetch to v3
• Update react monorepo to v18 (major) (react, react-dom)
• Update react-types to v18 (major) (@types/react, @types/react-dom)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Should I simply change this to "if we're NOT currently in a 1:1..., start a new chat"

or send in the following

diff --git a/src/components/views/rooms/MemberInfo.js b/src/components/views/rooms/MemberInfo.js
index ddd0d1f..cc0351d 100644
--- a/src/components/views/rooms/MemberInfo.js
+++ b/src/components/views/rooms/MemberInfo.js
@@ -365,15 +365,9 @@ module.exports = React.createClass({
             var currentRoom = MatrixClientPeg.get().getRoom(this.props.member.roomId);
             currentMembers = currentRoom.getJoinedMembers();
         }
-        // if we're currently in a 1:1 with this user, start a new chat
-        if (currentMembers && currentMembers.length === 2 &&
-            userIds.indexOf(currentMembers[0].userId) !== -1 &&
-            userIds.indexOf(currentMembers[1].userId) !== -1)
-        {
+        if (no_existing_private_one_on_one()) {
             existingRoomId = null;
-        }
-        // otherwise reuse the first private 1:1 we find
-        else {
+        } else { // reuse existing private one on one
             existingRoomId = null;

             for (var i = 0; i < rooms.length; i++) {
@@ -391,6 +385,11 @@ module.exports = React.createClass({
                 }
             }
         }
+        function no_existing_private_one_on_one() {
+            return currentMembers && currentMembers.length === 2 &&
+                userIds.indexOf(currentMembers[0].userId) !== -1 &&
+                userIds.indexOf(currentMembers[1].userId) !== -1;
+        }

It would be nice to support the rendering of LaTeX formulas, both text and displayed formulas.

I hope this is the right place to put this feature request.

Hello, I've tried to setup matrix-react-sdk in order to use matrix chat and its UI components and etc in my app. But I can't find any valid examples and all the time just get that matrix-react-sdk is not resolved by webpack, can you please help me or just give the link to the valid documentation of how to start it from scratch or something?

Spoke with @dbkr today about the split of React SDK and skins on top. This issue is a huge summary of the discussion and some proposals moving forwards.

Problems with the existing architecture

There's a number of issues currently which I feel aren't so great, including:

• The view/controller approach was intended to allow people to replace the entire HTML(view) but keep the underlying controller logic. In practice, there's tighter coupling here than you'd think and it's not always clear what should go where (e.g. I click a hide/show button which changes state, this is logic so you'd think controller. but it's purely aesthetic information from the view).
• Augmenting controllers doesn't really work. One of the main problems we both identified was Vector's RoomView controller which is a c/p of the React SDK one with some conference specific guff added. This trips people up (both of us included) when instinctively modifying the React SDK's controller and expecting it to work. It doesn't because the Vector one is entirely clobbering the React SDK one, not augmenting it.
• Coupling between controllers and views makes it very easy to introduce subtle breakages. A good example of this is the CreateRoom controller in the React SDK which calls a function which is only defined in the Vector skin (which means it'll crash on anything not vector). A similar subtlety is when views call functions seemingly not defined anywhere (because they're defined in their controller).
• The API surface exposed by React SDK is not well-formed. You can't really make an API reference for it. We have some classes which do some things but there's no real place to get a reference of what you can do aside from examples.

Proposed solution

Rather than splitting along the View/Controller, I propose splitting along component boundaries. In practice, this means:

• Combining the views/controller for a class together.
• Exposing a set of reusable components that the layers on top (Vector) can use.

The biggest concerns with this was "how do you prevent the layers on top from re-implementing all the logic that the SDK does?". My proposal is to make the components extremely thin, stateless UI code and that's it. Currently, the controllers do a lot of "business logic" like making API calls, dispatching actions to the rest of the app, etc. This is good but shouldn't really reside in the controller for a specific component. Take for example resending messages. Previously, you could hit a message and hit Resend which would do the API call and dispatch actions to the rest of the app. When I came to implement "Resend all" in a different component I couldn't easily reuse the existing code to resend a single message because it was tightly coupled with the component it resided in (setting things like this.state and this.props which my new component didn't want).

The proposed architecture would resolve these issues by effectively having "stateless UI components" and "wire components" which glue up other components and make calls through to the React SDK. Every component would accept props which govern their inputs and callbacks that they'd invoke. They would look something like this (using an example of leaving PR comments):

Syntax:
ComponentName(Type propInput, Type propInput)


PullRequestPage(String repo, Integer pr)
     |
     |_____________ PullRequestSummary(PullRequest pr)
     |_____________ CommentListView(Comment[] comments, Boolean showCommentBox, Callback onSubmitText)
                            |
                            |________CommentView(Comment comment)
                            |________CommentView(Comment comment)
                            |________CommentView(Comment comment)
                            |________ ...
                            |________CommentBox(Callback onSubmitText)

An implementation of CommentView would be extremely thin, basically just the render() method:

module.exports = React.createClass({displayName: 'CommentView',
    propTypes: {
        comment: React.PropTypes.any.isRequired
    },
    render: function() {
        return (
            <div className="CommentView">
                <img className="CommentView_avatar" src={
                    comment.getUser().getAvatarUrl()
                } />
                <div className="CommentView_header">
                    {comment.getUser().getName()} commented {
                        comment.getTimeAgo()
                    } ago <a href={comment.getLink()} target="_blank">(Source)</a>
                </div>
                <div className="CommentView_body">
                    {comment.getBody()}
                </div>
            </div>
        );
    }

If you wanted to add any UI-only state (show/hide, etc) it would reside in this file. If you wanted to do anything like say delete the comment, you would add a new prop onDeleteClick which will be called when they hit the delete button. This allows massive code reuse. For example, in Github's case you hit two different endpoints depending on whether you're interacting with Line Comments or PR comments. This UI component need not care, it just knows how to display the comment and a delete button. If one of the APIs didn't expose a deletion endpoint, you could easily add a prop to hide the delete button (or do inference e.g. "if there is a delete callback, I'll show a delete button").

By using props everywhere, we encourage "bubbling" of callbacks up from children to parents (See how onSubmitText is bubbled up from the CommentBox to the CommentListView to the PullRequestPage). This is a bit boilerplatey but is situationally useful (e.g. to disable the parent UI if you're sending a message from the child). There is no hard and fast rule on whether you should bubble or not other than asking if the component you're writing might be reused in another part which may have different logic (think the GH commenting example). Both uses are valid.

Dispatcher

The dispatcher would remain similar to as it is today but with a much stricter split between React SDK triggered actions and other stuff (e.g. Vector-specific triggered actions). Layers on top of the SDK would be almost exclusively consumers of SDK actions from the dispatcher, and would be able to produce/consume actions in their own layer with a sensible prefix e.g. vector_. Layers on top may in rare cases want to emit SDK-level actions for more exotic behaviour but it should be rare. Doing this means if you're following through some code you can have greater intuition of the control flow between the different layers based off a helpful action name.

Business logic

This relates to the "resend" example I gave earlier. The proposal here is to have a set of "pure logic classes" which:

• Make JS SDK API calls.
• Emit actions on the dispatcher.
• Manage any internal state (e.g. call state).

We already have started to organically grow these with CasLogic, CallHandler, SlashCommands, TextForEvent, WhoIsTyping and so on. I propose we formalise this concept (e.g. into a logic directory) split on concept boundaries (Calls, Messages, Auth, /commands, etc). These can either be "statically" linked into the React class (like we currently do by require()ing them) or by DIing them as additional props. This brings me onto...

Testing

Testing React components and UIs in general is Hard. We basically have two options. Test visually by comparing to "known working" snapshots and test by using shallow rendering (basically it dumps render()'s HTML output to a string which you can then test for equality. I dislike both of these. A change to the HTML <div> ordering shouldn't break the tests IMO. To this end, I do not propose testing React components directly, but instead the business logic classes. This is one of the reasons why the proposed architecture has extremely thin UI components with not a lot that can go wrong in them.

Example control flow

• [MessageComposer] User hits a button to send a message. Invoke a prop callback with the raw input string.
• [BottomRoomBar] Maybe augment the raw input string (e.g. imagine if a "Markdown" check box was enabled) then invoke a prop callback.
• [RoomView] Call through to a logic class e.g. MessageController.
• [MessageController] Do the API call and get a Promise. Maybe immediately emit a "sending" action on the dispatcher so other UI components not on the critical path can grey out their buttons. Attach a resolve/reject listener to emit a "sent" or "failed to send" action. Return the Promise.
• [RoomView] Return the promise.
• [BottomRoomBar] setState to display a spinner. Attach a resolve/reject listener on the promise to hide the spinner depending on the outcome. Return the promise.
• [MessageComposer] Grey out the UI. Attach a resolve/reject listener to un-grey the UI after it succeeds/fails.

This gives components a lot of flexibility. If components are on the critical path of parent-child relationships, more often than not they want to do stuff so rather than forcing them to listen for the "dispatcher" actions (which emulate a request/response cycle which is by far better represented as you know, a function call) they can just hook in before the bubble back the response. Furthermore, in this control flow everything is explicit. Your boundaries (the props) are well-defined.

Outstanding problems

• Augmenting components (the RoomView example) remains a thorny issue. This modified the render() method and added in extra props to the React SDK RoomView. With RoomView as it is, there is no good solution to this. You can't even abuse mixins because you can only have One True render() method which would need to know the "base" React SDK HTML and then the "extra" Vector HTML on top. To this end, a rather unsatisfying (though probably correct) solution would be to keep as much shared code as possible and then clobber the rest. In practice, this would mean breaking RoomView up into smaller stateless UI components and then switching to the Vector-specific code higher up the chain when you're just gluing together components. This results in less code duplication and prevents you from opening the "wrong" file (because you're loading a different component entirely rather than the same component with a different controller backend.

Next steps

If @ara4n and @dbkr are in agreement, the "actionable" steps to take on this would be:

• Go through on a component-by-component basis and combine the view/controller. Suck out anything which is not exclusively UI-related into a logic class. Aggressively define and inject props when you need some data to work with (rather than yanking it from MatrixClientPeg) and think about what callbacks you want to provide (e.g. RoomList may want to just have onRoomClick(Room), MessageComposer may want onTabClick(inputText), onSubmit(text), etc). Make Vector either use the pure-UI class that is left if the HTML is right, or write the pure-UI class and use that instead. This can be done incrementally for each component without requiring one huge branch/PR/merge.
• If Vector emits any actions specific to it (e.g. conf call stuff?) then add the vector_ prefix.
• Start adding tests for the logic classes we've pulled out of the components.

What the React SDK API reference would look like

• A list of Components each with:
  • A name.
  • A list of defined properties with types (from propTypes) documenting the inputs/callbacks.
  • A list of actions that it will be listening for.
  • A list of actions that it emits (with args).
• A list of "logic" classes with JSDoc. Any component is free to directly call these.
• An "action" reference. This is a complete list of actions that the SDK emits each with:
  • A name.
  • Names of keys / values with types on the payload.

Most components will be stateless UI components but some components may be "wire" components which could form the basis of Matrix React Console (though it would need CSS).