The proposal said a registered content script could be scoped to the selected
tab's origin. It cannot, in two ways that both matter.
matches is evaluated against each frame's own URL, not the tab's, so a pattern
for the top-level site would never reach the embedded player frame — the only
frame the change exists to reach. Covering a player origin that is unknown
before discovery requires <all_urls>.
And registration has no tab scoping at all: with several tabs open on the same
site, every one of them gets the script.
The honest cost is therefore that a passive monitor runs in every frame of every
http/https tab while a target is selected, which is a privacy-posture change for
a project that advertises touching only the chosen tab. Recorded so the decision
is made against the real trade rather than the flattering version.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A monitor took the current DOM as its baseline on install, so a video that was
already present counted as "not a change" and was never announced. The discovery
poll added in the previous commit reinstalled monitors every 2s, which meant a
video appearing between two reinstalls was silently swallowed — the reported
debug log had no [Content] lines at all, which is the signature of exactly this.
Monitors now announce a video that is already there when they install, which
also makes the rebuilt-frame case work by construction rather than by timing.
The reinstall interval is raised to 5s now that each install is informative.
Also adds docs/frame-targeting-handoff.md: why v3.1.2 worked immediately with
webNavigation, why reconstructing that single call from sweeps, a learned
registry, per-frame monitors and a poll keeps producing timing windows, and the
proposed structural replacement (chrome.scripting.registerContentScripts with
allFrames, no new permission) together with the project invariant it conflicts
with — which is the owner's decision, not a code change to make unasked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reported as "Receiving end does not exist" with targetReady true and no
activation errors: the election named a frame the player had already torn down.
Three defects were stacked, each hidden by the one in front of it.
The election was never released. getReadyTabVideoState() recovered through the
guarded refresh, which reports "unchanged" when no video is reachable, so the
stale frameId/documentId survived; adoption compounded it by setting hasVideo,
after which the target only moves on a frame change. An unreachable content
script — as opposed to a page that simply has no video yet — now releases the
frame election back to the top frame. The tab selection is never touched.
Switching frames destroyed the top frame's scripts. Promoting the target out of
frame 0 called deactivateTargetTab() on the previous target, which sent
TARGET_DEACTIVATE to frame 0 and tore down its content script and the chat
overlay with it. That is why chat delivery failed after promotion, and why
releasing the election pointed at an empty frame. An in-tab frame switch now
leaves the top frame alone.
Discovery could deadlock. Monitors announce new players, but a rebuilt frame is
a new document with no monitor, so the video created in it was never reported —
and nothing then triggered the upkeep that would have installed one. Monitors
are reinstalled on every lifecycle notification with a trailing-edge debounce,
and a bounded discovery poll breaks the cycle when no notification arrives at
all: 2s, capped, only while a tab is selected with no video found, stopping the
moment one is.
The new browser test adopts a nested player, destroys its document the way the
real player does, and asserts both the release and that the rebuilt player is
picked up again without touching the popup. It was flaky until the deadlock was
closed, and now passes repeatedly at a stable 8.3s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Timo