fix(YouTube - ReturnYouTubeDislike): Revert support for 18.37.36

[LisoUseInAIKyrios]

YouTube 18.37.36 uses a new Litho based shorts player.
But in this new player the dislikes shown is frequently incorrect, especially when swiping back to previous videos.

The issue is the video id hook is called out of order with a new short is swiped to. The prior shorts patch handled this by keeping track of all dislike buttons and then updating existing buttons asynchronously when the video id hook is called.

Previously it was thought a different video id hook might solve this. Now there is a Player Response video id hook, but it was found that hook is called for shorts preloading in the background and it's not reliable for finding the current or next short that's loading.

The only possible fix I see is one of three options:

• Set the dislike button text asynchronously (just as the existing Shorts player handles it). This would also fix the occasional frozen video during loading. But so far nobody has figured out how to modify litho components after they're created.
• Hook onto the video id a specific litho text is being created for (probably also difficult). This will still suffer from the occasionally frozen video but will fix dislikes showing the wrong value.
• Force the old shorts player to always be used (without spoofing the app version).

An unrelated bug also exist with the new shorts player, where the like/dislike/remix litho buttons do not appear at all. When this happens they are always hidden, and it requires restarting the app for them to appear again.

Until a fix is found, support should be reverted because otherwise dislikes for shorts is broken and unusable.

integration changes

[oSumAtrIX]

What is also possible, is to support RYD for normal videos, until a solution has been found for Shorts. I believe the majority will benefit from it in this way, too.

[LisoUseInAIKyrios]

I personally use the dislikes in shorts more than in regular videos. It's rare for any regular video to have over 3% dislikes, as the videos get hidden from discovery very quickly. But for some reason YouTube loves pushing shorts that have 10% or more dislikes, and after viewing most of them I see why so many people disliked.

If this cannot be solved in the near future, then RYD could be broke into two patches. One patch for regular videos, and another patch just for shorts. Then if someone hates shorts they can just exclude the patch and patch a newer version of YouTube. And when the problem is solved then combine the patches again.

[oSumAtrIX]

That sounds reasonable, separating the integrations will be challenging I assume.

[LisoUseInAIKyrios]

I think it could be done by the shorts patch changing an integrations static field from false to true. And integrations checks that field and then forces RYD shorts always off and hides the setting switch.

[oSumAtrIX]

changing an integrations static field from false to true

I'd say a simpler way would be to add a guard in the method that hooks the litho code and checks if the current player is a Short. In older versions of YouTube, the Litho code is not being used, the old patch hooks will be used and RYD will work on Shorts while on the new supported version, the guard will prevent the hook to modify the value for Shorts.

[oSumAtrIX]

video id hook is called out of order with a new short is swiped to

There may be a simple solution to this. The current hook we have for text spec is called whenever short components are rendered. This means, we just need a way to retrieve the current short video id at the time the hook is being called. This way we would be able to match the current playing short to the current video id.

[LisoUseInAIKyrios]

video id hook is called out of order with a new short is swiped to

There may be a simple solution to this. The current hook we have for text spec is called whenever short components are rendered. This means, we just need a way to retrieve the current short video id at the time the hook is being called. This way we would be able to match the current playing short to the current video id.

Yes, but it would need to be the video id for that specific dislike button.

The big issue is the dislike text for the next short is created before the short is swiped to. Swipe to the next short by swiping slowly up the entire screen and you'll see the dislikes for the next short is already there, even though the current short has not yet changed and the current video id has not yet changed either.

Maybe the video id is exposed somewhere in the new shorts player. And maybe the conversion context for that specific short could also be found. With both of those pieces it might be possible to figure out which video id a litho conversion context belongs to during it's creation.

It seems it might be easier 'tagging' a dislikes text as loading, and then find the image view that has that loading text (with a new patch point somewhere in the litho framework). Then in theory you now have the image view and can solve this asynchronously the same way the current shorts player works. I briefly looked at the litho source code for some insight, but man what a convoluted mess that is. I stopped looking when I found multiple comments of "for unknown reasons this value can sometimes be null so check to prevent null pointer exception" (??). It's not as bad as the source code for the awful Facebook iOS sdk from years ago (very messy + unnecessarily complex), so I guess they're improving.