Skip to content

test(input): add cross-engine CJK IME, touch, and mobile editing assurance #376

Description

@seonghobae

Buyer-visible product gap

Inkspan bundles offline Korean, Japanese, Simplified/Traditional Chinese, Vietnamese, and Latin typography, but bundled fonts alone do not establish reliable multilingual input or mobile support. Enterprise and public-sector buyers need an explicit, evidence-backed browser/device/input-method support matrix rather than a general multilingual claim inferred from typography.

Protected main is the only shipped-source authority. Draft #201 is the existing standalone-editor source owner for composition/read-only/controlled-value semantics; stacked Draft #380 is the existing browser-harness/spec/config owner for multilingual input assurance. Their mutable heads, bases, checks and lifecycle state must be refetched live before action rather than copied into this issue.

Current ownership and already-covered active-PR scope

Do not create competing writers for these boundaries:

Those active-PR behaviors are not protected-main shipped truth until their dependency-ordered stack integrates under then-live governance.

Standards basis

These references define standards context; they are not evidence that a specific Inkspan source generation passes the requirement.

Remaining product contract

Maintain an accepted ADR and public support statement that explicitly covers:

  • composition lifecycle ownership and observable callback behavior;
  • treatment of intermediate composition text in onChange, serialization, autosave candidates and collaboration updates;
  • controlled-value updates during composition;
  • undo/redo grouping for committed composition text;
  • remote collaboration updates near a local composition range;
  • focus/selection behavior when toolbar controls or dialogs are activated;
  • touch/pen toolbar operation, selection, scrolling and image/table controls;
  • supported desktop/mobile browser and physical-device/input-method profiles;
  • fully tested, periodically tested, emulated-only, known-limited and unsupported classifications.

Preserve browser/TipTap/ProseMirror composition semantics where they are authoritative rather than introducing an incompatible custom text model.

Remaining executable assurance

Real input-method semantics

Use committed synthetic phrases and deterministic expected documents for at least Korean 2-set Hangul, Japanese kana/kanji conversion, Simplified/Traditional Chinese phonetic candidate selection, Vietnamese diacritics, mixed Latin text, emoji, combining marks, variation selectors and adjacent grapheme clusters.

Where browser automation cannot faithfully drive the OS candidate UI, do not fabricate IME proof from synthetic DOM events. Keep synthetic composition coverage as component/browser contract evidence and add a documented authorized physical-device or remote-device lane for the support claim itself.

Exercise supported composition in paragraphs, headings, list items, table cells, links, marks, code blocks where supported and around inline images.

Transaction and lifecycle interactions

Cover at minimum:

  • composition start/update/end without loss, duplication or reordering;
  • controlled value refresh during and after composition;
  • autosave coalescing plus strong-revision capture without pairing an intermediate document with the wrong validator;
  • undo/redo before, during and after committed composition;
  • toolbar/dialog interaction while composing;
  • host read-only transition and unmount/remount;
  • remote Yjs insertion/deletion near the local composition range under host-owned provider authority;
  • paste/drop and safe-link/image policies adjacent to composition;
  • SSR hydration and native-form serialization;
  • stale revision restore/conflict behavior.

No test may treat DOM presence of intermediate composition text as evidence of durable save, collaboration acknowledgement, authorization or persistence success.

Browser, mobile and accessibility assurance

  • Preserve exact packed-package desktop Chromium/Firefox/WebKit evidence for applicable buyer journeys.
  • Add accepted mobile viewport/touch/pointer journeys for Chromium and WebKit without representing emulation as physical-device IME proof.
  • Before claiming iOS Safari or Android Chrome support, retain periodic authorized real-device evidence with OS/browser/input-method/device-or-runner/package hash/fixture hash/exact source identity.
  • Keep production text, user dictionaries, tenant content, credentials and private keyboard telemetry out of artifacts.
  • Verify toolbar/dialog/table/image/review controls remain operable without hover and under narrow viewport, zoom/reflow and virtual-keyboard conditions.
  • Meet WCAG 2.2 SC 2.5.8 target-size/spacing or retain exact exception evidence; where Inkspan owns drag behavior, meet SC 2.5.7 or document the applicable exception.
  • Keyboard, touch, switch and screen-reader interaction must not be mutually exclusive.

Acceptance criteria

Close only after the resulting exact protected generation proves all applicable requirements:

  • a published support matrix distinguishes fully tested, periodically tested, emulated-only, known-limited and unsupported profiles;
  • committed multilingual fixtures reach the expected canonical document without lost, duplicated, reordered or prematurely persisted text;
  • controlled-value composition behavior from the fix(data-integrity): keep controlled value sync atomic #201 owner is integrated and revalidated;
  • browser discovery and multilingual/touch journeys from the test(input): add multilingual browser input baseline #380 owner are integrated and revalidated on the exact packed artifact;
  • composition plus autosave/revision evidence cannot associate an intermediate/stale document with the wrong strong validator;
  • supported collaboration-near-composition behavior is deterministic or fails visibly without silent re-anchoring;
  • undo/redo behavior for supported language/input paths is documented and tested;
  • mobile/touch journeys prove target-size/spacing, focus, orientation, zoom/reflow and no-hover behavior;
  • physical iOS/Android support claims are backed by authorized real-device evidence rather than Playwright emulation alone;
  • applicable exact coverage, public API documentation, package, browser, accessibility, security, SAST and governance gates pass on the exact protected lineage.

Ownership / lifecycle boundary

Priority: P1 product correctness and accessibility. Work may proceed while stable-release acceptance #118 is open, but README/support claims must not broaden beyond exact protected evidence.

Before any #201/#380 lifecycle action or this issue's closure, refetch protected main, exact parent/child heads and live bases, ancestry/mergeability, changed paths/active writers, live rules/permissions, formal reviews/threads, and every applicable repository/central workflow job with actual checkout/source identity. Pending, queued, skipped-required, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, wrong-checkout, synthetic-source-only, undiscovered-test or emulation-only evidence is non-passing for a claim that requires more.

Do not self-approve, transfer parent/predecessor evidence, weaken gates, create a competing production/browser writer, force-push/destructively rebase, invent physical-device evidence, or represent active-PR behavior as protected-main shipped truth.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: accessibilityAccessibility and assistive-technology supportarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dependenciesDependency or lockfile maintenancepriority: highstatus: triagedOpen issue has an organization taxonomy assignmenttype: testTest coverage, fixtures, fuzzing, or validation

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions