Skip to content

fix(helpers): make timeline_view and transcribe run on Windows#81

Open
Pcecil21 wants to merge 1 commit into
browser-use:mainfrom
Pcecil21:fix/windows-fonts-and-console
Open

fix(helpers): make timeline_view and transcribe run on Windows#81
Pcecil21 wants to merge 1 commit into
browser-use:mainfrom
Pcecil21:fix/windows-fonts-and-console

Conversation

@Pcecil21

@Pcecil21 Pcecil21 commented Jun 20, 2026

Copy link
Copy Markdown

Motivation / Context

This completes the Windows-portability sweep started in #78 (cp1252 console + ffmpeg path) and #79 (subtitles-filter path escaping). Two CLI helpers were never touched by those fixes and still break on Windows.

What's fixed

helpers/timeline_view.py

  • FONT_CANDIDATES listed only macOS and Linux font paths. On Windows every candidate failed Path.exists(), so load_font fell through to PIL's default bitmap font (which ignores the requested size), rendering the filmstrip labels nearly illegibly. Added %WINDIR%-derived Consolas + Arial candidates (drive-correct, not hardcoded to C:).
  • Forced UTF-8 on stdout/stderr so a non-ASCII output path in the status print doesn't raise UnicodeEncodeError on a cp1252 console.

helpers/transcribe.py

  • Forced UTF-8 on stdout/stderr for the same reason — it prints the video filename, which crashes the helper on Windows when the name is non-ASCII (accents, emoji, CJK).

Tests

Adds tests/test_timeline_fonts.py (cross-platform): pins the candidate list, the %WINDIR%-derived font dir, that the original POSIX candidates are preserved, and that load_font never raises. Passes on Windows and Linux.

Risk / caveats

No behavior change on macOS/Linux — the new font paths simply never match there, and the UTF-8 reconfigure is a no-op when the stream is already UTF-8. The transcribe.py JSON write was already ASCII-safe (json.dumps defaults ensure_ascii=True) and was intentionally left untouched.

🤖 Generated with Claude Code


Summary by cubic

Fixes Windows support for helpers by adding %WINDIR%-derived font candidates (Consolas/Arial) in timeline_view.py and forcing UTF-8 on stdout/stderr in both helpers to avoid cp1252 UnicodeEncodeError. Adds a cross-platform test to pin font candidates and ensure load_font is resilient; no behavior change on macOS/Linux.

Written for commit 4957119. Summary will update on new commits.

Review in cubic

Completes the Windows-portability sweep across the CLI helpers. Two helpers
were never touched by the earlier fixes (cp1252 console + ffmpeg paths):

- timeline_view.py: FONT_CANDIDATES listed only macOS/Linux font paths, so on
  Windows every candidate missed and load_font fell to PIL's default bitmap
  font (which ignores the requested size), rendering filmstrip labels nearly
  illegibly. Add %WINDIR%-derived Consolas + Arial candidates (drive-correct,
  not hardcoded C:). Also force UTF-8 on stdout/stderr so a non-ASCII output
  path in the status print doesn't raise UnicodeEncodeError on a cp1252 console.

- transcribe.py: force UTF-8 on stdout/stderr for the same reason — it prints
  the video filename, which crashes the helper on Windows if non-ASCII.

Adds tests/test_timeline_fonts.py (cross-platform; pins the candidate list,
the %WINDIR%-derived font dir, and that load_font never raises). All 7 tests
pass on Windows and Linux. No behavior change on macOS/Linux.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMuYbKwjCCvuaB6i75DDsF

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 3 files

Re-trigger cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant