The control server answered a line that wasn't JSON with an error and kept
reading, so an HTTP request to the port (for example a web page's fetch to
127.0.0.1) could carry a command such as file.saveAs in its body. It now
replies once and closes the connection on the first bad line; HTTP request
lines never parse, so nothing after them runs.
Ctrl/Cmd+click on a hyperlink passed any URL to the system. It now follows
only http, https and mailto links, and shows a status message otherwise, so
a document can't launch file: paths or custom-scheme handlers.
Tests cover JSON requests, closing on bad JSON, an HTTP POST carrying a
command, and the link allow-list. The control protocol docs note the
closing behaviour.
Co-authored-by: Dmitrii Khlapov <19991457+dkhlapov@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Desktop: write log records to standard error and a rotating log file
The desktop app installed no logger, so every log::warn!/log::error! in
the workspace was discarded: an unreadable part of a .docx, a picture or
font a PDF export had to leave out, a PNG that would not encode. A launch
from a desktop menu has no terminal either, and a panic's message went to
that missing terminal, so there was nothing to attach to a bug report.
apps/wordcraft/src/logging.rs (no new dependency):
- standard error plus logs/wordcraft.log next to the preferences
(~/.config/wordcraft/logs, or under $XDG_CONFIG_HOME); each launch
rotates the previous log to wordcraft.1.log and .2.log, so the log of
a run that crashed survives the next start; the file is capped at 16 MiB
- records logged before the settings directory is known are buffered
(bounded) and written once the file is attached
- default levels: info for wordcraft*, warn for everything else;
RUST_LOG replaces them with env_logger-style directives
- never panics: an unusable directory or a failed write leaves standard
error as the only sink
- runs with WORDCRAFT_NO_PREFS (agents' test runs) log to standard error
only, so they don't rotate away the user's own logs
- a panic hook reports every panic, also those Session::run's guard
recovers from, through the logger; text the message quotes between
backticks (std quotes the string it failed to slice, which can be the
user's writing) is left out
The logger is installed first in main, before the panic hook, and the
file is opened after argument parsing (--version leaves no file). The
control server's and file-open messages go through the logger and drop
their "wordcraft: " prefix, which the record's target now shows.
Documented in README.md (Logs).
* Desktop: no eprintln! on the log and panic paths
eprintln! panics when standard error is a broken pipe (a GUI launch on
Windows), and a panic inside the panic hook aborts. The "no log file"
message goes through log::warn! (standard error only by then); the panic
hook's fallback writes to standard error with write_fmt and ignores the
error. Same fix as storytold/vectorcraft#465.
---------
Co-authored-by: Brandon Thomas <shared2@storyteller.ai>
eframe's default wgpu instance enables PRIMARY | GL on Windows. Creating
the OpenGL backend can crash inside AMD's atio6axx.dll before the window
appears, so the app exits silently at launch. When WGPU_BACKEND is not
set, the Windows instance now enables only DirectX 12; an explicit
WGPU_BACKEND is still honoured. macOS, Linux and web are unchanged.
Same fix as storytold/designcraft#168 and storytold/filmcraft#179.
Claude-Session: https://claude.ai/code/session_01LyVbT6Vv4BwWZ4hY8973qD
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
cyfung1031