Prevent the inner terminal scrollable from accepting user scrolling in the alternate buffer, so xterm's existing outer handler receives trackpad gestures after main-screen history.
Keep wheel encoding and drag reporting unchanged. Cover trackpad forwarding, subsequent drag coordinates, arrow fallback, and return to local scrollback.
hbb_common 7dc56d6..d9895ff, one commit: tokio-tungstenite and tungstenite
up from 0.26 to rustdesk-org's rustdesk-patches-0.29 branches. The
tungstenite fork grows the read buffer a read_buffer_size chunk at a time
as bytes arrive, where upstream reserved the whole length a frame header
declared. It is pinned here at the workspace root, the one place cargo
reads [patch], so hbb_common's copy and tokio-tungstenite's resolve to
the same one. The lockfile moves only those two crates and drops utf-8,
which 0.29 no longer pulls.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
Carries `Stream::set_max_packet_length` to all three transports, so a connection
can hold its peer to a small message until it has authenticated: TCP had the knob,
WebRTC's reassembly ceiling becomes a per-stream bound, and WebSocket reaches
tungstenite's config through a fork of v0.26.2 that exposes `set_config`, which
upstream still does not at 0.30.0.
Nothing calls it yet, so this changes no behaviour; the hook lands separately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
The hbb_common bump before this one calls SettingEngine::set_ice_max_binding_requests(),
which the 0.13.0 release on crates.io does not have: only webrtc-util and webrtc-sctp
were patched to the fork, so the webrtc crate itself still came from the registry and
the build stopped at that call.
The three patches now point at the same fork revision, one commit past the one they
were on, which adds the setter. The webrtc crate depends on its siblings by path, so
patching it moves the rest of that workspace to the fork as well; the fork is upstream
v0.13.0 with changes to sctp and to this setter only, so those crates carry the same
code they did from the registry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
The row was added for the web client, which has no session tab to name
the transport on, but nothing gated it: a desktop session over WebRTC
showed it too, duplicating the tab tooltip's "(WebRTC)". The getter now
answers only on the web, as its own comment intended.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QcJZZeJ3Nqb2MHxXuUadkb
dash_chat_2, window_manager and desktop_multi_window named only a url, so
the lock recorded `ref: HEAD` for them. That holds while the lock is used
verbatim, but any re-resolution -- an unrelated pubspec.yaml edit, a lock
conflict resolved by regenerating -- re-reads HEAD and silently moves the
plugin to whatever the fork's tip is that day. All three forks are ours and
get pushed to, which is how window_manager and desktop_multi_window drifted
across five lock bumps since July with no pubspec.yaml change to show for it.
Each ref is the resolved-ref already in the lock, and all three still match
their fork's HEAD, so nothing resolves differently today.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
`set_stream_offset` indexed `self.files` directly. Its only guard is the
`self.file_num() == r.file_num` check in `confirm()`, and `file_num` counts up
past every file, so it equals `files.len()` once the job is done -- read_frame
at :849 treats exactly that value as "job done". A peer that then sends
`send_confirm` with the matching file_num and a non-zero OffsetBlk gets through
the equality check and off the end of the slice.
Every other site indexing `files` in this file already bounds-checks; this was
the one that did not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
Sending without a congestion window, a T3-rtx resent everything in flight, and
on a 5 Mbps link with 300-500ms stalls that spiralled: seconds of latency and
several times the bytes. The fork now resends everything outstanding on a
timeout only when it packs into four packets; otherwise it resends one packet
and withholds the rest until the SACKs settle them (RFC 4960 6.3.3 E3, F-RTO):
an original acked takes the marks off, a first transmission made after the
timeout acked with the rest still missing sends them, and with nothing else to
tell, a probe acked no sooner than the least RTT after it went out draws the
next probe, two of them settling the rest as lost. A restarted RTO is counted
from the latest send as QUIC does, backs off from the full RTO, and floors at
KCP's 30ms with srtt + 25ms at the least. Lost tails of up to four packets and
sparse small messages under loss now recover at KCP's pace where they trailed
it by a frame; a stall no longer resends the backlog behind itself.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns
The nightly armv7 sciter build aborts while compiling the final `rustdesk`
binary:
fatal runtime error: Rust cannot catch foreign exceptions
error: could not compile `rustdesk` (bin "rustdesk") (signal: 6, SIGABRT)
armv7 is the only 32-bit target in this job that links the whole binary, and
`[profile.release]` uses fat LTO with codegen-units = 1, so LLVM merges every
module into a single unit and runs past the ~3GB address space a 32-bit
process gets. The allocation failure surfaces as a C++ bad_alloc unwinding
into rustc's Rust frames, which is what that "foreign exceptions" abort is.
The x86_64 sciter build uses the same settings and passes, as do aarch64 and
every other 64-bit job in the same run, so this is specific to the 32-bit
address space rather than to the source change itself.
It started failing once the crate graph grew (hbb_common is pulled with the
`webrtc` feature unconditionally), which pushed an already marginal target
over the limit.
Use thin LTO with more codegen units for armv7 only. Peak memory stays
bounded while cross-crate inlining is kept, and 64-bit targets are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lq6xFoeEmjcuKwRx1GfdQ2
The root workspace lists libs/hbb_common as a member, so without the
submodule cargo cannot load the workspace and `cargo update` exits 101.
The job has failed on every scheduled run since it was added.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gecc6fgEeSxs6VRiQmAeof
The give-up log added in the white-window follow-ups declared a local
named message inside MessageHandler, shadowing its UINT message
parameter. MSVC C4457 plus /WX failed both Windows nightly jobs.
Point the lock at rustdesk_desktop_multi_window#35 which renames it.
https://github.com/rustdesk/rustdesk/actions/runs/30512756157
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
