Follow-up to #16.
The Save-to-playlist drive (openSaveToPlaylistPopup / closeSaveToPlaylistPopup
in src/ui/playlist-popup-driver.js) verifies the sheet's own open/closed DOM
state before proceeding, but does not verify that YouTube's backend has
actually persisted a toggle before the sheet is closed and the popup cache
(playlistCache) is invalidated/rewritten.
Reported live: if the picker is reopened for the same video immediately after
an add/remove, in rare cases the freshly-scraped rows can still reflect the
pre-change state, suggesting the toggle click resolves client-side (and the
sheet closes) before the underlying playlist membership write has round-tripped.
Not reproduced with captured DOM evidence (no live logged-in Playwright
session available in this environment - same limitation as #17), so this is
filed as a known risk rather than a confirmed root cause.
Possible future directions, none implemented:
- re-scrape and diff rows after close, retrying if they don't reflect the
expected checked state within a short timeout
- treat the popup cache as provisional until a subsequent open confirms it
Low priority - functionally the add/remove itself works; this only affects
the freshness of the picker's checked-state display if reopened very quickly
after a change.
Follow-up to #16.
The Save-to-playlist drive (openSaveToPlaylistPopup / closeSaveToPlaylistPopup
in src/ui/playlist-popup-driver.js) verifies the sheet's own open/closed DOM
state before proceeding, but does not verify that YouTube's backend has
actually persisted a toggle before the sheet is closed and the popup cache
(playlistCache) is invalidated/rewritten.
Reported live: if the picker is reopened for the same video immediately after
an add/remove, in rare cases the freshly-scraped rows can still reflect the
pre-change state, suggesting the toggle click resolves client-side (and the
sheet closes) before the underlying playlist membership write has round-tripped.
Not reproduced with captured DOM evidence (no live logged-in Playwright
session available in this environment - same limitation as #17), so this is
filed as a known risk rather than a confirmed root cause.
Possible future directions, none implemented:
expected checked state within a short timeout
Low priority - functionally the add/remove itself works; this only affects
the freshness of the picker's checked-state display if reopened very quickly
after a change.