Skip to content

E2E Journey Matrix

This matrix is the canonical cross-browser journey map for Skeeditor extension E2E.

Purpose

  • Enumerate all critical user journeys.
  • Define user-visible assertions for each journey.
  • Capture browser-specific execution deltas.
  • Provide journey IDs for traceable parity and CI policy.

Journey matrix

Journey IDJourneyPrimary user-visible assertionsChrome pathFirefox pathBrowser deltas / notes
J-001Extension popup bootstrapPopup loads, heading visible, sign-in CTA visible when signed outPlaywright Chromiumweb-ext Firefox runExtension loading mechanism differs; assertions remain identical
J-002OAuth sign-in flow handoffSign-in triggers auth tab/open flow and authenticated UI appears after callbackPlaywright Chromium + mocked callback where neededweb-ext + Firefox callback pathCallback interception differs by browser runtime behavior
J-003Reauthorize expired sessionReauthorize action available and session restored to authenticated statePlaywright Chromiumweb-ext Firefox runToken refresh and callback timing may differ
J-004Sign out (all sessions)Signed-in UI transitions to signed-out UI and edit controls disappear after refreshPlaywright Chromiumweb-ext Firefox runStorage/session lifecycle differs for temporary add-ons
J-005Multi-account list and switchAccounts list visible, active indicator moves to selected accountPlaywright Chromiumweb-ext Firefox runNone (shared component behavior)
J-006Sign out single accountRemoved account disappears from list while others remainPlaywright Chromiumweb-ext Firefox runNone (shared component behavior)
J-007Content-script initializationPage gets initialization marker and own post processing completesPlaywright Chromium (waitForContentScriptReady)web-ext Firefox runStartup timings differ; use state marker not sleeps
J-008Own-post edit button visibilityEdit button appears on own post only, absent on othersPlaywright Chromiumweb-ext Firefox runDOM rendering timing varies; use role/locator + readiness helpers
J-009Unauthenticated visibility rulesNo edit controls shown when no active sessionPlaywright Chromiumweb-ext Firefox runTemporary install/session semantics in Firefox can persist unexpectedly
J-010Edit modal load readinessModal opens with loading transition complete and textarea editablePlaywright Chromium (waitForEditModalReady)web-ext Firefox runModal attachment timing can vary
J-011Save strategy: edit in placeSave succeeds and payload preserves original createdAtPlaywright Chromium (capture PUT body)web-ext Firefox run with network inspection harnessRequest inspection mechanism differs
J-012Save strategy: recreate recordSave succeeds via applyWrites delete+create and fresh createdAtPlaywright Chromium (capture applyWrites body)web-ext Firefox run with network inspection harnessRequest inspection mechanism differs
J-013Conflict handlingConflict save shows explicit retry/reload warning messagePlaywright Chromiumweb-ext Firefox runSame UX expectation; transport setup differs
J-014Edit time limit enforcementOlder posts become non-editable and user sees limit messagePlaywright Chromiumweb-ext Firefox runClock/timing setup may differ
J-015Options settings persistenceSettings save success feedback and persisted values reload correctlyPlaywright Chromiumweb-ext Firefox runNone (shared settings component)
J-016Labeler prompt display/dismissLabeler prompt appears when pending, open/dismiss behavior updates UIPlaywright Chromiumweb-ext Firefox runNone (popup component behavior)
J-017Edited/archived interceptionEdited/archived interactions show expected history/original-text behaviorPlaywright Chromiumweb-ext Firefox runDialog injection timing may differ
J-018Devnet real-network saveEdit persists to live devnet PDS and read-back confirms updateChromium devnet PlaywrightFirefox devnet web-ext pathTooling constraints differ; same read-back expectation
J-019Devnet real-network conflictExternal mutation causes conflict warning on local saveChromium devnet PlaywrightFirefox devnet web-ext pathSame outcome, different harness plumbing

Parity acceptance criteria

For a journey ID to be considered parity-complete:

  1. The same journey ID is implemented in both Chrome and Firefox paths.
  2. Both implementations assert user-visible outcome(s) first.
  3. Browser-specific assertions are additive and do not replace core outcome checks.
  4. Each implementation runs in CI on its respective required job.
  5. Any temporary exception must be documented as an explicit waiver with reason and expiry.

Browser-specific constraints tracked in this phase

  • Firefox automated extension execution in this cycle is web-ext-first.
  • Playwright Firefox extension loading remains non-primary due upstream limitations.
  • Chromium uses persistent context extension load with readiness helpers and route-based fixtures.

Mapping to current suites

  • Chromium local: test/e2e/chrome.spec.ts
  • Chromium devnet: test/e2e/chrome-devnet.spec.ts
  • Firefox local scaffold: test/e2e/firefox.spec.ts
  • Firefox devnet scaffold: test/e2e/firefox-devnet.spec.ts

Phase 2 and Phase 3 implement full parity against this matrix; Phase 4 enforces it in CI.

Privacy Policy · Released under the MIT License.