This is to fix the bug for Brave. (YouTube Live Chat)
Target User: Brave
See https://community.brave.com/t/youtube-live-chat-30-sec-delay/
Root Cause
YouTube calls "urlChanged" twice to set the iframe url.
In the first attempt, chatframe.contentDocument is null. So it will set the src of the iframe.
In the second attempt, chatframe.contentDocument is non-null. So it will set the url using chatframe.contentDocument.location.replace
Both Brave and Chrome will do these two attempts. Both attempts are just 10ms aparted.
The difference is, in brave, the first attempt affected the second attempt, but in chrome, the first attempt would not affect the second attempt.
Details in Github issue#25694
Issue Discussion
Issue "youtube-live-chat-30-sec-delay"
Below is an analysis of the issue reported in the thread “YouTube live chat 30 sec delay” on the Brave Community forum:
Issue Overview
Users have reported that when watching YouTube live streams in Brave (using the default, non‐private browsing mode), the live chat is delayed by approximately 30 seconds. In contrast, both YouTube’s video/audio and live chat load immediately when viewed in Chrome or Brave’s private mode. This inconsistency points to a problem that appears to be specific to the normal browsing profile in Brave.
Reproduction and Observations
Reproduction Steps:
- Open a YouTube live stream that features a live chat.
- Notice that while the live video and audio begin almost immediately, the chat messages only start populating after about 30 seconds.
Observed Behavior:
- The delay is reproducible on different operating systems (e.g., Windows and Manjaro Linux).
- Disabling extensions and even reducing Brave Shields does not resolve the delay.
- The issue does not occur when using Brave’s private window or when using a new, clean profile, although some users have observed intermittent reoccurrence even in new profiles after certain interactions (e.g., closing live polls).
Potential Causes
Based on the discussion in the thread, several potential causes have been identified:
Profile-Specific Data or Caching:
Since the issue does not occur in private mode or a fresh profile, it suggests that certain cached data or cookie settings in the default profile might be interfering with the live chat loading.
Interference from Extensions or Ad Blocking:
Although users have reported disabling all extensions and lowering shields, network logs (showing errors like net::ERR_BLOCKED_BY_CLIENT) hint that some requests may still be getting blocked. This might indicate residual interference from ad-blocking or tracking protection rules inherent to Brave.
Browser Bug in Handling YouTube API Requests:
The log snippets reveal delayed or blocked requests related to YouTube’s API (e.g., delay parameters in the URL). This suggests that a bug in how Brave handles certain YouTube API requests—possibly introduced in the version of Brave using Chromium 105—could be responsible.
Community Feedback and Workarounds
Clearing Cookies:
Some users speculated that cookie data might be the culprit, as one comment noted that the problem might be resolved by clearing cookies. However, at least one user mentioned that clearing cookies for Google domains did not help.
Creating a New Profile:
Testing with a new profile appears to temporarily resolve the issue. This supports the idea that some settings or cached data in the original profile might be contributing to the delay.
Intermittent Nature:
Even within new profiles, users have observed that after interacting with certain elements on the live stream (such as closing polls), the delay can reoccur. This points to a complex interaction between profile settings and YouTube’s dynamic elements.
Conclusion
The issue of the 30-second delay in YouTube live chat on Brave is likely due to a combination of profile-specific data/caching and Brave’s handling of certain API requests or network calls. The fact that the problem does not occur in private mode or on other browsers (like Chrome) suggests that it is not an inherent incompatibility with YouTube but rather a bug or misconfiguration within the normal browsing mode of Brave. Users facing this issue may find temporary relief by using private mode or creating a new profile, but a long-term fix would likely need to come from an update or patch from the Brave development team.
Issue 25694
Below is a detailed analysis of the GitHub issue #25694:
Overview
Title: YouTube live chat remains blank for 30 seconds on live streams
Status: Closed (fixed by brave/brave-core#24763)
Reported by: @snowbound on September 29, 2022
This issue concerned a delay in the live chat’s appearance when viewing YouTube live streams in Brave. Users observed that—even though the video would start playing normally—the chat window remained blank for about 20–30 seconds.
Steps to Reproduce
- Open a live YouTube stream (a stream known to have live chat enabled).
- Observe that while the video plays, the chat remains blank for an extended period (approximately 30 seconds).
- Reloading the page or clearing the browser cache did not consistently resolve the delay.
These reproduction steps were confirmed in both beta and release channels, while other browsers (like Chrome, Firefox, and Edge) did not exhibit this delay.
Key Observations & User Feedback
- Delayed Chat Load: The core problem was that the chat component did not render concurrently with the live video. Users noticed that after some action (like switching tabs or after a timeout), the chat would eventually load.
- Ad-related Behavior: Several comments noted that the delay seemed linked to the appearance of non-skippable preroll ads. Even when Brave Shields were enabled (which blocked or altered ad behavior), the chat only populated once the ad reached about a 20-second mark.
- Reproducibility Factors:
- The issue was reproducible on a clean profile and a new installation of Windows 10.
- Testing with other browsers (or even Vivaldi with similar ad-blocking settings) did not show the delay, pointing to a Brave-specific implementation detail.
- Console Logs & Developer Analysis:
- Devtools outputs revealed timeouts and possible race conditions with event handlers.
- There was an indication that the load order for a component referred to as “GreaseLion” might be misaligned—potentially delaying when the chat could be rendered.
- Community Impact:
- Users, especially stream moderators and viewers who rely on real-time interactions, expressed significant frustration.
- Several community threads (including discussions on Reddit and Brave Community) highlighted the severity, with some users even switching browsers as a workaround.
Root Cause Analysis
Based on the investigative comments from Brave developers:
- Race Condition / Load Order Issue:
The initial hypothesis was that the event handlers responsible for loading the chat were being timed out or delayed due to a conflict in the load sequence. This was tied to when and how certain client hints (like those provided via the JS API) and related ad-blocking behavior were processed.
- Ad Preroll Interference:
The presence of non-skippable ads, which are meant to load prior to the main content, was identified as a trigger. In Brave, even when ad blocking was active, these ads interfered with the timely rendering of the live chat.
- Brave-Specific Handling:
The issue was not observed in browsers like Chrome or Vivaldi, indicating that a specific Brave implementation (possibly related to its privacy shields and client hints) was at fault.
Resolution & Fix
- Fix Implemented:
The bug was addressed in the Brave Core codebase (brave/brave-core#24763) by modifying the handling of client hints and adjusting the load order of relevant event handlers.
- Verification:
QA teams confirmed that the issue was resolved on Nightly builds (as mentioned in the July 2024 comments) and later uplifted into beta and stable channels.
- Developer Comments:
Final comments from team members (e.g., @bsclifton, @szilardszaloki) indicated that after the changes, the live chat would load in a timely manner, even on platforms like Windows 10.
Impact & Lessons Learned
- User Experience:
The 30-second delay was particularly disruptive for users engaged in live interactions, such as chat moderation or real-time commentary.
- Importance of Timing & Event Management:
This issue underlines the sensitivity of web features to load order, especially when multiple asynchronous tasks (like ad processing and live content loading) are involved.
- Cross-Browser Behavior:
Since the bug was Brave-specific, it highlighted how certain privacy or ad-blocking features can inadvertently affect core web functionalities.
Final Remarks
The analysis of issue #25694 demonstrates a classic case where a feature (live chat) suffered from timing issues—likely exacerbated by the browser's ad handling and client hints implementation. The resolution involved adjusting the load sequence and handling of client hints, and it has since been verified as fixed in subsequent builds. This serves as a reminder of the balance needed between privacy features and seamless user experience in modern browsers.
