bug(YouTube - Return YouTube Dislike): Invalid video ID parsed in Litho Shorts player

[aliernfrog]

Bug description

A new server-side change puts the video ID in buffer string after the dislike button's name, instead of its icon. Current patch does not support parsing video ID from this new buffer.

This results in RYD request returning a 400, and dislike count not appearing until the video is voted.

Error logs

No response

Solution

Parsing the video ID correctly.

Additional context

New buffer string looks like this:

shorts_action_bar.eml|ff15c5e6c482074|CellType|ContainerType|ContainerType|shorts_dislike_button.eml|573ad5b1b603aca4|shorts_video_action_toggle_button.eml|32a6f63e1b9396ab|shorts_video_action_button.eml|98eec64184a1c4d2|ContainerType|ContainerType|ContainerType|ImageType| BufferStrings: enme❙sans-serif-medium❙ic_right_dislike_off_shadowed❙id.reel_dislike_button❙Bu videoyu be❙enme❙xtY3MRjdeF0:2Cg0KC3h0WTNNUmpkZUYwEAAYASIMCMOnlqkGEMj-gpcBKAQ%3D❙

I have highlighted the video ID (xtY3MRjdeF0), it is between dislike button's localized name (Bu videoyu be❙enme) and :.

Acknowledgements

• This request is not a duplicate of an existing issue.
• I have chosen an appropriate title.
• All requested information has been provided properly.

[oSumAtrIX]

We already extract the video id from this place, but I am not sure why it does not work until you press dislike, as the id is present in the component when not pressed dislike beforehand too.

[LisoUseInAIKyrios]

The dislikes showing after voting is because it uses the 'current video' video id hook for that one situation, and that hook doesn't rely on parsing litho buffer strings.

@aliernfrog try disliking a short, closing the short, then reopening it. Post the litho log for that element (including buffer strings). It should use ic_right_dislike_on_shadowed, but the video id may appear slightly different in the buffer.

[LisoUseInAIKyrios]

At a minimum, the litho video id parsing could search for an 11 character string followed by ':' if the dislikes icon name also appears in the buffer. It should be more robust against litho components gets rearranged slightly (as long as the video id is in the format of 'videoid:'
This won't work for shorts that were previously disliked, because there is no ':' to detect where the video id is. But for that situation it could be accepted that no shorts will be displayed, and it's not common anyways.

Another solution is because the video IDs are detected by the player response before the litho text is parsed, the litho text could search the entire buffer until it finds the first string that matches a recent player response video id. That would work for previously disliked videos, and should be 100% resilient against all buffer structure changes as long as the video id appears somewhere in the buffer. Since only 3 shorts are loaded at any time, it would only need to search the last few video IDs the player response parsed.

But the real solution is to figure out a way to hook the dislike text view (not just the dislike spanned text), or find a way to force litho to rebuild itself (which would cause the existing litho text hook to be called, and would allow asynchronous updating). Then this buffer string parsing strategy would no longer be needed.

[aliernfrog]

When the video is disliked, : isn't there, but video id can still be found.

enme❙sans-serif-medium❙ic_right_dislike_on_shadowed❙id.reel_dislike_toggled_button❙enmemeyi kald❙wEZMsuG2GnYB4Cg0KC3dFWk1zdUcyR25ZGAAgASoLCPvxmKkGELaIoQMwBA%3D%3D❙

Another solution is because the video IDs are detected by the player response before the litho text is parsed, the litho text could search the entire buffer until it finds the first string that matches a recent player response video id

I guess this would be the easiest solution for now.

[LisoUseInAIKyrios]

Another solution is because the video IDs are detected by the player response before the litho text is parsed, the litho text could search the entire buffer until it finds the first string that matches a recent player response video id

I guess this would be the easiest solution for now.

I agree. I'll give this strategy a go.

[LisoUseInAIKyrios]

For now, turn on app spoofing and use target 18.20.39 and RYD will work correctly in all situations.