@ethora/chat-component-rn 26.8.1 → 26.8.2

package/src/roomStore/roomsSlice.ts

@@ -2,6 +2,7 @@ import { createAsyncThunk, createSlice, PayloadAction, type Slice } from '@redux
 import type { WritableDraft } from 'immer';
 import { EditAction, HistoryPreloadState, IMessage, IRoom } from '../types/types';
 import { insertMessageWithDelimiter } from '../helpers/insertMessageWithDelimiter';
+import { msgSortableMs } from '../helpers/msgSortableMs';
 import type XmppClient from '../networking/xmppClient';
 
 // Per-room runtime message cap. Mirrors the persistence layer's
@@ -13,7 +14,7 @@ import type XmppClient from '../networking/xmppClient';
 // older history added via unshift/splice is exempt, so the user can
 // page backward arbitrarily far without instantly losing what they
 // just fetched. After cap eviction we drop from the head (oldest).
-const RUNTIME_MESSAGE_LIMIT = 100;
+export const RUNTIME_MESSAGE_LIMIT = 100;
 
 // Body strings the server uses for call signaling broadcasts (call-token,
 // call-state ringing/ended, etc). These should never reach the chat
@@ -142,7 +143,6 @@ function mergeHistoryIntoCache(
   const ex = stripCallSignals(existing);
   const fe = stripCallSignals(fetched);
 
-  const pending = ex.filter((m) => m?.pending);
   const realExisting = ex.filter(
     (m) => m && !m.pending && m.id !== 'delimiter-new'
   );
@@ -151,6 +151,29 @@ function mergeHistoryIntoCache(
   // Nothing usable came back → keep the cache exactly as it was.
   if (realFetched.length === 0) {return ex;}
 
+  // Optimistic sends are preserved across a history merge - EXCEPT the
+  // ones the fetched page proves the server already has. That happens
+  // whenever a send reached the server but its echo did not reach us
+  // before the process died: the optimistic bubble is restored from disk
+  // still `pending: true` (and, since bug #39, flagged failed at boot),
+  // while MAM hands back the very same message under its ARCHIVE id.
+  // Keying only on `id` never matched those two, so the room ended up
+  // showing the message twice - once for real and once as a bubble stuck
+  // on "sending…"/"Failed" that nothing could ever clear. The archived
+  // copy carries our original stanza id as `xmppId` (getDataFromXml), so
+  // match on that too and drop the local ghost.
+  const fetchedKeys = new Set<string>();
+  for (const m of realFetched) {
+    if (m?.id != null) {fetchedKeys.add(String(m.id));}
+    if ((m as any)?.xmppId) {fetchedKeys.add(String((m as any).xmppId));}
+  }
+  const pending = ex.filter(
+    (m) =>
+      m?.pending &&
+      !fetchedKeys.has(String(m.id)) &&
+      !(m.xmppId && fetchedKeys.has(String(m.xmppId)))
+  );
+
   const byMs = (a: IMessage, b: IMessage) =>
     msgSortableMs(a) - msgSortableMs(b);
   const capTail = (arr: IMessage[]) =>
@@ -214,6 +237,33 @@ export interface RoomMessagesState {
   // — see `applyPrivateStoreMarkers`. Re-fetched every init/reconnect,
   // so it is intentionally NOT persisted.
   privateStoreMarkers: Record<string, number>;
+  // The single source of truth for "read up to here, but the user
+  // hasn't reached the bottom yet" (`{ roomJID: boundaryMs }`).
+  // Set by MessageList (via ChatRoom's `onReadBoundaryChange`) the
+  // moment the user first scrolls away from the bottom, to the
+  // msgSortableMs of the newest message they'd actually seen. Every
+  // path that stamps a read marker for a room the user is leaving
+  // (ChatRoom unmount, xmppProvider's AppState background handler and
+  // `isVisible=false` handler, the live `advance()` effect, and
+  // `useChatRoomFocus`'s `leaveRoom`) must consult this instead of
+  // unconditionally stamping "the newest acked message" - otherwise
+  // leaving a room while scrolled up marks messages the user never
+  // reached as read (customer #42, a regression of #33 reintroduced by
+  // #38's server-timestamp marker). See `getReadMarkerTimestamp` in
+  // helpers/getServerReadTimestamp.ts.
+  //
+  // Cleared when the boundary no longer applies: the user scrolls back
+  // to the bottom, the visible room changes, or the room is truly left
+  // (ChatRoom unmounts, or a tab-navigator focus hook releases the
+  // room). NOT cleared merely because the app backgrounds or a host's
+  // `isVisible` flips false - MessageList typically stays mounted
+  // through those, so its own scroll-tracking ref (the only thing that
+  // could re-derive this value) is still intact and the boundary must
+  // stay in sync with it. Deliberately NOT persisted (this key isn't
+  // read by `persistence.ts`, which only ever picks `rooms` back out of
+  // this slice) - it's meaningless across a process restart, where
+  // MessageList always mounts fresh at the bottom.
+  readBoundaries: Record<string, number>;
 }
 
 const initialState: RoomMessagesState = {
@@ -230,6 +280,7 @@ const initialState: RoomMessagesState = {
   },
   pendingNotificationJid: null,
   privateStoreMarkers: {},
+  readBoundaries: {},
 };
 
 const isValidRoomJid = (jid: unknown): jid is string => {
@@ -317,6 +368,8 @@ const reducers = {
         : [];
       state.rooms[roomData.jid] = {
         ...roomData,
+        icon: roomData.icon !== undefined ? roomData.icon : existing?.icon,
+        roomBg: roomData.roomBg !== undefined ? roomData.roomBg : existing?.roomBg,
         messages:
           existingMessages.length > 0 ? existingMessages : incomingMessages,
         lastViewedTimestamp: lastViewed,
@@ -494,7 +547,7 @@ const reducers = {
           state.visibleRoomJID === roomJID
             ? null
             : lastViewedValue
-              ? new Date(lastViewedValue)
+              ? lastViewedValue
               : null;
 
         insertMessageWithDelimiter(roomMessages, message, lastViewedTimestamp);
@@ -512,6 +565,7 @@ const reducers = {
       state.rooms = {};
       state.visibleRoomJID = null;
       state.privateStoreMarkers = {};
+      state.readBoundaries = {};
       state.isUnreadSyncing = false;
     },
     setComposing(
@@ -578,7 +632,19 @@ const reducers = {
      *
      * Monotonic: a marker only ever moves a baseline FORWARD, so a stale
      * server value can't resurrect already-read messages and a more-recent
-     * local read (tab blur stamping Date.now()) always wins.
+     * local read (tab blur stamping the server read timestamp) always wins.
+     *
+     * Bug #38 self-heal: forward-only is correct for a SANE existing
+     * value, but a device whose clock was ahead may have already stamped
+     * a marker in the future (either persisted locally from a previous
+     * session, or fetched from the server before this fix existed). To
+     * "only ever move forward" from a corrupt future value is to never
+     * move at all - the room would stay stuck at `unreadMessages: 0`
+     * forever. When the room is loaded, detect a marker that sits well
+     * past the newest message we actually know it has and waive the
+     * forward-only check for that one comparison, so the incoming
+     * (already-clamped, see xmppClient.getChatsPrivateStoreRequestStanza)
+     * value can correct it even though it's numerically smaller.
      */
     applyPrivateStoreMarkers: (
       state: WritableDraft<RoomMessagesState>,
@@ -590,20 +656,72 @@ const reducers = {
       for (const jid of Object.keys(markers)) {
         const ts = Number(markers[jid]);
         if (!jid || !Number.isFinite(ts) || ts <= 0) {continue;}
+
+        const room = state.rooms[jid];
+        const newestKnownMs = room ? newestAckedMessageMs(room.messages) : 0;
+        // Mirrors isCorruptFutureReadMarker in helpers/getServerReadTimestamp.ts
+        // (duplicated to avoid a roomStore <-> helpers import cycle):
+        // BOTH signals are required. "Further ahead than the newest
+        // message this room has locally" happens all the time on a room
+        // whose history hasn't synced yet, and healing on that alone
+        // would drop a legitimate marker another device wrote after
+        // reading newer messages. A real read marker can never be ahead
+        // of real time, so that second signal is what distinguishes a
+        // stale cache from a wrong clock.
+        const nowMs = Date.now();
+        const looksCorrupt = (existing: number) =>
+          newestKnownMs > 0 &&
+          existing > newestKnownMs + FUTURE_MARKER_TOLERANCE_MS &&
+          existing > nowMs + FUTURE_MARKER_TOLERANCE_MS;
+
         // Remember the marker so rooms that load LATER (via addRoom)
         // inherit it even though they don't exist in the store yet.
-        if (ts > (state.privateStoreMarkers[jid] || 0)) {
+        const cachedMarker = state.privateStoreMarkers[jid] || 0;
+        if (ts > cachedMarker || looksCorrupt(cachedMarker)) {
           state.privateStoreMarkers[jid] = ts;
         }
         // Upgrade an already-loaded room's baseline + recompute its badge.
-        // Only ever forward, so a later local read isn't clobbered.
-        const room = state.rooms[jid];
-        if (room && ts > (room.lastViewedTimestamp || 0)) {
+        // Forward-only, unless the room's CURRENT baseline is itself the
+        // corrupt value being corrected.
+        if (room && (ts > (room.lastViewedTimestamp || 0) || looksCorrupt(room.lastViewedTimestamp || 0))) {
           room.lastViewedTimestamp = ts;
           room.unreadMessages = countNewerMessages(room.messages, ts);
         }
       }
     },
+    /**
+     * Set (or clear) the "read up to here, but not further" boundary for
+     * a room - see `readBoundaries` on `RoomMessagesState` for the full
+     * contract. `ts` is the msgSortableMs of the newest message the user
+     * actually reached before scrolling away from the bottom; `null`/`0`
+     * clears it (the user is at the bottom, or nothing was reached yet).
+     */
+    setReadBoundary: (
+      state: WritableDraft<RoomMessagesState>,
+      action: PayloadAction<{ jid: string; ts: number | null }>
+    ) => {
+      const { jid, ts } = action.payload;
+      if (!jid) {return;}
+      if (!state.readBoundaries) {state.readBoundaries = {};}
+      if (typeof ts === 'number' && Number.isFinite(ts) && ts > 0) {
+        state.readBoundaries[jid] = ts;
+      } else {
+        delete state.readBoundaries[jid];
+      }
+    },
+    /**
+     * Release a room's read boundary once it has been consumed by a
+     * genuine "leave" (ChatRoom unmount, or a tab-navigator focus hook
+     * switching to a different room) - see `readBoundaries` for why the
+     * background/`isVisible=false` paths deliberately do NOT call this.
+     */
+    clearReadBoundary: (
+      state: WritableDraft<RoomMessagesState>,
+      action: PayloadAction<{ jid: string }>
+    ) => {
+      const { jid } = action.payload;
+      if (jid && state.readBoundaries) {delete state.readBoundaries[jid];}
+    },
     setRoomRole: (
       state: WritableDraft<RoomMessagesState>,
       action: PayloadAction<{ chatJID: string; role: string }>
@@ -697,6 +815,7 @@ const reducers = {
       state.isLoading = false;
       state.isUnreadSyncing = false;
       state.privateStoreMarkers = {};
+      state.readBoundaries = {};
     },
     setActiveMessage: (
       state: WritableDraft<RoomMessagesState>,
@@ -818,27 +937,13 @@ export const roomsStore: Slice<RoomMessagesState, typeof reducers, 'roomMessages
   reducers,
 });
 
-// Count messages strictly newer than the given millisecond timestamp.
-// Uses `msg.id` (server-authoritative microsecond timestamp prefixed by
-// 13-digit millis — see helpers/dateComparison `getHighResolutionTimestamp`)
-// because `msg.date` can be derived client-side (createMessageFromXml
-// falls back to `Date.now()` for realtime stanzas without a `date`
-// attr), which makes the comparison drift vs what the server assigned.
-// Excludes the "delimiter-new" sentinel, pending sends, and the current
-// user's own messages (parity with unreadMiddleware's isOwnMessage
-// filter — without this, the reducer and the middleware disagree about
-// the count and we get a flicker as the badge gets written twice with
-// different values on every message).
-export const msgSortableMs = (msg: any): number => {
-  const id = String(msg?.id || '');
-  const m = /^(\d{13})/.exec(id);
-  if (m) {return Number(m[1]);}
-  if (msg?.date) {
-    const t = new Date(msg.date as any).getTime();
-    if (Number.isFinite(t)) {return t;}
-  }
-  return 0;
-};
+// Re-exported for backward compatibility - every existing call site
+// imports `msgSortableMs` from here. The implementation now lives in
+// helpers/msgSortableMs.ts (imported above), so insertMessageWithDelimiter.ts
+// (which this file itself imports) can use the SAME ordering source
+// without a roomStore <-> helpers import cycle. See that file for the
+// full rationale (server id vs. client `date`).
+export { msgSortableMs };
 
 const norm = (s: any): string => {
   if (s == null) {return '';}
@@ -870,6 +975,31 @@ const isOwn = (
   return false;
 };
 
+// Bug #38 tolerance: a stored read marker more than this far past the
+// newest message a room actually has is not "the user is a little
+// ahead" - it's a leftover from a device whose clock was wrong when it
+// stamped the marker. Kept in sync with (but duplicated from, to avoid
+// a roomStore ↔ helpers import cycle) FUTURE_READ_MARKER_TOLERANCE_MS
+// in helpers/getServerReadTimestamp.ts.
+const FUTURE_MARKER_TOLERANCE_MS = 5 * 60 * 1000;
+
+// Newest message in `messages` this room actually has proof the server
+// accepted - used only to sanity-check an already-stored read marker
+// against reality (see applyPrivateStoreMarkers's self-heal). Excludes
+// pending/optimistic sends via the `pending` flag alone: unlike
+// getServerReadTimestamp, this runs inside a reducer and can't reach
+// across to the roomHeapSlice slice, but `pending` already identifies
+// every optimistic send that matters for this comparison.
+const newestAckedMessageMs = (messages: IMessage[] | undefined): number => {
+  let newest = 0;
+  for (const m of messages || []) {
+    if (!m || m.id === 'delimiter-new' || m.pending) {continue;}
+    const ms = msgSortableMs(m);
+    if (ms > newest) {newest = ms;}
+  }
+  return newest;
+};
+
 const countNewerMessages = (
   messages: IMessage[],
   timestamp: number,
@@ -900,6 +1030,8 @@ export const {
   setUnreadSyncing,
   setLastViewedTimestamp,
   applyPrivateStoreMarkers,
+  setReadBoundary,
+  clearReadBoundary,
   setRoomNoMessages,
   setCurrentRoom,
   setVisibleRoom,

package/src/services/pushSubscriptionService.ts

@@ -81,7 +81,9 @@ export class PushSubscriptionService {
         this.subscribedRooms.add(roomJID);
         await this.saveSubscribedRoomsToStorage();
       }
-      console.log('Successfully Subscribed to room', roomJID);
+      if (!result) {
+        console.warn('[PushService] MucSub subscribe refused for', roomJID);
+      }
       return result;
     } catch (error) {
       console.error(`[PushService] Failed to subscribe to room ${roomJID}:`, error);
@@ -92,30 +94,33 @@ export class PushSubscriptionService {
   async subscribeToRooms(
     client: Client,
     roomJIDs: string[],
-    userNick?: string
+    userNick?: string,
+    concurrency = 8
   ): Promise<void> {
     let successful = 0;
     let failed = 0;
 
-    console.log('test roomJIDs', roomJIDs);
+    await this.loadSubscribedRoomsFromStorage();
+    const pending = roomJIDs.filter((jid) => !this.subscribedRooms.has(jid));
+    if (!pending.length) {
+      return;
+    }
 
-    for (const roomJID of roomJIDs) {
-      try {
-        const result = await this.subscribeToRoom(client, roomJID, userNick);
-        console.log('test roomJID-1', result);
-        if (result) {
+    for (let i = 0; i < pending.length; i += concurrency) {
+      const batch = pending.slice(i, i + concurrency);
+      const results = await Promise.allSettled(
+        batch.map((roomJID) => this.subscribeToRoom(client, roomJID, userNick))
+      );
+      for (const r of results) {
+        if (r.status === 'fulfilled' && r.value) {
           successful++;
         } else {
           failed++;
         }
-        await new Promise(resolve => setTimeout(resolve, 100));
-      } catch (error) {
-        failed++;
-        console.error(`Failed to subscribe to room ${roomJID}:`, error);
       }
     }
 
-    console.log(`Subscribed to ${successful} rooms, ${failed} failed`);
+    console.log(`[PushService] MucSub: ${successful} rooms subscribed, ${failed} failed`);
   }
 
   async reset(): Promise<void> {

package/src/types/types.ts

@@ -105,6 +105,7 @@ export interface User {
   ];
   appId: string;
   xmppPassword: string;
+  fileToken?: string;
 
   homeScreen?: string;
   registrationChannelType?: string;
@@ -150,6 +151,7 @@ export interface xmppSettingsInterface {
   disableLastRead?: boolean;
   xmppPingOnSendEnabled?: boolean;
   historyQoS?: HistoryQoSConfig;
+  keepAliveInBackground?: boolean;
 }
 
 export interface InAppNotificationConfig {
@@ -309,13 +311,16 @@ export interface TypographyConfig {
   };
   /** Attach (photo/document picker) bottom sheet. */
   attachSheet?: {
-    /** "Attach" header label. Default 13 / "600". */
+    /** "Photos & Videos" section header. Default 17 / "700". */
     title?: ChatTextStyle;
-    /** Row labels (Camera / Gallery / Document). Default 16 / "500". */
+    /** "View Library" link next to the section header. Default 15 / "500". */
+    viewLibrary?: ChatTextStyle;
+    /** Row labels ("Upload a File"). Default 16 / "500". */
     rowLabel?: ChatTextStyle;
-    /** Grey hint under each row. Default 12. */
+    /** @deprecated Rows no longer render a hint line. */
     rowHint?: ChatTextStyle;
-    /** Cancel button. Default 16 / "600". */
+    /** @deprecated The sheet has no Cancel button — it closes by tapping
+     * the backdrop, dragging it down, or the hardware back gesture. */
     cancelButton?: ChatTextStyle;
   };
 
@@ -393,6 +398,16 @@ export interface IConfig {
      * value takes effect.
      */
     height?: number;
+    /**
+     * Extend the header cards (room list + chat) under the status bar:
+     * each pads its top by the safe-area inset and paints it white, so
+     * the card and the status-bar band are one surface. Use this instead
+     * of wrapping `<Chat>` in a top-edge SafeAreaView: a host-side white
+     * band above the card shows a hairline seam where the card's
+     * shadow/elevation starts. Off by default (hosts that already pad the
+     * top keep their layout).
+     */
+    safeAreaTop?: boolean;
   };
   disableHeader?: boolean;
   disableMedia?: boolean;
@@ -421,7 +436,7 @@ export interface IConfig {
   hideMemberSendMessageAction?: boolean; // hides only "Message"
   hideMemberCopyIdAction?: boolean;      // hides only "Copy User Id"
   chatHeaderAdditional?: { enabled: boolean; element: any };
-  headerMenu?: () => void;
+  headerMenu?: (() => void) | boolean;
   headerChatMenu?: () => void;
   chatHeaderSettings?: {
     hide?: boolean;
@@ -453,11 +468,41 @@ export interface IConfig {
     loginFunction: () => Promise<User | null>;
   };
   defaultLogin?: boolean;
+  logout?: {
+    enabled: boolean;
+    label?: string;
+    confirm?:
+      | boolean
+      | {
+          title?: string;
+          message?: string;
+          confirmText?: string;
+          cancelText?: string;
+        };
+    onBeforeLogout?: () => Promise<boolean | void> | boolean | void;
+    onAfterLogout?: () => Promise<void> | void;
+  };
   refreshTokens?: {
     enabled: boolean;
+    /**
+     * Host-owned rotation. When set, the SDK calls this INSTEAD of
+     * `/users/login/refresh` — always, including during bootstrap — and
+     * never rotates the Ethora refresh token itself. Serialised through
+     * the same lock as the built-in path.
+     *
+     * Return `refreshToken` whenever the host's flow actually rotates an
+     * Ethora refresh token: the backend now treats a re-presented one as
+     * theft, so omitting it leaves a burned token in storage that ends
+     * the session the next time it is used. It stays optional because
+     * some hosts re-mint an access token from a different authority
+     * (SuperTokens, an owner-session endpoint) and hold no Ethora
+     * refresh token at all.
+     */
     refreshFunction?: () => Promise<{
       accessToken: string;
       refreshToken?: string;
+      fileToken?: string;
+      xmppPassword?: string;
     } | null>;
   };
 
@@ -540,6 +585,28 @@ export interface IConfig {
   // `disableKeyboardAvoidingView` is set. Needs on-device tuning of any
   // `keyboardVerticalOffset`.
   keyboardStickyInput?: boolean;
+  // Bottom padding applied to the input dock (the composer's outer
+  // wrapper), on both iOS and Android. When a number is provided (0 is
+  // allowed) it is used verbatim on both platforms, overriding the
+  // built-in default below.
+  //
+  // Left unset, the default is:
+  //  - 0 when `disableKeyboardAvoidingView` is set, since the host owns
+  //    layout entirely and typically already places the chat above its
+  //    own chrome (e.g. a tab bar) - the built-in padding would just add
+  //    an extra gap between the composer and that chrome.
+  //  - otherwise unchanged: the iOS safe-area bottom inset, or a fixed
+  //    12dp gap on Android (`ANDROID_INPUT_DOCK_GAP`).
+  // Customer-reported #44.
+  inputDockPaddingBottom?: number;
+  // The message list's FlatList uses keyboardDismissMode="interactive" by
+  // default, so a drag can be used to pull the keyboard closed. Because
+  // the list is `inverted`, an ordinary scroll gesture through history can
+  // also be read as a dismiss drag, closing the keyboard mid-scroll. Set
+  // this to keep the keyboard open regardless of how the list is scrolled
+  // — dismissal then only happens when the user deliberately closes it
+  // (tapping outside, back button, etc). Customer-reported #36.
+  keepKeyboardOpenOnScroll?: boolean;
 
   // ----- interactions / messages -----
   disableInteractions?: boolean;

package/src/version.ts

@@ -1,3 +1,3 @@
 // Generated by scripts/sync-version.mjs on `npm version`.
 // Edit package.json's version instead of this file.
-export const ETHORA_CHAT_COMPONENT_VERSION = '26.8.1';
+export const ETHORA_CHAT_COMPONENT_VERSION = '26.8.2';