[P1] Audit: External-request tools need stronger offline and failure states

[baixiangcpp]

Imported from the byteflow.tools deep audit on 2026-06-22.

Problem: external-request tools are labeled, but their offline and failure states should be more explicit. Users need to know when a failure is due to invalid input, remote asset unavailability, CORS/network issues, or intentional offline mode.

Affected tools:

• YouTube Thumbnail Grabber
• Vimeo Thumbnail Grabber
• Instagram Photo Downloader
• Any future external-request tool

Reproduction steps:

1. Open each external-request tool.
2. Try empty input, invalid URL, valid-looking but unreachable URL, and offline mode.
3. Click preview/download/copy actions.
4. Observe message clarity and next-step guidance.

Expected behavior: each failure mode should have a distinct, actionable message and should restate the external-request boundary.

Actual behavior: failure messaging is present but not consistently detailed across external-request tools.

Impact: users may think the tool is broken or may not understand when external network access is required.

Proposed fix:

• Standardize external-request status states: idle, invalid input, ready, requesting, success, unreachable, blocked, offline, permission/rights warning.
• Add per-tool retry and reset actions.
• Add external domain details near action buttons.
• Ensure offline mode disables preview/download with explanation.
• Add tests for network failure and offline behavior.

Acceptance criteria:

• Empty, invalid, unreachable, and offline states are distinct.
• No external request occurs before explicit action.
• Offline mode is clearly explained.
• User receives a next step for every failure state.
• External-request tools share a consistent status component.

[baixiangcpp]

Closed as completed by the canonical BF audit backlog work. This older non-BF audit issue duplicates work now merged through PRs #209-#219, with the BF issues closed and guard/test coverage in place. The remaining non-duplicate follow-up is #7, which stays open because the upstream Next/PostCSS advisory is not fixed yet.

[baixiangcpp]

Reopening after acceptance review on 2026-06-24. The merged work adds external-request confirmation, destination disclosure, offline guards, and tests for representative media tools, but this older audit issue is not fully satisfied: the tools still do not share a full external-request status component covering idle, invalid input, requesting, success, unreachable, blocked, offline, and retry/reset guidance, and test coverage does not distinguish every required failure mode. Keep this open until empty, invalid, unreachable/blocked, and offline states are distinct and actionable across the external-request media tools.