Skip to content

fix(frame): do not lose a navigation or load state that lands while a wait subscribes - #3405

Closed
Simon Cropp (SimonCropp) wants to merge 1 commit into
microsoft:mainfrom
SimonCropp:fix-3364
Closed

Simon Cropp (SimonCropp) wants to merge 1 commit into
microsoft:mainfrom
SimonCropp:fix-3364

Conversation

@SimonCropp

Copy link
Copy Markdown
Contributor

Summary

  • Frame updates Url / _loadStates and takes the Navigated / LoadState handlers under one lock; WaitForLoadStateAsync, WaitForURLAsync and the post-navigation load-state wait check and subscribe under the same lock, so an event landing between check and subscribe is no longer lost.
  • WaitForURLAsync on an already-matching URL now goes through the navigation wait, which checks the URL where it subscribes (the URL predicate runs outside the lock).
  • Adds a regression test that forces a navigation to commit between the URL check and the subscription.

Fixes #3364
Also addresses #3399

… wait subscribes

Events arrive on the connection's thread while a wait checks the frame's URL or load states and then subscribes on
the caller's, so one landing in between was recorded but never heard, and the wait ran out its timeout. The frame now
updates its state and takes the handlers to raise under one lock, and the waits check and subscribe under it.

Fixes: microsoft#3364
@dgozman

Copy link
Copy Markdown
Collaborator

Closing in favor of #3453.

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.

[Bug]: WaitForURLAsync can lose the event it is waiting for — its check-then-subscribe races with the thread that delivers events

2 participants