Ty_Tech/SlabUploader
6
0
Fork 0
Code Issues 15 Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: Add explicit browser compatibility floor and graceful fallback for unsupported clients #4

New Issue
Closed
opened 2026-09-01 20:38:20 +00:00 by Ty · 2 comments
Ty commented 2026-09-01 20:38:20 +00:00
Owner
Copy Link
Copy Source

Summary

The refactor docs do not define browser compatibility requirements or any gating for older, incompatible browsers. Phase 6 acceptance only says "E2E capture→publish on iPhone and Android browsers works," which is too vague to be testable.

This issue tracks making that promise explicit without turning it into a POC blocker.

Scope

Three items, kept small:

  1. Minimum version floor — document the oldest iOS Safari and Android Chrome the app will support, written into the tech spec as a real constraint rather than an assumption.

  2. Graceful fallback — when an unsupported browser loads the app, show a clear message with a link to update, instead of a broken mask or silent failure. No polyfill work; a hard stop is fine.

  3. Load-bearing API inventory — a short note listing the APIs the client depends on (OffscreenCanvas, the crop pipeline, File System Access if used, etc.) so future contributors know what not to break.

Non-goals

  • Not a POC gate. The existing Phase 6 acceptance is sufficient for V1.
  • No polyfill strategy or broad browser-matrix testing.
  • No changes to the hybrid architecture or server stack.

Acceptance criteria

  • Tech spec names a minimum iOS Safari and Android Chrome version.
  • Unsupported-browser fallback behavior is specified (message + update link).
  • Load-bearing client APIs are listed in the docs.
  • Issue is associated with the docs/refactor-v2 branch.
## Summary The refactor docs do not define browser compatibility requirements or any gating for older, incompatible browsers. Phase 6 acceptance only says "E2E capture→publish on iPhone and Android browsers works," which is too vague to be testable. This issue tracks making that promise explicit without turning it into a POC blocker. ## Scope Three items, kept small: 1. **Minimum version floor** — document the oldest iOS Safari and Android Chrome the app will support, written into the tech spec as a real constraint rather than an assumption. 2. **Graceful fallback** — when an unsupported browser loads the app, show a clear message with a link to update, instead of a broken mask or silent failure. No polyfill work; a hard stop is fine. 3. **Load-bearing API inventory** — a short note listing the APIs the client depends on (OffscreenCanvas, the crop pipeline, File System Access if used, etc.) so future contributors know what not to break. ## Non-goals - Not a POC gate. The existing Phase 6 acceptance is sufficient for V1. - No polyfill strategy or broad browser-matrix testing. - No changes to the hybrid architecture or server stack. ## Acceptance criteria - [ ] Tech spec names a minimum iOS Safari and Android Chrome version. - [ ] Unsupported-browser fallback behavior is specified (message + update link). - [ ] Load-bearing client APIs are listed in the docs. - [ ] Issue is associated with the docs/refactor-v2 branch.
Ty added this to the POC milestone 2026-09-01 23:49:50 +00:00
Ty commented 2026-09-03 02:37:48 +00:00
Author
Owner
Copy Link
Copy Source

Doc changes applied:

  • TECH-SPEC §0 added: browser minimums (iOS Safari 17, Android Chrome 110), load-bearing API inventory, hard stop for unsupported browsers.
  • UX.md added "Browser compatibility" section with fallback message and update link.

Test cases needed once implementation exists:

  1. Hard stop — loading the app in a browser below the minimum version shows the compatibility message with an update link, not a broken mask or blank screen.
  2. API detection — the app does not crash or silently fail when load-bearing APIs are available; it functions normally.
Doc changes applied: - TECH-SPEC §0 added: browser minimums (iOS Safari 17, Android Chrome 110), load-bearing API inventory, hard stop for unsupported browsers. - UX.md added "Browser compatibility" section with fallback message and update link. Test cases needed once implementation exists: 1. **Hard stop** — loading the app in a browser below the minimum version shows the compatibility message with an update link, not a broken mask or blank screen. 2. **API detection** — the app does not crash or silently fail when load-bearing APIs are available; it functions normally.
grokbot_ty commented 2026-09-24 18:54:52 +00:00
Owner
Copy Link
Copy Source

Verified in main @ 0c00d25: REQUIREMENTS.md:18 CAPTURE-10 shipped (iOS Safari, Android Chrome, desktop Chrome/Edge/Firefox, hard stop, no polyfills). frontend/src/browser.ts implements the check.

Verified in main @ 0c00d25: REQUIREMENTS.md:18 CAPTURE-10 shipped (iOS Safari, Android Chrome, desktop Chrome/Edge/Firefox, hard stop, no polyfills). frontend/src/browser.ts implements the check.
Sign in to join this conversation.
docs/refactor-v2
Branches Tags
Labels
Clear labels
blocking
Blocks POC acceptance; must be resolved before merge
 docs
Documentation change required
 gate-b
Gate B sprint issue
 gate-c
Gate C sprint issue
 gc-seq-01
Serial order 01/6 in Gate C sprint
 gc-seq-02
Serial order 02/6 in Gate C sprint
 gc-seq-03
Serial order 03/6 in Gate C sprint
 gc-seq-04
Serial order 04/6 in Gate C sprint
 gc-seq-05
Serial order 05/6 in Gate C sprint
 gc-seq-06
Serial order 06/6 in Gate C sprint
 poc
POC post-Gate-C issue
 poc-seq-01
Serial order 01 in POC sprint
 poc-seq-02
Serial order 02 in POC sprint
 poc-seq-03
Serial order 03 in POC sprint
 poc-seq-04
Serial order 04 in POC sprint
 poc-seq-05
Serial order 05 in POC sprint
 poc-seq-06
Serial order 06 in POC sprint
 poc-seq-07
Serial order 07 in POC sprint
 poc-seq-08
Serial order 08 in POC sprint
 poc-seq-09
Serial order 09 in POC sprint
 poc-seq-10
Serial order 10 in POC sprint
 poc-seq-11
Serial order 11 in POC sprint
 poc-seq-12
Serial order 12 in POC sprint
 poc-seq-13
Serial order 13 in POC sprint
 poc-seq-14
Serial order 14 in POC sprint
 poc-seq-15
Serial order 15 in POC sprint
 poc-seq-16
Serial order 16 in POC sprint
 poc-seq-17
Serial order 17 in POC sprint
 poc-seq-18
Serial order 18 in POC sprint
 poc-seq-19
Serial order 19 in POC sprint
 poc-seq-20
Serial order 20 in POC sprint
 post-launch
Deferred to post-launch / V1.5+
 seq-01
Serial order 1/10 in Gate B sprint
 seq-02
Serial order 2/10 in Gate B sprint
 seq-03
Serial order 3/10 in Gate B sprint
 seq-04
Serial order 4/10 in Gate B sprint
 seq-05
Serial order 5/10 in Gate B sprint
 seq-06
Serial order 6/10 in Gate B sprint
 seq-07
Serial order 7/10 in Gate B sprint
 seq-08
Serial order 8/10 in Gate B sprint
 seq-09
Serial order 9/10 in Gate B sprint
 seq-10
Serial order 10/10 in Gate B sprint
No Label
Milestone
No items
No Milestone POC
Projects
Clear projects
No project
Assignees
Clear assignees
HA_Architect HA_Researcher Ty grokbot_ty grokbuild_ty tonyjbala (Tony Balascio)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Ty_Tech/SlabUploader#4
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?