Doesn't break for me. Adding a URL param really shouldn't break things on the web, in general. I guess I'm not sure what "pretty obvious" problem you expect us to be seeing. Maybe you can tell us what exactly is broken?
Maybe I got AB tested, cause yesterday-ish all was ok.
When you watch a long VOD part by part, it looks like watch-close-...-watch-close sequence. Youtube normally remembered where you closed the video and then next click on it returned to that time (without any &t=).
Now they added &t=123 everywhere, and when you click on that url, now it becomes &t=123 in history too. And the feed may contain random-timed &t=456 links too.
Now in the third "watch" phase there's a conflict between &t= and what youtube remembered internally, and &t wins, and &t becomes const.
As a result, I watch a couple of hours, close and next time I open &t sends me far back.
For example, I recently closed this video at the time where Simon explained 3-1-1-1 arrow (25:40). But in my history it points to https://www.youtube.com/watch?v=z0rbYbqS4ug&t=691s which is basically the start. (Yes I made sure to ctrl-f5 history page etc etc.) It happens ALL the time now, basically unusable without my script.
With your script, with the t removed, what happens? Do the videos just start at the beginning now, or is there some internal clock that they start at instead?
Videos start at where I left them last time, or beginning if never watched. This worked since forever (unless you disable history completely). I believe they store it in localStorage.
Edit: after second thought, maybe they store it on server too. Anyway, everything worked almost perfectly. I could lose a timestamp once a week, but probably due to some packet error.
Someone at YT literally broke what worked, in a way that is so naive and non-web2.0, as if it was made by a php junior from early 2000s. Because e.g. if you open history and newtab a link with &t=, then you have to refresh history now after watching few minutes of the video. And every click makes it worse cause it overwrites internal data too. The original “internal” method worked perfectly because it never relied on a url that may and will become obsolete. Idk why they did that and how it was approved etc.
Doesn't break for me. Adding a URL param really shouldn't break things on the web, in general. I guess I'm not sure what "pretty obvious" problem you expect us to be seeing. Maybe you can tell us what exactly is broken?
YouTube is a JS app so adding a URL param could break the JS depending on what the JS does with it.
I haven't seen an issue, but I'm really curious to know what you are experiencing?
Maybe I got AB tested, cause yesterday-ish all was ok.
When you watch a long VOD part by part, it looks like watch-close-...-watch-close sequence. Youtube normally remembered where you closed the video and then next click on it returned to that time (without any &t=).
Now they added &t=123 everywhere, and when you click on that url, now it becomes &t=123 in history too. And the feed may contain random-timed &t=456 links too.
Now in the third "watch" phase there's a conflict between &t= and what youtube remembered internally, and &t wins, and &t becomes const.
As a result, I watch a couple of hours, close and next time I open &t sends me far back.
For example, I recently closed this video at the time where Simon explained 3-1-1-1 arrow (25:40). But in my history it points to https://www.youtube.com/watch?v=z0rbYbqS4ug&t=691s which is basically the start. (Yes I made sure to ctrl-f5 history page etc etc.) It happens ALL the time now, basically unusable without my script.
With your script, with the t removed, what happens? Do the videos just start at the beginning now, or is there some internal clock that they start at instead?
Videos start at where I left them last time, or beginning if never watched. This worked since forever (unless you disable history completely). I believe they store it in localStorage.
Edit: after second thought, maybe they store it on server too. Anyway, everything worked almost perfectly. I could lose a timestamp once a week, but probably due to some packet error.
Someone at YT literally broke what worked, in a way that is so naive and non-web2.0, as if it was made by a php junior from early 2000s. Because e.g. if you open history and newtab a link with &t=, then you have to refresh history now after watching few minutes of the video. And every click makes it worse cause it overwrites internal data too. The original “internal” method worked perfectly because it never relied on a url that may and will become obsolete. Idk why they did that and how it was approved etc.
Super interesting. Thanks for the details! (I don't work there or anything, was just curious about the implementation)