Greasy Fork

In latest Firefox (macOS) it does not work when opening YouTube link in a new tab via context menu or Command + Click. This happens after cookies got cleared or blocked. After refreshing the tab, it works correctly. The problem does not persist if I open a link in a blank tab (even with empty cookies).

UPDATE:
Changing @run-at value to document-end solved the problem.

I'll take a look at this issue.
Changing the @run-at value is a hint to what is the problem, but is not a solution in itself. It forces the userscript to run very late, and it can sometimes be too late.

According to metadata block documentation, document-end is the default value for @run-at key, making script to execute when DOMContentLoaded is fired.

I know that, but with at least TM (as explained by its author), this means that the script is fired after DOMContentLoaded (because of how it is injected), and there could be a race condition with other scripts on the page. In this script I inject a function to intercept "pause" and "stop" calls. That is what is failing in your case because of how I delay this process when the video element API is not available yet.

You can try this for me:

• set @run-at back to document-start
• at the bottom of the script, in the 2nd occurence of s.textContent=, change var c=80 to var c=800 or even to var c=2000

If it doesn't solve the problem I'll have to look elsewhere.

I tried changing var c to a higher value, but it does not help.

When the issue occurs in browser console I noticed this error — Uncaught TypeError: document.head is null. I suppose this is the cause.

ok, I know what it is
I have updated FF on another laptop. I see the same error.
I know how to fix it. It'll be ready in a few minutes.

Edit: I have another weird error. I'll take the time to understand this.

Sure, no worries, take your time.

I've updated the script. A small change was enought.
The other problem was with a syntax not accepted by FF (when I tried to fix), and a bug in tampermonkey than prevents the script to match frames.

For the time being, the popup shown in the 2nd picture is only hidden and not dismissed if you're using the script in tampermonkey or greasemonkey in FF. It will work as expected if violentmonkey is used. Chromium-based browsers have no problem.

Now it works properly with untouched @run-at, Violentmonkey in my case. Thanks! Well done!

Just to let you know that I've updated the script and that an alternative method (on the cookie level) is used to bypass FF+TM bug.
If you ever want to use TM, the script is not limited anymore.

A noticed a few more issues with the current release version 0.3.7:

* video starts paused when opening from list view (search results, channel video section, startpage)
* startpage search field focus is lost after page is fully loaded (seems like focus is switched to invisible cookies dialog)

Note: in my current setup youtube.com cookies are blocked.

> paused ... from list view

It's the situation I talk about in the description of the userscript. In that particular case, YT bypasses the API and the userscript can't prevent stop/pause actions on the video. So far I haven't found a solution to this.

> losing focus.
> cookies blocked

I think that if your browser blocks the cookie, you encounter pausing&focus problems every time.
Test by accepting the cookies, and see if it gets better.


While writing this I started FF on another computer (not installed on this one), and I have tested:
There is another reason for accepting cookies: to save CPU (but I must verify if it's a valid assumption) the userscript disables its popup-catcher routine once it has caught the popup. So it doesn't see the next one on the video. (I think disabling the routine is stupid since it's never disabled on a new page when cookies have already been accepted, and it doesn't cause a slowdown)

I'll do more tests to see if changes in the script can fix parts of the behaviour.

After further analysis, the script doesn't disable the popup-catcher. Just another process. The thing is that the popup is created only once, and then reused. I have to look for something else to catch the new popup. That done, no difference in behaviour.

This is not the source of the problem. YT is still bypassing its API (at least the version attached to the video element).

For the moment the solution is to accept YT cookies. Select "Allow for Session" to get rid of them as soon as possible if you don't want to keep them.

Thanks for your analysis and detailed explanation. Will try out different scenarios to find the optimal UX that will satisfy my needs.

Another solution is to open videos off a search result in a new tab (also see note below). In that case the userscript can control pause/stop commands.

In a situation like yours, when the browser doesn't accept cookies, YT opens the "sign-in" dialog on every possible occasion. That dialog calls the `stopVideo()` function.
It is not a problem if the initial YT page opened in the tab is a video page ; the userscript can intercept this function call. Even if you click on another video, make a search and click a video ; the userscript still works. But if the initial YT page is the homepage or a search result (eg. you open that page from a bookmark) YT uses another hook in its API. I still have to find this hook. So far no luck.

I think I've found a way to make it work better for someone like you who discards cookies.
It implies forcing YT to load the video pages entirely instead of only updating parts of the html code of the page to display the interface of the viewer.

I'm trying it right now and it works. The only cave-at is that video pages loaded from the homepage, from a channel, or from a search results are a little bit longuer to load (the interface is reloaded and displayed). Video clicked from another video page are still loaded inline.

I'll contact you to try a beta version.

Could you please try this code:
- Disable the current version of the userscript.
- create a new script and paste the content of the following page.

file remove from my server

Thanks a lot. Sure, I will try this later when I will have more time for this.

Forget about that test. I've found a way to hook the "prevent_pause" function highter in the processes, and it always works now. Even when starting with YT homepage, search or channel.
I've also managed to fix a bug here and there (for FF).

Thanks anyway for your cooperation.

Version 0.4 of the script is almost ready. Just testing in "all" browsers. Stay tuned...

How does the latest version work with your installation?

v0.4 works perfect for me now whether launching video from homepage, search result page or opening directly. Huge thank you for well done script.

To be fair I had given up on finding a way to make it work in every situation. But solving your problem made me try something else, which sparked an idea to solve the original problem. ;)