Version
Midscene Chrome extension from main at ea75076b5 (workspace version 1.13.3).
Details
A recording event belongs to the tab where its content script runs. When that script asks the service worker for a screenshot, Chrome supplies the tab identity in sender.tab. The worker passes sender.tab.windowId to chrome.tabs.captureVisibleTab, but that API captures the currently active tab in the window, not necessarily sender.tab. The window ID identifies the right window without identifying the right page.
There is a short delay before the recorder sends an event and takes its after-action screenshot. If I click in tab A and switch to tab B during that interval, A's screenshot request can capture B. The resulting image is then stored on A's event as screenshotAfter. Checking the active tab only at the start would still leave a race: A can be active when the check runs, B can become active while capture is pending, and A can be active again by the time the response is checked.
This silently changes the visual context of the recording. The timeline, exported recording, and screenshot-backed script generation can show or consume a page unrelated to the recorded action. It can also include content from another tab that the user did not start recording.
Reproduce link
Any two pages in one Chrome window work, for example tab A and tab B.
Reproduce steps
- Load the Midscene Chrome extension, open the two pages in separate tabs in the same window, and start recording on tab A.
- Click on tab A, then immediately switch to tab B while the recorder finalizes the event. The event-send path has a 200 ms delay before its screenshot request.
- Return to the recorder and inspect the click event's after-action screenshot. Switching B→A again while capture is in progress exercises the additional race described above.
Actual behavior: The event from A can carry a screenshot of B.
Expected behavior: An event should only receive a screenshot from its source tab. If that tab is no longer continuously active during capture, the request should return no new screenshot rather than accept an image from another tab.
The worker should verify the source tab before and after capture and observe tab activations during the capture itself. That covers both a simple A→B switch and an A→B→A switch. The corresponding fix is in PR #3194.
Version
Midscene Chrome extension from
mainatea75076b5(workspace version1.13.3).Details
A recording event belongs to the tab where its content script runs. When that script asks the service worker for a screenshot, Chrome supplies the tab identity in
sender.tab. The worker passessender.tab.windowIdtochrome.tabs.captureVisibleTab, but that API captures the currently active tab in the window, not necessarilysender.tab. The window ID identifies the right window without identifying the right page.There is a short delay before the recorder sends an event and takes its after-action screenshot. If I click in tab A and switch to tab B during that interval, A's screenshot request can capture B. The resulting image is then stored on A's event as
screenshotAfter. Checking the active tab only at the start would still leave a race: A can be active when the check runs, B can become active while capture is pending, and A can be active again by the time the response is checked.This silently changes the visual context of the recording. The timeline, exported recording, and screenshot-backed script generation can show or consume a page unrelated to the recorded action. It can also include content from another tab that the user did not start recording.
Reproduce link
Any two pages in one Chrome window work, for example tab A and tab B.
Reproduce steps
Actual behavior: The event from A can carry a screenshot of B.
Expected behavior: An event should only receive a screenshot from its source tab. If that tab is no longer continuously active during capture, the request should return no new screenshot rather than accept an image from another tab.
The worker should verify the source tab before and after capture and observe tab activations during the capture itself. That covers both a simple A→B switch and an A→B→A switch. The corresponding fix is in PR #3194.