Context
K reported that the player's displayed playback speed (pointed at via #ytd-player > div:nth-child(1) / //*[@id="container"]) didn't match the speed our extension actually applies. Manually confirmed the queue-overlay fix works first; this was a secondary, lower-priority observation. Per instruction, this is research-only — no code changes, just findings for a future call.
What was tested
Live Firefox session against a real youtube.com watch page (not a fixture), using the extension's actual setSpeed code path (moviePlayer.setPlaybackRate() + video.playbackRate/defaultPlaybackRate assignment, see src/player-adapters/html5-video-player-adapter.js).
Findings
-
The #container XPath is a false lead. //*[@id="container"] resolves to DIV#container.style-scope.ytd-masthead — the page masthead wrapper, unrelated to the player. #container is a non-unique id reused by several Polymer components on the page, so a bare XPath grabs the first (wrong) match.
-
The element K actually saw is .ytp-speedmaster-label, inside .ytp-speedmaster-overlay (nested under the player, sibling structure near #movie_player). Its text was "2x".
-
That label is not a live speed readout — it's a static onboarding badge. Confirmed on a pristine page load (video untouched, playbackRate: 1) the label already reads "2x". After setting the real rate to 0.75 via the extension's own code path, the label still reads "2x", unchanged. The overlay's own markup carries class="ytp-speedmaster-user-edu" and the element is style="display: none" by default — it's YouTube's hidden "double-tap to jump to 2x" gesture tutorial, not a status indicator. There is no actual mismatch/sync bug on our side here.
-
What's real: the classic gear (⚙️) → "Playback speed" submenu item was completely absent from .ytp-panel-menu in this session — only "Subtitles/CC" was present. So for at least some accounts/sessions, YouTube currently gives users no native, reliable way to see the currently-applied speed at all (the promo badge above can't be used for this, and the classic menu item may not be present).
Why this is worth a future look
Our extension already applies speed correctly (verified: video.playbackRate lands on the requested value every time). The gap is purely UX: if YouTube's native surfaces for confirming speed are unreliable (a hidden promo badge that never updates, and a settings item that can disappear), a user has no trustworthy way to visually confirm what our extension actually did — which is exactly what led to this report.
Possible future direction (not scoped, not committed)
Consider our own lightweight on-page confirmation (e.g. a brief toast/badge, similar in spirit to the queue-add confirmation badge already shown by src/ui/queue-overlay.js) when the extension applies a default/preset speed, instead of relying on YouTube's own UI to reflect state. Would need its own spec before implementation — not scoping here.
Repro notes
Tested via a throwaway Playwright script against live youtube.com (Firefox), not committed. Gear-menu absence and speedmaster badge behavior may be account/A-B-test dependent — worth re-checking on a couple of accounts before designing any fix.
Context
K reported that the player's displayed playback speed (pointed at via
#ytd-player > div:nth-child(1)///*[@id="container"]) didn't match the speed our extension actually applies. Manually confirmed the queue-overlay fix works first; this was a secondary, lower-priority observation. Per instruction, this is research-only — no code changes, just findings for a future call.What was tested
Live Firefox session against a real youtube.com watch page (not a fixture), using the extension's actual
setSpeedcode path (moviePlayer.setPlaybackRate()+video.playbackRate/defaultPlaybackRateassignment, seesrc/player-adapters/html5-video-player-adapter.js).Findings
The
#containerXPath is a false lead.//*[@id="container"]resolves toDIV#container.style-scope.ytd-masthead— the page masthead wrapper, unrelated to the player.#containeris a non-unique id reused by several Polymer components on the page, so a bare XPath grabs the first (wrong) match.The element K actually saw is
.ytp-speedmaster-label, inside.ytp-speedmaster-overlay(nested under the player, sibling structure near#movie_player). Its text was "2x".That label is not a live speed readout — it's a static onboarding badge. Confirmed on a pristine page load (video untouched,
playbackRate: 1) the label already reads "2x". After setting the real rate to0.75via the extension's own code path, the label still reads "2x", unchanged. The overlay's own markup carriesclass="ytp-speedmaster-user-edu"and the element isstyle="display: none"by default — it's YouTube's hidden "double-tap to jump to 2x" gesture tutorial, not a status indicator. There is no actual mismatch/sync bug on our side here.What's real: the classic gear (⚙️) → "Playback speed" submenu item was completely absent from
.ytp-panel-menuin this session — only "Subtitles/CC" was present. So for at least some accounts/sessions, YouTube currently gives users no native, reliable way to see the currently-applied speed at all (the promo badge above can't be used for this, and the classic menu item may not be present).Why this is worth a future look
Our extension already applies speed correctly (verified:
video.playbackRatelands on the requested value every time). The gap is purely UX: if YouTube's native surfaces for confirming speed are unreliable (a hidden promo badge that never updates, and a settings item that can disappear), a user has no trustworthy way to visually confirm what our extension actually did — which is exactly what led to this report.Possible future direction (not scoped, not committed)
Consider our own lightweight on-page confirmation (e.g. a brief toast/badge, similar in spirit to the queue-add confirmation badge already shown by
src/ui/queue-overlay.js) when the extension applies a default/preset speed, instead of relying on YouTube's own UI to reflect state. Would need its own spec before implementation — not scoping here.Repro notes
Tested via a throwaway Playwright script against live youtube.com (Firefox), not committed. Gear-menu absence and speedmaster badge behavior may be account/A-B-test dependent — worth re-checking on a couple of accounts before designing any fix.