Skip to content

fix(navigation): preserve readiness across cancelled redirects - #280

Merged
iuyo5678 merged 1 commit into
fix/background-tab-executionfrom
fix/preserve-pending-navigation-progress
Sep 18, 2026
Merged

iuyo5678 merged 1 commit into
fix/background-tab-executionfrom
fix/preserve-pending-navigation-progress

Conversation

@iuyo5678

Copy link
Copy Markdown
Collaborator

Fix the false navigation timeout in #249 when a page has already reached the requested lifecycle phase but a successor navigation is still pending.

A reproducible case is a load handler that starts a navigation to an endpoint returning HTTP 204 after 1.4 seconds, while the original document starts a long-running fetch. Chrome emits the original document's load, then networkAlmostIdle and firstMeaningfulPaint, before cancelling the successor request. Previously those later events overwrote the buffered load. With no subsequent networkIdle, the handler timed out even though the original document had loaded and remained current.

Preserve the buffered event once it satisfies this wait's target. A successor commit still clears the buffer, and cancellation still has to pass the existing document checks. The production change is confined to this buffering condition in navigation.ts.

The tests cover preservation of DOMContentLoaded, load, and networkIdle, waiting while the successor remains pending, and rejection of predecessor readiness after a successor commits. They also check that DOMContentLoaded cannot satisfy load, and load cannot satisfy networkidle in the cancellation path.

Validation:

  • Confirmed all three new readiness-preservation cases fail with timeouts on the unmodified base, then pass with this fix.
  • Navigation and navigation-recovery tests: 80 passed.
  • pnpm ext:test: 1808 passed, 99 skipped.
  • pnpm lint: passed, including 240 plugin tests.
  • pnpm --filter @browser-skill/extension compile: passed.
  • pnpm ext:build: passed.
  • Local Chrome 153.0.8010.50, using the actual navigation handler and real CDP events in an isolated browser: all six HTTP 204 + long-running fetch cases returned load after about 1.4 seconds, including the case using the default 30-second timeout. A real successor-commit control waited for the successor's own load. This verifies the handler/browser integration, not the full CLI and extension transport chain.

This PR targets fix/background-tab-execution so the fix can be incorporated into #249 before its final merge.

@iuyo5678
iuyo5678 merged commit 5ef23e7 into fix/background-tab-execution Sep 18, 2026
6 checks passed
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.

2 participants