Repository navigation
fix(browser): app state before the waiting tool answers - #97
Merged
Merged
Conversation
…swers The event loop woke the tools waiting for an event before it published the page info to the app. A click that opened a tab could answer the bot while the app's tab list still had one tab; the macOS runner hit it.
…ge run The setup of a tab a page opened lets the page run and, when the owner watches, starts its screencast; the bot's tool could read the new page while the event loop was still in that setup, before it published the tab list. The tab is published as soon as it joins the list.
The address of a tab a page opened reaches the app through events that wait while the tab is set up, so the app may show it a moment after the bot read the page. The second macOS run showed the tab without it yet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the macOS runner, a click that opened a tab could answer the bot with the new page ("Thanks, Tab") while
browser.liststill showed only the opener tab. It failed innew_tabs_and_dialogs_reach_the_bot_and_the_owner_watchesin 3 of 4 macOS runs; the list printed by the test showed the one old tab.Two places let the bot get ahead of the app:
attachedadds the tab to the session, then waits for its setup:Runtime.runIfWaitingForDebuggerlets the page run, and the screencast starts when the owner watches. The tool'ssettlereads the session directly, so it saw the loaded page while the event loop was still inside that setup and had not published the tab list. The tab is now published as soon as it joins the list.moved) still wakes nobody, as before.Checks: clippy; the browser tests three times in a row on Windows (Edge) and twice on Linux (Docker, Chromium), all green. The race only showed on the macOS runner, so this PR's macOS job is the real check.
Update: with both fixes, a second macOS run showed two tabs, but the new tab still without its address. That address comes through
Target.targetInfoChanged, which waits in the queue while the event loop sets up the tab. So the app can still trail the bot by a moment. That is fine for the owner, and the bot's own result is right. The test now waits up to 5 s for the app's list to catch up instead of reading it once. Closing the gap completely would mean setting tabs up off the event loop, which I left out without a Mac to check it on.