Time in Video-URL is being ignored

[Emerentius]

When opening a link to a youtube-video with a specified time in the URL, the video still begins at 0:00. Sample-URL: https://www.youtube.com/watch?v=PDEce3mtkRg#t=1800.

This does not happen when youtube's own html5 setting is set in cookie, but, well, that would make the addon's main draw pointless.

A workaround I found is to change the number in the url to something else like 1801 and pressing enter. Also some inconsistent behaviour where it sometimes worked from the get go (maybe related to vid still being in cache) or the workaround works without changing the url yada yada.

[Emerentius]

Was a bit trigger happy on that PR but it doesn't actually fix it. The problem seems to be related to Noscript. It doesn't happen when I have it deactivated. Completely deactivated, not just allowing all scripts.

Timelinks do work when the time is given via a parameter (v=..&t=..) but not as an html anchor.

[klemens]

Sorry for responding so late.

I am not sure that this is only related to Noscript. I did a test on a clean profile and it didn't work. The problem seems to be the following: When you are enabling the html5 "test", youtube uses the html5 player by default and not as a fallback. It seems as soon as it uses it as a fallback (eg when the "Disable Flash on YouTube" option is enabled or flash is disabled completely), the seeking no longer works. So this seems to be a youtube bug.

Your PR #42 seems to fix it in some cases, however I don't like how it is done. (setTimeout) This has proven to be very buggy and I am trying to find a better solution for the pause video case as well. I think a better solution would be to actually add the html5 "test" cookie in each request to youtube.com/watch, similar to how we force the IE user agent. This could also fix some other potential issues (mainly for embedded videos). What do you think?

[Emerentius]

That does sound preferable and may also fix some issues with SPF. Activating the HTML5 test adds the parameter f2=40000000 to the PREF cookie. The easiest way would be to simply set that parameter but sadly (thankfully) cookies are not sent anymore when the site is blocked from setting cookies.

I'll look into it, but won't promise anything. I really don't know javascript.

[klemens]

You don't have to implement it, I will do when I have some time to spare. ;-) I will probably add this as a new video loading method.

The implementation should be very similar to the already existing UserAgentChanger.

[klemens]

I implemented the discussed CookieChanger (f3e66c1c3383b7543f4c61d4fe7abef52ad892be), so fixing this issue should be trivial now. Something like:

var youtubeHTML5Test = new CookieChanger("www.youtube.com", (cookies) => {
    if(cookies.has("PREF")) {
        var pref = cookies.get("PREF");
        /* Add or replace f2=40000000 in pref */
        cookies.set("PREF", pref);
    } else {
        cookies.set("PREF", "f2=40000000");
    }
});

This will be in the next alpha (3).

[Emerentius]

That's cool and will probably come in handy. At least for this bug, it's already fixed on Windows since FF37 and will probably be on Mac in a week (FF38, 12.5.15) with partial media source extension support. The HTML5 player is default if those extensions are there. Somewhere in the last weeks YT seems to have changed their policy a bit. Right after FF37 came out, supporting everything but MSE & WebM VP9 wasn't enough for defaulting to HTML5, but now YT does just that. Haven't seen anything on the timeline for Linux MSE. So that one will still need it.

[klemens]

Implemented for the main domain in 3a69da4643e0592b7871bb0823ab211b6103fe1d.