Get Overlay URL stopped working

[clarkezone]

I was playing with the live chat overlay extension this evening and it was working well until it stopped :-). From studio, i pop out the chat window and see things working fine as shown in these two screenshots:

and

When I click on Get Overlay (in order to get something I can key using OBS with Ultrastudio) i see no output in the modified page:

of by following the URL:

This was working earlier so I hope I haven't tripped a rate limit. Any ideas greatly received :-)

Thx Aaron

[aaronpk]

Strange, I don't see anything wrong.

In your screenshots, you have two separate session IDs (the part after the #). Is that just an artifact of testing it a few times? Or maybe that's the problem? It looks like the browser window you opened separately is not the same URL as the one showing in the screenshot of the youtube chat.

[clarkezone]

Captured over the course of multiple tests. I confirmed it was still repealing yesterday after your live stream. Wondering if there is anything I could look at in browser tools or if there is a pointer to building and debugging the extensions

[aaronpk]

Checking the JavaScript console for errors would be a good start. You should be able to go to View -> Developer -> JavaScript console. Then click around and see if any errors pop up.

[clarkezone]

Debugging the working path, looks like line 113 in youtube.js is what's doing the jquery append(html) operation.. in the working case i see a breakpoint hit on next() after the chain of actions including the delay(...) containing a closure:

In the non-working case, looks like the code is going down the if(sessionID) branch (line 102) instead of the else where the above append(html) lives and never entering the else branch that would be adding something to the DOM:

although if i patch sessionID to be empty in the console, forcing the code to go down the jquery append path, execution never gets to next() as it does in the working case. Unfortunately debugging in to the chain of actions in minified jquery source wasn't particularly fruitful to find a root cause for the failure.

Does this give you more to go on?

[aaronpk]

So the sessionID is what switches between showing the comment in the same window vs showing in the remote view. If you're opening the overlay url you should see it make that post request on line 109. That sends the message to my server which renders it in the chat.aaronpk.tv website. Once you click get overlay url it will stop showing the comment in your YouTube window since it's sending it to the remote server instead. Are you really not seeing the message on the chat.aaronpk.tv page when you click it in your YouTube chat window? Do you have any firewall thing that might be blocking the request? I'm seeing lots of other messages going through right now so I'm wondering if this is something specific to your environment that we can troubleshoot more.

[clarkezone]

I do see posts although hard to tell if they succeed or fail.. here's an example of an active url: https://chat.aaronpk.tv/overlay/#XVvkjs5Tnn and here is the url that the post function is trying to send:
https://chat.aaronpk.tv/overlay/pub?id=XVvkjs5Tnn

What's weird is that it was working fine for a bit on Saturday on multiple machines and then stopped, nothing I can think of at this end changed. I do use Tailscale on all my devices but that should only come into play for calls between devices on the tailnet. To rule that out have tried with it disabled. I'm seeing the same thing in both Chrome and Brave. I have a Ubiquity UDM pro, no fancy firewall settings.

[aaronpk]

Do you have a minute for a zoom call? I think this is going to take some synchronous debugging

[aaronpk]

(redacted)

[clarkezone]

Thanks to @aaronpk who helped to debug this. It appears that what happened here is that,

1. in the course of testing, I launched Chrome in addition to my primary browser (Brave). I haven't used Chrome in a while on that PC, likely before the upgrade from win10 to win11 hence it was a super old version. Upon reflection, it's possible that autostart of the chrome updater may have been disabled in Windows (unconfirmed theory).
2. This version of Chrome interacted poorly with the chat server used by the chrome extension, having some incompatibility that caused CORS requests to fail. In addition, this version of chrome appeared to interact differently with tailscale causing requests to come from a different source IP
3. As a consequence of 2, chat messages were not getting correctly pushed to the chat server, hence client sessions were not getting relayed out to subscribers for rendering in overlay windows created from the Get Overlay URL button.
4. As part of debugging this, chrome updated itself and at some point, clicking on a link launched the new version. There was a brief period where there were two different instances running at once, both showing up in the taskbar.
5. With the updated version of Chrome, the CORS issue went away and requests no longer got routed out via Tailscale. Consequently, chat messages started getting pushed to the chat server and were correctly rendered on all browsers connected to that session on all devices including in the OBS embedded browser that had original been having problems.

Lesson here is, if you are having an issue like this ensure you are running a current version of Chrome.