The Chat badge now counts pending room invitations, but the web UI only offered
to accept one: denyLobbyInvite() exists in the core and was called nowhere. An
invitation left alone therefore kept the badge lit for good, with no action able
to clear it. It can be declined now -- the entry leaves the room list with it,
since it came from the invitation and not from the nearby lobbies.
An invitation also carries no participant count: ChatLobbyInvite has lobby_id,
peer_id, lobby_name, lobby_topic and lobby_flags, and total_number_of_peers only
exists on the records the nearby list returns. The detail panel claimed "0 users"
for every invited room, and the join-failure message read the same missing field
to conclude the room was "no longer advertised by an online participant" --
a wrong diagnosis when the real cause was a refused identity.
The version label also went back to v154 on the way in: the four merges of #23
to #26 each resolved main.js by keeping the lower number, so the branch says
v154 while carrying the code of v157. Set to v158 rather than restoring v157,
since the composer spacing and the invitations landed after it.
A room opens on its last 20 messages and that was all there ever was: reaching
the top of the pane loaded nothing, so anything older was only reachable through
the separate history browser.
Scrolling near the top now asks for a larger slice. p3HistoryMgr::getMessages
takes a count and nothing else -- no cursor, no "before this message" -- and
always answers with the newest ones, so the only way to reach older text is to
ask for more and let addMessages() drop what is already held. It re-sends what
we have, which is the price of that API; the slice is small, and the core keeps
ten days at most anyway.
An answer shorter than the count asked for means there is nothing older left,
and the pane stops asking. The opening slice stays at 20: every room opening
pays for it, and on a phone each request is a fresh connection on a core that
answers one at a time.
Older messages are inserted above what is on screen, which would push the
conversation down by their height; that height goes back into scrollTop, so the
reader does not move while a slice lands.
The message pane scrolled to the bottom from its onupdate, unconditionally. That
hook runs on every redraw of the chat hub -- an incoming message, a poll answer,
a keystroke in the composer -- so scrolling up to read anything older was undone
a few tens of milliseconds later, every time.
It now follows the reader: the pane stays pinned while it is already at the
bottom, stops as soon as it is scrolled away from it, and pins again when it
comes back. Sending a message still jumps down whatever the state, and switching
room opens on its last message, since the pane is reused rather than recreated
and its oncreate does not run again.
The scroll handler sets event.redraw = false: mithril redraws after every
handler by default, and this one fires continuously while the pane is dragged.
The overlay carries role=dialog and aria-modal=true, but its Escape handler sits
on the overlay itself and therefore only sees what bubbles through it. The close
button is focused on open, so Escape works -- until the first tap on the picture,
which moves the focus to <body>: from then on the only way out is the close
button or the Back button.
The handler moves to the document, in the capture phase, and is removed when the
preview closes. Tab is caught there too: aria-modal promises the rest of the page
is inert, and without it the focus walks straight out of the preview into the
message list behind it. Closing also puts the focus back on whatever opened the
preview rather than dropping it on <body>.
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>
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.
Every JSON API answer carries `Connection: close` and the server runs its
service on a single thread, so each request costs a full TCP handshake and they
are answered one at a time. Over loopback a round trip is 0.1 ms and none of
this shows; over WiFi or 4G it is 20 to 80 ms and the three patterns below turn
into seconds of blank screen.
Chat room list: one getChatLobbyInfo per subscribed room, and nothing was
painted until the last answer arrived -- then only did the public room list get
asked for. Paint each room as it lands and start the public list immediately.
Forum post bodies: loadPostContent() is called from the view, and the body stays
null for the whole round trip, so every redraw fired the same getForumContent
again -- and each of the other posts' answers causes a redraw. An open thread
multiplied one request per post into one per post per redraw. Guarded by an
in-flight set, kept on failure so an unavailable post is asked for once per
visit rather than forever.
Chat history preload: two getMessages per known identity, hundreds of them at
once, filling the browser's six sockets and the single service thread while the
user waits for something else. Run four at a time. The duplicated response
handling of the two branches is now one function.
- The Graph shortcut is hidden from the default friend list.
- After selecting a friend, Network Graph remains available in the detail tabs.
- Desktop behavior is unchanged.
- File and picture attachments now share one paperclip button.
- The message field gains more horizontal space on phones.
- Correct full-certificate friends being incorrectly marked “Pending validation.”
- Refresh identity lists immediately after creating an identity.
Update open chat-room and distant-chat identity selectors automatically.
- Replace the broken signed-identity password popup with a responsive mobile form.
- Allow creation of the first signed identity without requiring an existing signed identity.
Filter temporary all-zero GXS IDs.
- Wait for RetroShare to expose the real generated identity ID.
- Retry identity-detail loading when RetroShare temporarily returns empty data.
- Display the fetched nickname instead of “Unknown.”
eslint reported them and nothing references them: they are the previous
generation of UI, superseded in place.
channels/channel_view.js
displaycomment() and the AddComment form it opened, replaced by renderComment()
and ChannelComments. displaycomment only referenced itself, recursively, which
is why it looked used.
chat/chat.js
LayoutSingle, the single chat room layout that predates the hub, and with it
LobbyList, Lobby, SubscribedLobbies and PublicLobbies, which nothing else
called. Six names imported from chat_state were unused as well.
Kept as its own commit so it can be reverted alone if any of it turns out to be
wanted again.
Chat messages are carried as HTML. renderChatMessage() strips the tags but
never decodes the entities left behind, and the result goes into a mithril
text node, so they reach the screen verbatim.
The visible case is a plain space: RetroShare sends the message as HTML as
soon as the composer holds any formatting, and QTextDocument::toHtml()
turns leading and repeated spaces into , which the web UI then
displays as that literal string. &, < and > were affected the
same way.
The three call sites that turned HTML into text carried the same sequence
of replacements, so they now share htmlToText(). Decoding goes through a
textarea rather than a div on purpose: the content model of a textarea is
plain text, so no part of a message can be parsed into an element. Nothing
is trusted as markup at any point.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
master gained an eslint config in 35c5c17 and the code added here predates
it, so `npm run lint` fails on this branch. This commit is the mechanical
part only, produced by `eslint app --fix` with no hand editing:
object-shorthand, quote style, trailing whitespace, prefer-const.
Twenty-two problems are left because they need a decision rather than a
rewrite rule, the two worth looking at first being real:
boards/board_view.js:499,503 'forumId' is not defined (no-undef)
`renderComment` calls `util.voteForPost(forumId, ...)` for the up and down
vote buttons, but no `forumId` exists in that scope - it looks like it came
over from the forums code. Voting on a board comment therefore throws
ReferenceError and silently does nothing.
The other twenty are unused bindings left behind by the refactors
(`get64Num`, `loadLobbyDetails`, `Message`, `SubscribedLobbies`,
`PublicLobbies`, `LayoutSingle` in chat.js, `closePopup` in
board_kanban.js, `bsubscribed`/`bposts`/`createDate`/`lastActivity` in
boards_util.js, `displaycomment` in channel_view.js) plus a few dead
assignments. `npm run lint` lists them all.
Drop this commit if you would rather keep the diff to your own changes.
Brings the branch up to date with master so #121 can be merged again.
Eight files needed a decision. The branch predates 41111cb ("restore WebUI
styles in SCSS sources"), which recovered into the SCSS a number of rules
that until then existed only in the compiled styles.css, so most conflicts
are that recovery meeting the changes made here. Where both sides describe
the same element the branch's version is kept; where master's rule is a
positioning context the branch has no equivalent for, master's is kept:
* _chat.scss - master's attach-modal, emoji-picker, rightbar context menu
and create-lobby-button rules are kept alongside the compact-message
styles added here. Taking either side whole would have dropped about
450 lines. .chat-own-profile-card, .chat-hub-rightbar and
.chat-hub-rightbar .user keep `position: relative`, because
.chat-create-lobby-btn and .rightbar-context-menu are still declared
`position: absolute` further down and would otherwise escape to the
initial containing block. For .user-tooltip the branch's `position:
fixed` rework wins, and master's `.chat-hub-rightbar .user-tooltip
{ left: -275px }` offset is dropped since it would fight a fixed
element.
* _people.scss - master's restored .friends-list-container context menu
is kept; the pane rules it also restored are shadowed by the branch's
own !important versions and were dropped as dead code.
* boards_util.js - the revived updateContent() and the in-flight dedup in
updateDisplayBoards() are kept. Master's side of the first two hunks
was comment reformatting only.
* board_view.js - the rewrite here is kept whole. Master's only change
since the fork point was `let reader` -> `const reader`, in code the
rewrite replaced.
* chat.js - the modals moved out one nesting level here; that structure
is kept.
* chat_state.js - `require('people/people_util')` is not restored. It is
unused, which is why 35c5c17 removed it.
* build.sh - master's version. The change here concatenated raw .scss
onto the generated CSS; see the following commits.
* styles.css - regenerated, see the following commits.
Add Chat improvements
Added Send Chat & Mail for Parcipants list
Added tooltip functionality
Improved Identiy details display
Added show distant chat status
