pull#3
Merged
Merged
Conversation
fix: poll for mdl.name before fallback CDP injection
Tizen 6.5 Cobalt enforces Trusted Types which blocks setting script.src to a plain string (TypeError: Failed to set the 'src' property on 'HTMLScriptElement': This document requires 'TrustedScriptURL'). Replace the script-tag injection in the fallback interval with a fetch of the script source followed by Runtime.evaluate of the code directly. CDP evaluation bypasses Trusted Types DOM restrictions. Use window.__tbInjected as a guard to prevent double-execution on subsequent poll ticks. Reuse the modulesCache so the source is only fetched once. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: bypass Trusted Types for fallback injection on Tizen 6.5
- Log executionContextCreated with contextId so we can see when/if it fires
- Log the userscript URL in all three injection paths:
* script-tag path (executionContextCreated, !evaluateScriptOnDocumentStart)
* fetch+addScriptToEvaluateOnNewDocument path (evaluateScriptOnDocumentStart)
* fallback eval path (cached vs fresh fetch)
- Log when the CDP __ttLogQueue drain actually picks up entries ("draining N entries")
so we can confirm TizenTube logs are reaching TizenBrew
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feat: add comprehensive CDP injection and log-queue logging
… CDN LaunchModule handler copied fullName, versionedFullName, mainFile etc. to currentModule but never copied sourceMode. buildScriptUrl() in debugger.js then fell back to 'cdn' and injected from jsDelivr even when the module was configured as 'direct' (unpkg). Fix: copy mdl.sourceMode in LaunchModule, add sourceMode to currentModule initial state, and clear it on CDP disconnect. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: propagate sourceMode to currentModule for correct userscript URL
Logs every proxied request (method, file, sourceMode, upstream URL) and the HTTP status of the upstream response. Also adds error handling with a 502 response on upstream fetch failure. This makes the proxy path visible in the log viewer so we can confirm whether Tizen 5.5 uses it for injection. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feat: add request/response logging to 8081 module proxy
executionContextCreated fires for every JS context: main frame, workers, iframes, isolated worlds. TizenBrew was injecting into all of them, causing TizenTube to initialize multiple times (5 toasts on Tizen 5.5). Check auxData.isDefault before injecting — CDP sets this true only for the main frame default world. Also log auxData.type/isDefault so we can see what contexts Cobalt creates. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: only inject userscript into main frame execution context
…together executionContextCreated injects via script tag; the fallback interval injects via Runtime.evaluate. Both ran for the same context because neither knew the other had fired — causing TizenTube to initialize twice (double toasts, double log entries). Set window.__tbInjected = true at the END of the script tag expression (after appendChild) so that: - On Tizen 5.5 (no Trusted Types): script.src succeeds, __tbInjected is set, fallback interval sees it and stops with "already" - On Tizen 6.5 (Trusted Types): script.src throws before __tbInjected is set, so the fallback eval path correctly takes over as the sole injector - Also guard the expression with if(window.__tbInjected) return so a second executionContextCreated (e.g. YouTube TV post-redirect navigation) skips re-injection in the same context Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: prevent double injection from script-tag and eval paths
YouTube TV creates two default execution contexts on first launch: one for the initial page load and one after the DIAL navigation fires ~4s later. Both have auxData.isDefault=true so the existing isDefault filter does not help. Without a service-side guard, the script tag path injects into both contexts causing two toasts and all log entries appearing twice. Add contextHasBeenInjected flag (reset on CDP disconnect): - Script tag path (executionContextCreated): set flag on first default context, skip with a log line on every subsequent one - Fallback eval path: set flag when eval succeeds - Disconnect handler: reset flag so the next CDP session starts fresh On 6.5 this was already hidden by Trusted Types blocking the script tag, but the flag makes it explicit and prevents any future double-injection edge cases. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: skip injection into second default context per CDP session
When the user pressed the launch button multiple times before Cobalt accepted the debug port, each press spawned a new startDebugging retry loop (up to 15 × 750 ms). All loops raced to connect and, once Cobalt was ready, multiple CDP clients connected near-simultaneously — each with its own contextHasBeenInjected flag — causing TizenTube to be injected once per client. Adds a module-level session counter (_activeSessionId). Each new top-level startDebugging call increments it and captures the value. Retry iterations belonging to a superseded session abort before connecting. If a superseded session's CDP callback fires anyway (the connection was already in flight), the client is immediately closed. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: cancel superseded CDP retry loops to prevent multi-client injection
Two bugs caused TizenTube to inject twice in a single CDP session: 1. The fallback interval never checked contextHasBeenInjected at the top of each tick. After executionContextCreated injected via script tag into contextId=2, the fallback would fire on the next tick, evaluate window.__tbInjected in the now-active contextId=3 (a different page whose window object has no flag set), see "ready", and inject again. 2. contextHasBeenInjected was set synchronously BEFORE the script-tag Runtime.evaluate resolved. On Tizen 6.5 the eval throws (Trusted Types), so the flag was true but no injection had succeeded — leaving the fallback unable to take over. Fixes: - Add contextHasBeenInjected check at the TOP of each fallback tick so it stops immediately once any path confirms success. - Introduce scriptTagAttempted flag: set synchronously when the script-tag path starts (blocks fallback from racing), cleared on failure (Trusted Types) so the fallback can inject via eval instead. - contextHasBeenInjected is now set only in the async .then() after the script-tag eval returns without exceptionDetails (confirmed success). - Add window.__tbInjected guard inside doEval expression as a final page-side safety net against any remaining timing races. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: eliminate double injection from script-tag/fallback race
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
2 participants
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.
No description provided.