Improved the webui pages for phone - #121
Open
defnax wants to merge 131 commits into
Open
Conversation
Added Board posts display Added for Network to list last Chats
Fixed css issues
Contributor
|
@defnax I feel there are some other |
Contributor
Author
|
I hate this scss, i get very often destroyed corrupted this |
Contributor
Sure take a look when you get chance. So, we need to be careful with the |
Contributor
Author
|
But i commited all changes what i see in my git app. |
* corrected some place holder text
Added Navbar for webui on phones for Boards and Channels: * Validate API responses before processing. * Keep rendering/navigation functional if a response is incomplete. * Log a clear warning instead of throwing an uncaught error. * Use independent sorted arrays, avoiding mutation of the master list.
Fixed channels thumbnail layout issue Added same comments design from boards to channels
Fixed layout issues for myfiles, friendfiles & search
Contributor
Author
|
@zelfroster new review? |
Contributor
|
@defnax I was working on streamlining some things and adding instructions, so the styles don't get messed up each time. Let me push the changes in a bit, we can merge that, and then after you update this PR accordingly, will review it. |
Contributor
Author
|
yes this issue with styles i get headdache, then i lose motivation when its destroyed and losing time |
defnax
changed the title
Contributor
|
Defnax please rebase this pr/121 on master so that it gets a chance to be reviewed and merged, and I can work on it. |
Contributor
@jolavillette @defnax What's the plan for webui rn btw? I mean broadly do we already have planned features to implement or things to improve? Since, we are going to use AI most probably to improve things here, it would be better to add an AGENTS.md with some specific instructions here too, else the webui product as a whole would have inconsistent looking UI/UX. |
Contributor
|
As far as I am concerned:
May I respecfully suggest that you also use AI to make a first pass on PRs, so that you can focus on what is worth your human time? IMO that's the way everything should go now in the whole RetroShare project. |
Contributor
Makes sense 👍🏼
Yeah, that's a great suggestion, I was thinking of doing that too. @csoler I was wondering if we can get an AI tool reviewer to automatically review PRs so the author's can fix the obvious issues etc, and then the actual reviewer can take a better look to save everyone's time and accelerate the work on webui maybe. |
Contributor
|
This one is a good AI reviewer to use if we can get it for our project - https://www.greptile.com/open-source |
Contributor
|
of course if that can be helpful. What we should avoid absolutely is the AI merging PRs by itself or even being able to modify the code in the repository. |
Contributor
Author
I had no time now my code broken i has some conflicts on my code with master |
Contributor
Author
|
I think after this merged i will make a break with webui |
Contributor
OK I will rebase it on master |
Once hashing starts there is no way out: Cancel is disabled, the backdrop click is guarded by the same flag, and the overlay covers the whole viewport, nav included. The only exits are the browser's Back button and a reload -- and Back does not even stop the poll, since the setTimeout chain runs off module state that nothing resets, so it keeps asking once a second for the rest of the session and the dialog is waiting again on the way back. That would be harmless if the wait always ended, but the core drops a file it failed to hash without a word: ftExtraList only records successes, so the file never enters mHashedList and ExtraFileStatus() answers "not ready" for ever. hashExtraFile() has already refused missing paths and directories by then, so this is the file that exists but cannot be read -- permissions, a share unmounted, an I/O error. The red button therefore stays enabled and reads Stop while hashing, the backdrop closes again, and leaving the view stops the poll: it writes its file link into that view's textarea, so once the view is gone the answer has nowhere to land anyway. The poll also backs off from one second to ten, since a large file legitimately takes minutes and each request opens a new connection.
…-for-121 The attach dialog must be escapable while it hashes
…r answered Select a contact, Profile details, Start chat: the tunnel goes green, what you type leaves and is echoed, and the answers never appear. They do arrive -- the core posts an RsChatMessageEvent for every incoming message and the handler runs -- they are just written into a list nobody displays. Giving each peer its own session pointed State.chatMessages, the array the view renders, at session.messages. loadChatMessages() then kept doing State.chatMessages = data.msgs: that reassignment does not update the session, it detaches from it. From that answer on there are two arrays -- the visible one holding the history, your echo and the status notices, and the session one where the event handler pushes everything the peer says. The `else if` fallback of the handler cannot save it either, since the session is always found first. It fires every time: the JSON API answers msgs: [] rather than nothing, so an empty history detaches just as surely as a full one. The session array is now the only one: it is mutated in place and State.chatMessages is never reassigned, only re-pointed at it. Messages carry a key -- direction, send time and text -- shared by the three sources, so the same message coming from the history and from the live event is stored once, and the status notices no longer need their manual text scan. Two windows were losing messages besides. The core emits its "starting distant chat" notice from inside initiateDistantChatConnexion, before the caller knows the pid, and rswebui buffers every chat event it cannot deliver; the tab also unregisters its handler when the user walks away. Both are covered by draining that buffer -- when the chat opens, when the tab mounts, and when the tunnel turns secure -- and by adopting the visible conversation for a message that names the pid the view is already showing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e knows Clicking Chats sets the counter climbing for minutes. It is not counting conversations, it is watching a probe walk the whole identity list: the tab re-runs preloadAllChatHistory(), which asks /rsHistory/getMessages once per known identity, and the badge is recomputed from the answers as they land. On a node that has seen twenty thousand identities that is twenty thousand requests, four at a time, against a JSON API that answers one at a time and closes the connection after each -- and it starts over at every click, on top of the three calls the layout and the sidebar already make when the page opens. Neither half of the probe can find anything. Distant chat history is not stored under the peer's GXS id. The core keys it by the tunnel id, sha1 of the two GXS ids sorted and truncated to sixteen bytes (p3GxsTunnelService::makeGxsTunnelId), so the query only ever answers an empty list and the previews appear solely for chats opened in this session. There is no API to derive that id and no crypto.subtle outside a secure context, the web UI being served over plain HTTP, so people_util now computes the digest and the probe asks for the tunnels of our own identities against that peer. Private chat history is keyed by a location, not by a person: the query passed the PGP id where an RsPeerId is expected. It is half the length, the core cannot parse it, so it builds a null id -- which is the key of the public broadcast history -- and prints a stack trace for every request. 1714 of them in one log here, over 979 distinct PGP keys. It now asks per location of the friend behind the identity, which is where the messages actually are. So the probe covers the peers a conversation can exist with -- contacts, peers already in the map, identities belonging to our friends -- instead of every identity ever seen, and it will not run twice within thirty seconds however many times the tab is clicked. The badge and the list read chatHistoryMap directly: it only ever holds peers with a real message, so the sweep of the identity list on every redraw bought nothing, and identity details are fetched for the handful of peers actually listed. The History dialog was asking the same two impossible questions and now asks the right ones. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The right pane keeps its last tab in State.activeTab, and that state is global rather than per contact. So the list item handler ends on "if the chat tab is the one showing, connect" -- which is never true on a fresh page, and always true afterwards. Once a conversation has been opened, every later click in the contact list requests a GXS tunnel toward whoever was just selected: a network action the other side sees, from a click that only meant "show me this profile". Selecting somebody now shows their profile, and the tunnel waits for the Chat Conversation tab. The three places that do mean it -- the tab itself, the Start Chat button, the Chats list and its context menu -- are untouched. The mirror case was broken the other way round. "Start private chat" from a chat room calls setSelectedId(id, 'chat'), which preselects the chat tab on a page that is not mounted yet; nothing ever opened the tunnel there, so the pane sat on its Connecting spinner for good. That intent is explicit, so it is now remembered and honoured once the own identities are loaded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…wered rsJsonApiRequest hands the callback the HTTP status, not the answer, and the button read that as "the tunnel is closed": any reply at all, including one that says nothing was closed, ended the conversation on screen. The core does report it, in retval, so that is what is read now, and the ended card says which of the two happened -- closed on request, or already gone before the click. The status poll had the same deafness and is what let it happen. Once a tunnel is gone from the core -- died of inaction, closed by the peer -- getDistantChatStatus answers false, and the poll only ever looked at the branch where it answers true. So the last known status stayed on screen for good: a conversation whose tunnel had been dead for a while kept its green dot and its "You can talk", and Leave Chat then had, quite correctly, nothing to close. Two consecutive false answers now end the conversation, with a line saying so, which is the state the user was in. Needs the libretroshare side to be meaningful: fix/distant-chat-close-keeps-contact makes closeDistantChatConnexion report whether it closed anything, and drop the distant chat contact it used to leave behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Edit dialog opens on an empty name field -- it is never filled from the identity it was given -- and Save sends whatever stands in it, so an edit meant for the picture alone renames the identity to nothing. The picture goes anyway: updateIdentity(id, name, avatar, pseudonimous, pgpPassword) takes the avatar as a mandatory parameter, p3IdService assigns it with no condition attached (group.mImage = avatar), and the request carried none. A missing JSON member is not "keep what you have", it is an empty image. The line that would have sent it has been sitting there commented out. So the name is filled in from the identity, an empty one is refused, and the current avatar is always sent back -- with a file picker to replace it, since the dialog now has to carry it either way. Deleting had the opposite problem: it announced success without reading retval, and refreshed nothing. watchOwnIds() is not a watcher, it listens for the event refreshOwnIds() emits, so an identity deleted from this page stayed in the list until something else happened to reload it. Two more in the same file: a refused passphrase left the Create button disabled on "Creating…" for good, since only .catch() cleared the flag and a refusal is a perfectly valid answer; and the passphrase dialog asked for a "passpharse" then reported "Successfully created identity." after an update. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tten
"Type" tested `mFlags === 14` against a bitfield. 14 is PGP_LINKED | PGP_KNOWN |
IS_OWN_ID, so the only identities that ever matched were our own signed ones: a
friend's signed identity carries 6, or 7 with the contact bit, and was labelled
"Anonymous ID". The bit to look at is RS_IDENTITY_FLAGS_PGP_LINKED, 0x2.
"Usage Statistics" mapped mServiceId over 1..8, but that field is an
RsServiceType -- 0x0211 for the identities, 0x0215 for the forums, 0x0217 for
the channels, 0x0012 for the chat. No case could match, so every line of the
panel came out as "Unknown (533)". The usage codes next to it are right, they
really do run 0 to 21; it is the service that was being read from another table.
The two timestamps read `.xint64` straight out of the field instead of going
through get64Num, which exists for exactly that: a 64 bit value arrives as
{xint64, xstr64} and large ones carry the string alone, where the pane then
shows "Invalid Date".
Details were also fetched once and kept for the whole session -- deliberately,
it is what makes the lists cheap -- which froze the reputation, the usage record
and the avatar of the profile being *looked at*. That one is now asked again
after a minute, over the top of what is displayed rather than by clearing it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things in the People chat pane, all about what happens between two conversations. The text being typed lived in a single page-wide field that nothing cleared when the selected peer changed, while the per-peer session carried an inputMsg nobody ever read. A message written to one contact was still in the box when the next conversation opened, one Enter away from the wrong recipient. Every write now goes through the session, and opening a conversation restores its own draft. Changing the identity we talk as opened a second tunnel and abandoned the first: the id is sha1(sorted(own || peer)), so another identity means another tunnel, and nothing closed the one being left. It is closed now, before the new one is asked for. The paperclip pasted the path itself into the message -- the peer received "/home/me/x.iso" and nothing else. It now publishes the file as an extra file and sends the retroshare:// link the core answers with, which is what the chat page does; the hashing runs behind a banner that says what is being hashed and can stop it, since a file that exists but cannot be read is dropped silently by ftExtraList and would otherwise be waited on for ever. And the failed-send alert blamed a packet size limit that does not exist: getMaxMessageSecuritySize() answers 0, unlimited, for distant chat, and the core slices anything past 15000 characters and reassembles it. The picture compression stays -- several megabytes of base64 through a turtle tunnel is still a bad idea -- but says why it is there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…eir choosing renderChatMessage turns any <img src="..."> found in a received message into a real <img>, and the browser then goes and gets it. On a distant chat -- carried by a turtle tunnel precisely so that neither end knows where the other is -- that hands the reader's address to whatever host the sender picked, and tells them the moment the message was read. Pictures embedded by RetroShare travel as data: URIs; anything else is now shown as the text it is rather than fetched. The rest of this commit is the People tab paying for its lists. "All Users" is every identity the node has ever seen -- this profile's gxsid_db is 35 MB -- and the sidebar rendered all of them, firing one getIdDetails per row from inside its own view. The list is capped at 200 rows with a line saying how many are left, and the search narrows it. jdenticon redraws an avatar's SVG on every call, and that call sat in the view of every avatar on screen: once per avatar per redraw, and a redraw happens on every answer of every poll. Same id and same size, same drawing -- memoised. The history browser is mounted with the page and draws nothing until asked for, so its oninit was the moment a *conversation* opened, not the moment somebody wanted the history: opening a chat ran "give me every message ever stored" for a panel nobody had asked for. It loads when it opens now, which also fixes the chat page, where the panel was loaded once at mount and never again. Its overlay follows the three others onto dvh. Two small ones: adding or removing a contact from the context menu reloaded the identity summaries alone, while isContact is read from rs.userList.userMap, which only loadUsers() refreshes -- so the list kept showing the old state; and about 250 lines of unreachable code are gone, people_own_contacts.js entirely, the "Own Identities" widget of people_ownids.js, the second search box of people_util.js and the isSearched marking those two shared, which contactlist() and sortUsers() still wrote from inside a view. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
People tab: distant chat repairs and a full audit pass
zelfroster
requested changes
Aug 20, 2026
zelfroster
left a comment
zelfroster
left a comment
Contributor
There was a problem hiding this comment.
This PR has grown quite big, when we have reached a certain point we should plan to review and merge it and do further work in separate PRs.
Contributor
Author
|
big work is done next time then only small prs |
Contributor
Author
|
@zelfroster soon merged not yet done finish review? |
Contributor
It will take some time to finish review. |
The Refresh button was guarded by a `loading` flag set once at oninit and never raised again, so it only ever disabled itself before the first answer. After that every click fired two more requests, on top of the five second interval, with nothing preventing two runs from overlapping -- and on a phone they do overlap, since each answer closes its connection and the core serves them one at a time. `load()` now refuses to start while one is running and always clears the flag, including on the paths that throw. Friend names came from a second collection of the friend list -- getFriendList plus one getPeerDetails per friend, all at once -- run exactly once, at oninit: a friend added afterwards stayed `Peer 1a2b3c4d…` until the page was reloaded. network_data already does that work and keeps it in NetworkData.gpgDetails for the whole session, so the page reads that and asks for a refresh at most once a minute rather than never. `formatBytes` was a second implementation of `rs.formatBytes`, printing MiB where the statusbar, the chat and the file lists print MB for the same number. The pie segments are rotated back to twelve o'clock, where a pie chart is read from; the totals in the middle stay upright.
The address fallback deduces "local or external" from the RFC1918 ranges, but the core already says which is which: getPeerDetails appends its own marker to every ipAddressList entry, " 123 sec loc" or " 123 sec ext" (p3peers.cc). Guessing instead gets two cases wrong -- a peer behind CGNAT (100.64/10) or a double NAT has a private looking external address, and a loopback entry is not external at all -- where the marker is always right. The parser was also IPv4 only, which misses the very case the fallback exists for: GetRetroshareInvite() clears extAddr and moves the address into ipAddressList when it is IPv6, because the certificate format only carries IPv4 numbers, so a peer added by short invite over IPv6 has an empty external address and an entry the regex could not read. RsUrl wraps IPv6 hosts in brackets and escapes the % of a link-local scope id as %25; both are handled, and the entry with no marker at all -- the one that invite path produces -- is external by construction.
Statistics page: overlapping polls, a second friend collection, a second formatBytes
…r-121 Peer addresses: read the core's loc/ext marker, and handle IPv6
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.