paperpile: correct the wedged-tab explanation (it is not YouTube)#59
Merged
Conversation
a21a34d's comment says "a playing YouTube tab reproduces this", attributing the CDP hang to YouTube or to media playback. That was an over-specific inference from a single observation, and it is wrong. Re-probing the same browser three hours later: the YouTube tab that had hung reliably (twice, with and without Network.enable) now answers in milliseconds, while a wrds-www.wharton.upenn.edu tab has started hanging instead. One of six page targets hangs at any given moment, and which one drifts. It tracks renderer busyness, not the site. No code change — the fix was already right, and this makes it more clearly right: if the culprit were a known site you could skip it, but since any tab can be wedged and it moves, avoiding page targets entirely is the only sound answer. Worth correcting rather than leaving: the comment is what the next reader reasons from, and "it's the YouTube tab" invites exactly the wrong fix. Bump 5.70.1 -> 5.70.2 so this reaches the version-keyed cache — per #58, a change without a bump never ships. Verified: bash -n clean, extraction still returns 12 cookies with plack_session present. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UZvrft29zMGgks5abHVtVK
The only conflict was the manifest version: this branch bumped 5.70.1 -> 5.70.2, while main advanced to 5.72.0 via #61 and #62. Resolved by taking main's line and re-bumping to 5.72.1, so the comment correction still reaches the version-keyed cache (per #58, a change without a bump never ships). refresh-auth-from-dia.sh merged cleanly — main never touched it. Added the matching CHANGELOG entry, which the branch predates. Verified: both manifests re-validate as JSON, no stray 5.70.x or 5.72.0 refs in .claude-plugin/, bash -n clean on refresh-auth-from-dia.sh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XTS65gq18Rf3K98tJa3Me1
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
1 participant
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.
Correcting my own comment from #57. No code change — the fix is right; the explanation of why is wrong, and the explanation is what the next reader reasons from.
What I claimed
That attributes the CDP hang to YouTube, or to media playback. It was an over-specific inference from a single observation.
What is actually true
Re-probing the same browser three hours later:
music.youtube.com/playlistwww.youtube.com/watchwrds-www.wharton.upenn.edu/…read.readwise.io,web.morgen.so,mail.superhuman.com,chrome://newtabThe YouTube tab that hung reliably — twice, with and without
Network.enable— now answers in milliseconds, and an unrelated WRDS tab hangs instead. One of six page targets is wedged at any moment and which one drifts. It tracks renderer busyness, not the site.Why this is worth a commit
It makes the fix more clearly right rather than less. If the culprit were a known site you could special-case it — skip YouTube, prefer a "safe" tab. Because any tab can be wedged and the identity moves, avoiding page targets entirely is the only sound answer. Left as-is, the comment invites exactly the wrong fix.
Also bumps
5.70.1→5.70.2so this actually reaches the version-keyed cache — per #58, a change without a bump never ships.Verified:
bash -nclean; extraction still returns 12 cookies withplack_sessionpresent; both manifests re-validated as JSON with no stray5.70.1.Related: edwinhu/superhuman-cli#28 fixes a live instance of this same page-target gamble.
🤖 Generated with Claude Code
https://claude.ai/code/session_01UZvrft29zMGgks5abHVtVK